Skip Navigation

Posts
0
Comments
306
Joined
2 yr. ago

  • Looks really nice and seems like it should be a great foundation for future development. Personally I can't lose Nextcloud until there are sufficiently featureful and reliable clients for Linux, Windows, Android that synchronize a local copy and help manage the inevitable file deconfliction (Nextcloud Desktop only barely qualifies at this, but it does technically qualify and that represents the minimum viable product for me). I'm not sure a WebDav client alone is enough to satisfy this criteria, but I am not going to pretend I am actually familiar with any WebDav clients so maybe they already exist.

  • You're on the right track. Like everything else in self-hosting you will learn and develop new strategies and scale things up to an appropriate level as you go and as your homelab grows. I think the key is to start with something immediately achievable, and iterate fast, aiming for continuous improvement.

    My first idea was much like yours, very traditional documentation, with words, in a document. I quickly found the same thing you did, it's half-baked and insufficient. There's simply no way to make make it match the actual state of the system perfectly and it is simply inadequate to use English alone to explain what I did because that ends up being too vague to be useful in a technical sense.

    My next realization was that in most cases what I really wanted was to be able to know every single command I had ever run, basically without exception. So I started documenting that instead of focusing on the wording and the explanations. Then I started to feel like I wasn't capturing every command reliably because I would get distracted trying to figure out a problem and forget to, and it was duplication of effort to copy and paste commands from the console to the document or vice versa. That turned into the idea of collecting bunches of commands together into a script, that I could potentially just run, which would at least reduce the risk of gaps and missing steps. Then I could put the commands I wanted to run right into the script, run the script, and then save it for posterity, knowing I'd accurately captured both the commands I ran and the changes I made to get it working by keeping it in version control.

    But upon attempting to do so, I found that just a bunch of long lists of commands on their own isn't terribly useful so I started to group all the lists up, attempting to find commonalities by things like server or service, and then starting organize them better into scripts for different roles and intents that I could apply to any server or service, and over time this started to develop into quite a library of scripts. As I was doing this organizing I realized that as long as I made sure the script was functionally idempotent (doesn't change behaviors or duplicate work when run repeatedly, it's an important concept) I can guarantee that all my commands are properly documented and also that they have all been run -- and if they haven't, or I'm not sure, I can just run the script again as it's supposed to always be safe to re-run no matter what state the system is in. So I started moving more and more to this strategy, until I realized that if I just organized this well enough, and made the scripts run automatically when they are changed or updated, I could not only improve my guarantees of having all these commands reliably run, but also quickly run them on many different servers and services all at once without even having to think about it.

    There are some downsides of course, this leaves the potential of bugs in the scripts that make it not idempotent or not safe to re-run, and the only thing I can do is try to make sure they don't happen, and if they do, identify and fix these bugs when they happen. The next step is probably to have some kind of testing process and environment (preferably automated) but now I'm really getting into the weeds. But at least I don't really have any concerns that my system is undocumented anymore. I can quickly reference almost anything it's doing or how it's set up. That said, one other risk is that the system of scripts and automation becomes so complex that they start being too complex to quickly untangle, and at that point I'll need better documentation for them. And ultimately you get into a circle of how do you validate the things your scripts are doing are actually working and doing what you expect them to do and that nothing is being missed, and usually you run back into the same ideas that doomed your documentation from the start, consistency and accuracy.

    It also opens an attack vector, where somebody gaining access to these scripts not only gains all the most detailed knowledge of how your system is configured but also the potential to inject commands into those scripts and run them anywhere, so you have to make sure to treat these scripts and systems like the crown jewels they are. If they are compromised, you are in serious trouble.

    By now I have of course realized (and you all probably have too) that I have independently re-invented infrastructure-as-code. There are tools and systems (ansible and terraform come to mind) to help you do this, and at some point I may decide to take advantage of them but personally I'm not there yet. Maybe soon. If you want to skip the intermediate steps I did, you might even be able to skip directly to that approach. But personally I think there is value in the process, it helps defining your needs and building your understanding that there really isn't anything magical going on behind the scenes and that may help prevent these tools from turning into a black box which isn't actually going to help you understand your system.

    Do I have a perfect system? Of course not. In a lot of ways it's probably horrific and I'm sure there are more experienced professionals out there cringing or perhaps already furiously warming up their keyboards. But I learned a lot, understand a lot more than I did when I started, and you can too. Maybe you'll follow the same path I did, maybe you won't. But you'll get there.

  • Was this article written by AI? It's full of what seem to be overly specific references and is just really fucking weirdly paced and disorganized.

  • Nextcloud is just really slow. It is what it is, I don't use it for any things that are huge, numerous, or need speed. For that I use SyncThing or something even more specialized depending on what exactly I'm trying to do.

    Nextcloud is just my easy and convenient little dropbox, and I treat it like it's an oldschool free dropbox with limited space that's going to nag me to upgrade if I put too much stuff in it. It won't nag me to upgrade, but it will get slow. So I just don't stress it out. So I only use it to store little convenience things that I want easy access to on all my machines without any fuss. For documents and "home directory" and syncing my calendars and stuff like that it's great and serves the purpose.

    I haven't used Seafile. Features sound good, minus the AI buzzword soup, but it looks a little too corporate-enterprisey for me, with minimal commitment to open source and no actual link to anything open source on their website, I don't doubt that it exists, somewhere, but that raises red flags for potential future (if not in-progress) enshittification to me. After eventually finding their github repo (with no help from them) I finally found a link to build instructions and... it's a broken link. They don't seem to actually be looking for contributions or they're just going through the motions. Open source "community" is clearly not the target audience for their "community edition", not really.

    I'll stick to SyncThing.

  • Sounds like you're doing fine to me. The stakes are indeed higher, but that is because what you're doing is important.

    As the Bene Gesserit teaches: I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear.

    Make your best effort at security and backups, use your fears to inform a sober assessment of the risks and pitfalls, and ask for help when you need to, but don't let it stop you from accomplishing what you want to. The self-hosting must flow.

  • It was, and still is. It hasn't moved to the US, it just also opened a nonprofit there, so the US donations they receive from US people are tax deductible in the US. If I remember correctly they have also opened a non-profit in Belgium which is I think where they are intending to actually move their assets and do most of their work going forward as I think they've had various issues with the German organization also.

  • So far, I think you're safe!

  • Will this become Lemmy's "test post please ignore"? I guess we'll see.

  • It's definitely not burn-in, it's likely some kind of defect in the backlighting system. For most LCDs the "backlight" is essentially a big thin white/mirrored panel reflecting or diffusing light in a very carefully consistent way from a very bright light source, typically either a fluorescent tube at the bottom or more commonly nowadays evenly spaced strips of LEDs. Some higher end models use more elaborate designs but they're the minority. Defects in the backlight panel, the back of the LCD panel, or stuff like dust or even insects getting inside that reflective/diffuser chamber will affect the consistency of the backlight as it both blocks a bit of the light from reaching some places and reflects it to other places it shouldn't be. That's what it looks like is happening here. It could be some kind of delamination of some of the surfaces inside the TV, or it could be some puff of dust that somehow got inside, or even something like a spider decided that was a great place for a cobweb. Without opening the panel it's hard to say what's going on exactly, it might just need a very delicate cleaning or it might need replacement parts.

    If you're afraid of spiders, I'm sorry, you just have to burn the house down now, it's the only way to be sure.

  • User's post history offers some clues that it may not be worth engaging with them.

  • AA batteries is an interesting choice. Wish we had a ubiquitous lithium-rechargable-based battery standard for products like this that would be smaller than an 18650 but bigger than a coin cell. Design it with some safe chemistry like LiFePo if you have to, but the old 1.2-1.5V AA standard is starting to feel very anachronistic these days.

  • It is a perfectly valid approach, and there are also many other perfectly valid approaches. "Better" requires a definition of what you want to be better. If there's something that's making you uncomfortable about the process, let us know what concern or issue you're seeing with it and maybe we can guide you to a better way for you. But there's nothing wrong with the way they're doing it. Others may have different preferences (including you, YOU might have different preferences!) but they're just preferences. It's not right or wrong, even if some people argue that it is, they're always going to have some preferences embedded in that judgement. There's always more than one way to do it. That's the joy of it, really, and sometimes you'll have to experiment yourself to find out what ways YOU like the best, that make sense to you, that are comfortable for you, or that do things the way you want to do them.

    It's your own self-hosting setup, you get to make the choices. Sometimes the number of choices can be intimidating and lead to analysis paralysis but the only way out of that is to realize that there really is no way of finding the "best" until you've tried many different ways and figured out the "best" yourself. That's why the only real advice I can give you is to just go through the tutorial you've found and do it the way they do it for now. You can change later, as you learn more, when not if you decide you want to do something differently. Because you will. We all do. It's part of the process.

  • When the antichrists leading the formerly-free-world attempt to crucify Gaming Jesus we'll know the end times have truly arrived.

  • I think it's generous helpings of both.

  • The OG cyberpunk Johnny of course is included in that. while he is technically found among "any of the Johns", I actually meant for it to be both implied and explicitly included, but my words kind of got ahead of my muddled brain.

  • I'd absolutely buy and play more cyberpunk games with Johnny Silverhand/Keanu in them. I'd also play games where I can be Johnny Silverhand/Keanu. Could certainly see another attempt to make some cyberpunk-style matrix-like story or open world that would go over well with me. I'm pretty open to any sort of Johnny Silverhand/Keanu related themes. I'd also readily accept a John Wick or John Constantine or Johnny Utah game too, basically any of the Johns. Honestly, I'd even play a game where I have to drive a bus that can't slow down or it explodes (which really isn't any different from most arcade racers when you think about it). Basically, shut up, take my money, do whatever you want with it as long as there's eventually more Keanu- or Keanu-adjacent-content in the video gaming space once you're done, this is a good thing. Or just inject some Keanu right into my veins, whatever, I don't know.

  • Solution in search of a problem in my opinion. I don't see any problem. Lemmy's perfectly fine the way it is right now. If there becomes some problem eventually, we can figure out how to solve it when it happens with a more clear understanding of what the problem actually is.

  • I'm a meat popsicle.

  • Eventually people might learn why they should not just prefer to have, but actually require open systems for all the computers in their lives, even the ones hidden inside of their appliances, instead of buying these locked down, pre-programmed, remote-updated internet-of-shit devices.

    If you can't get root and boot access on your device, decide what you're updating it with and when, you don't own it or control it in the first place. You're just letting some shitty company (and maybe anyone at all with the amount of security flaws these devices have) directly into your home and network to decide what you can or can't do with your product (and when and how much it's going to cost), while they take advantage of every opportunity they can think of to spy on you and extract money from you. Any device with microchips in it isn't just an appliance anymore, it's a trojan horse full of gross and creepy salesmen and they're going to be there forever, watching you and figuring out ways to get more of your money.