Those aren't competitors of Spotify/Netflix; they're alternatives for people who are willing to tolerate small inconveniences to have full control over their library.
Of course it's not as easy as signing up for Spotify/Netflix, but setting them up is easier than ever (even easier for tech people).
Yup, the key word for me is control. And over time, considering the continual loss of control, more people will adopt self hosting, and things will get better and easier. For now, i only recommend it to hobbyists or people with free time and money. It does take quite a while to get it all running smoothly.
To me, it starts to feel like work when I have to rebuild large parts of my factory because I didn't leave enough space to expand. This process feels exactly like having to refactor a bad codebase (where you feel the urge to just start from scratch).
If you plan your build properly, you can avoid this, but it takes a few runs to learn the best strategies.
Factorio makes me realize that I don’t really like solving problems for the sake of solving problems (or optimization, for that matter). I like solving them for a tangible reason or because I I’m making someone’s life better.
Problem solving and optimizing in Factorio is different than a grind in some game like Diablo. That sort of grind uses a completely different part of your brain (movement and in-the-moment decision making), and I find that I need that kind of change after a week of real-life problem solving.
I imagine people who gravitate to Factorio are probably better problem solvers and optimizers than me because that’s what they truly enjoy for its own sake.
I think the new expansion helps a lot with the rebuild issue, since you're expected to have have many different bases on different planets instead of just one big base.
Once you buy a game on Steam, you don't need to pay any kind of subscription to play it. The vast majority of games sold there are, in fact, one-time purchases. The games stay in your library even if the developer/publisher decides to delist them.
There are games like MMOs that do require a subscription, but that has nothing to do with Steam itself.
It's a great tool when you can actually read and understand the code AI is feeding you. When you don't really know how the language works or don't know programming in general, you end up getting stuck trying to guess why this valid piece of code (that looks like it should do what you asked the LLM for), is not working properly.
UNIX etc has all file access start from /. DOS/Windows has separate trees starting with different letters. I think having it all in one tree structure has some advantages. All paths can be expressed as relative paths, for instance.
Windows kind of does have that. They call it the global catalog or Win32 Device Namespaces.
somehow C: is easier to type than \\?\GLOBALROOT\Device\HarddiskVolume2\ or \\?\GLOBALROOT\Device\Harddisk0\Partition2\ or even \\?\Volume{1ab2d2f9-230f-4c63-bc25-163c085334df}\ though.
VMS is a good example of a system that uses very un-UNIX-like file naming conventions, with ::, :, [], ., and ; used as separators for different path components:
I think having one tree is a huge advantage. take the windows registry, on paper it sounds like a great idea. "lets make a single unified database to hold all config values" In reality, it sort of sucks. One of the reasons it is so unpleasant to use. Is that now you have another tree with different special access patterns and programs that are incompatible with your main tree(or trees in the case of windows).
I really like the plan 9 ethos here, which can be summed up as "does it vaguely look like a tree? if yes, put it in the file system". My favorite one was html "Hmmm... An html document is tree structured.... hey guys lets make our web browser a filesystem driver. (enthusiastic clapping)". Having said that, having no mainstream browser on plan9 is what usually keeps me from using it. I keep telling myself that avoiding the web drivel that requires a mainstream browser would make me a happier person, but I keep coming back for more.
Well, me too, but it is 2024 and we have half a dozen technologies that let us put a few terabytes of non-volatile directly-accessible memory on the CPU memory bus.
Isn't it maybe time we relegated the technology of sequentially-accessed disk storage -- including SSD -- to legacy status, like tape drives, and stopped thinking about files and folders at all?
We are one quarter of the way through the 21st century. "Disk drives", including flash memory pretending to be disks, is legacy tech. We do not need filesystems any more. Let's move on and banish this to VMs holding legacy OSes for backwards compatibility with existing workloads.
A "filesystem" is really just a key:value store, in the unix system the key is hierarchical and each value can have more than one key. The real unix innovation was to combine all such stores present on a system into one tree. The point is to have a nice human accessible address to get your data at.
Now, theoretically, all memory access on the system could be done via one simple api. and as plan9 showed most IO can be done via that same api. It is sort of like having all networks be IP or all protocols be HTTP. The implementation may not be ideal but having that narrow waist is a huge quality of life improvement.
Realistically, it is only used for items that need to persist outside of a processes run cycle.
There are useful simplifications, and over simplifications.
As in a cartoon I once saw: two cats are talking, and one says of the human they're looking at: "it's a box of electronics, and when he presses buttons on the front, it flashes little coloured lights on that panel at him. It keeps him occupied for hours."
It's true and 100% accurate, but it's not at all precise.
It doesn't matter what kind of store it is. What matters is that it is an indirection mechanism designed for computers which were unable to access large amounts of directly-addressible non-volatile store.
Computers no longer suffer from this restriction, but all current OSes are built around this abstraction, and it cripples them.
I had this exact experience with my workstation SSD (NTFS) after a short power loss while NPM was running. After I turned the computer back on, several files (package.json, package-lock.json and many others inside node_modules) had the correct size on disk but were filled with zeros.
I think the last time I had corrupted files after a power loss was in a FAT32 disk on Win98, but you'd usually get garbage data, not all zeros.
> but you'd usually get garbage data, not all zeros.
You are less likely to get garbage with an SSD in combination with a modern filesystem because of TRIM. Even if the SSD has not (yet) wiped the data, it knows that a block that is marked as unused can be retuned as a block of 0s without needing to check what is currently stored for that block.
Traditional drives had no such facility to have blocks marked as unused from their PoV, so they always performed the read and returned what they found which was most likely junk (old data from deleted files that would make sense in another context) though could also be a block of zeros (because that block hadn't been used since the drive had a full format or someone zeroed free-space).
They may be pointing to unallocated space which on a SSD running TRIM would return all zeros. NTFS is an extremely resilient yet boring filesystem, I cannot remember the last time I had to run chkdsk even after an improper shutdown.
As somebody who worked as a PC technician for a while until very recently, I've run chkdsk and had to repair errors on NTFS filesystems very, very, very often. It's almost an everyday thing. Anecdotal evidence is less than useful here.
So anecdotal evidence is not useful, as proven by your anecdotal evidence? :)
FWIW I've found NTFS and ext3/4 to be of similar reliability over the years, in general use and in the face of improper shutdown. Metadata journaling does a lot to preserve the filesystem in such circumstances. Most of the few significant problems I've had have been due to hardware issues, which few filesystems on their own will help you with.
It is worth noting that when you run tools like chkdsk or fsck, some of the issues reported and fixed are not data damaging, or structurally dangerous, or at least not immediately so. For instance free areas marked in such a way that makes them look used to the allocation algorithms.
There's a difference between your personal experience and my experience in a professional role handling multiple customer devices every day.
However, I'm also not making a statement about NTFS's reliability vs ext3/ext4. In the years that I worked in that position, I maybe dealt with Linux systems 3 times.
Reminder of the original statement:
> NTFS is an extremely resilient yet boring filesystem, I cannot remember the last time I had to run chkdsk even after an improper shutdown.
I never said anything about catastrophic failure of an NTFS filesystem. I have experienced that, but it was comparatively rare (still happened though). I have, however, have had to run chkdsk fairly often to correct errors. Sometimes user data was affected to some degree, but it was often a matter of system stability and getting Windows back to running without issues.
I still find that NTFS is reasonably resilient and have no qualms with it. I just want to push back against the idea that nothing ever goes wrong with NTFS, which was implied by your statement that you can't remember the last time you used chkdsk.
> not making a statement about NTFS's reliability vs ext3/ext4
I should have been a bit clearer there: I only mentioned those specific filesystems because those are the ones I have a lot of experience with, rather than intending to bang the drum for them (or one in favour of the other). I expect other much-tested journaled filesystems could be substituted into the same sentences.
