10 ms·
The evolution of Unix facilities and architecture (2017)
- rwaksmunski 4y agoTo this day I admire Linux for having the grit and perseverance of maintaining ext2, ext3 and ext4 as separate code bases for so long. Equivalent FreeBSD UFS, UFS with soft updates and UFS with journaling is one code base with each generation as a backward compatible feature. Given FreeBSD's negligible market share perhaps worse is indeed better.
- Datagenerator 4y agoFreeBSD usage is mostly hidden behind very large storage environments. Think PB scale HPC and NetApp (the glorified FreeBSD with some sellable added complexity), all running FreeBSD at it's core.
- throw0101c 4y ago* https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD https://en.wikipedia.org/wiki/List_of_products_based_on_Free...
- kryptiskt 4y agoI guess the various Playstations are the most widespread FreeBSD deployment.
- nix23 4y agoAnd TrueNAS, pfSense and OPNsense
- pjmlp 4y agoExcept there is just as much FreeBSD on PlayStation OS as there is on iOS.
- KerrAvon 4y agohuh, does that explain why the PS5, in 2023, still gets really upset about having power yanked while it’s not turned all the way off? It yells at you (talk to PG&E, Sony) and does a slow fsck when power is restored. Being stuck with old FreeBSD FFS would explain it. You’d think they could invest in a modern filesystem to make this headache go away.
- rwaksmunski 4y agoUFS with journaling makes fsck almost instant. They must be using barebones UFS.
- dbtc 4y agoAnd (at least parts of freebsd) inside all of Apple's devices.
- nix23 4y ago>Given FreeBSD's negligible market share perhaps worse is indeed better. Not sure if that's true, i know many people who have TrueNAS, but no Linux installation on a Desktop/Server. Also some PS3/4/5 owners and Netflix users, often people don't know they use FreeBSD or parts of it, but they know when they installed Linux. It's also funny that Linus tech tips probably use more FreeBSD's (TrueNas and OPNsense) then Linux's ;)
- pjmlp 4y agoLicense wonders.
- nix23 4y agoGood license with a bad product is still bad, so there must be more the "just" the license. For example netflix, they could use linux without any problems (since they don't redistribute the code nor the appliances).
- pjmlp 4y agoBetter be safe than sorry. Plus they also ship devices with Netflix code on them.
- nix23 4y ago> Better be safe than sorry. You talk bs. >Plus they also ship devices with Netflix code on them. Are you talking about open-connect? They don't ship that to "End-users", and you can sell an appliances with GPL software and proprietary code on it..hello Android?? And please stop now, your arguments are like from a 12yo, and i know for a fact that your much much older, also sometimes wiser, i don't know why that is not available for you today.
- pjmlp 4y agoWhat BS? The amount of precious upstream changes that FreeBSD gets from all vendors shipping their code? Android is actually a good example, it is no accident that Google has been cleaning Android from GPL code, leaving only the kernel and since Android 8 only Project Treble drivers (out of kernel) are used. Fuchsia is even better, only Apache and MIT licenses.
- yjftsjthsd-h 4y agoI mean, ext3 did eventually get merged, I think into ext4 just with some features disabled. But yeah, it is an interesting design choice.
- deleted 4y ago[deleted]
- efn4t 4y agoWhy do I like NTFS? It just works.
- nix23 4y agoWhat version of NTFS?
- bombolo 4y agoLet's hope you're not in a rush for your file to be created :)
- speedgoose 4y agoIt’s super slow. If you deal with many small files on Windows, you will observe much better performances in WSL2/ext4 than windows with NTFS. Even though the ext4 filesystem is stored as a file inside a NTFS partition. If you use NodeJS for example, it’s a very obvious speed difference.
- deleted 4y ago[deleted]
- anthk 4y agoOpenBSD it's the best case of doing thinks right. Stuff is too crappy and insecure to run, such as BT or Linux_compat(4)? Out. Laptop Fn keys for brightness? OOTB. Even with fvwm. Hyperbola GNU /Linux tries to do the same as a Parabola forked distro.
- rahen 4y agoNo, the author explicitly mentions the shortcomings of soft updates. Did you read the article?
- anthk 4y agoIn OpenBSD softdeps are an optional FFS mount option not enabled by default, (softdep). I don't use them. Theye can give you a boost on slower media, but a power cut can be fatal after untarring/cp -r/git cloning. Maybe you should have read the OpenBSD manpages.
- IshKebab 4y agoInteresting, but it doesn't really sounds like worse is better. More like "worse can work ok if you test it to death".
- mike_hock 4y agoMore like "worse" selected with survivorship bias is "better." The fact that block journaling happened to paper over a design flaw in PC hardware, was a complete luckball.
- Tuna-Fish 4y agoIt's not survivorship bias when you do selection. ext2 was not the only FS type available on Linux. As always with Linux, there was this wide variety of more or less off-the-wall choices. ext2 and it's lineage stuck with us because people started thinking that it was the one least likely to eat your data. The fact that ext2 happened upon a technical decision that worked well with cheap hardware was luck, the fact that ext2 ended up as the "default" file system on Linux was not.
- mike_hock 4y agoNo, but the "worse" technical decision survived because it turned out to be "better" out of sheer luck. If it hadn't, they would have found a fix for ext2 or we would have gotten ext3 sooner, or we would have gotten a different default FS. (Survival of the "bad" decision, not the FS itself, at least not necessarily.)
- kqr 4y agoIntentionally exploiting selection is sort of the point of "worse is better" as a design strategy. By promising fewer things in the design, you can get software in front of users faster, and you find out sooner what works well and what does not.
- userbinator 4y agoIronically, I've had far more problems with Linux systems using extfs losing data or requiring very lengthy fsck'ing after hard resets than Windows 9x or even DOS on FAT, despite experiencing more hard resets and routine hangs in my use of the latter. I suspect the relatively more aggressive write caching of Linux and Unix-likes, combined with their more complex filesystem data structures, leads to a design in which unexpected resets easily cause lots of filesystem corruption. Contrast that with FAT's simplicity, minimal (effectively none) write caching, and the tradition of cutting power as soon as you returned to a DOS prompt. Maybe that's actually the true "worse is better".
- noselasd 4y agoYes, ext2, before journaling was added to extfs was painful, powerloss, or simply switching off a computer without runnng shutdown often resulted in data loss and if you're unlucky enough, fsck threw you in to "please try to fix this, I can't" prompt on the next boot.
- b112 4y agoextfs isn't a thing, and I say that because ext3 or 4 or even 2, matters here. That spake, I wonder, are your bad experiences here with VMs, or with a raspberry pi? Pis, especially the 2, had faulty hardware, and would report a successful write to an sd card before it was done. To "help" with speed. This cause the sort of issues you are mentioning. And similarly, any situation where a write complete is a lie, can result in this behaviour too. EG, a raid card with hard power off, no battery backed up cache, etc. Because your experiences do not jive here, with ext4, and thousands upon thousands of servers and desktops I maintain.
- scns 4y ago> would report a successful write to an sd card before it was done. To "help" with speed. Sadly USB sticks are handled the same way. The write notification and progress bar are long gone but you won't be able to eject that medium for several minutes. Don't remember if it is the same on windows, since i use it rarely.
- bluedino 4y ago> You were dropped into some stand alone shell after fsck threw up its > hands and it was up to you to fix it. I can't remember how many of my early Linux systems I couldn't recover after a power outage (or crash) because / was corrupt
- stingraycharles 4y agoReally? As someone who has been using Linux since the 90s, for me the corruptions were extremely rare. Full fsck of course was happening regularly after unclean shutdowns, but I think I encountered only 1 or 2 actual corruptions.
- mpol 4y agoI had it happen many times as well. A power outage or a thrashing system were often accompanied with an fsck and file loss on ext2. This even included system files like libgtk.so because they were open at the moment of crashing. I never understood why reading/opening a file would corrupt it on a crash. I was happy to switch to Reiserfs.
- jmbwell 4y agoIn my own experience, such situations were more likely when the system was already suffering some other issue or failure, like a failing array member or a volume out of space or something more routine, and in the course of troubleshooting, ah shit, now I have a corrupted root to deal with. Had one app that crashed inexplicably every year at midnight on Halloween. Or at least the two years I put up with it. Had to leave a party to rebuild a server from scratch when one failure turned into lots of failures. Not missing those days!
- jmclnx 4y agoSame here, but I think in those early days, after so many mounts (boots) on ext2, an fsck would execute. I think the number of times was 15.
- okamiueru 4y agoYou can't remember, because it was so long ago?
- j1elo 4y ago> In Linux, ext2 was incredibly sloppy about how it handled write ordering --- it didn't do anything at all. But as a consequence we developed tools that were extremely good to compensate So worse is not better, then! More like worse needed greater efforts to make decent. Imagine all that great tooling effort, applied to create excelent tooling for the other so-good and well engineered filesystem, the FFS mentioned in the article.
- harshreality 4y agoAs he mentions, unless you disabled the hdd's write-back cache, you had to deal with the same class of write-ordering problems anyway.
- j1elo 4y agoYeah it seems that the kind of brute force or less than ideal software-engineering style of ext2 was a perfect match for the kind of hardware qualities (i.e. very low ones) that were the target! In the end everything ended up working better, even if due to completely accidental reasons.
- tankenmate 4y agoOr maybe the decisions were a form of emergent behaviour; the developers that succeeded were the ones whose behaviour best matched the environment. The accidents ARE the reason it worked; i.e. evolution.
- lifeisstillgood 4y agoThank you - insightful :-) Perhaps that's the reason why a market succeeds under schumpeter but a planned economy (ie inside a large company) often fails
- fidgewidge 4y agoYeah once you start thinking in evolutionary terms you see it everywhere. Like why do we have this discussion via interactive documents? The web has a sort of evolutionary fitness that lucked its way into being a popular app platform.
- pclmulqdq 4y agoOperating system engineers seem to often have a "bug" in their thought process where they believe the models of hardware they use are close to 100% true. It turns out that they are often almost completely false, so relying on those promises is a bad idea.
- temac 4y agoGood luck for developping a robust system by considering the execution plateform can introduce bugs anywhere and trying to resist them all. The article makes me think the Linux journaling redudancy robustness was not even really a conscious choice, but more a happy accident coming with a simpler design because less effort cound be put in it. Now maybe simplicity everywhere is actually beneficial for mean robustness, but this will not be true for all particular cases.
- daneel_w 4y agoFFS/FFS2 on OpenBSD is definitely one of the system's weaknesses. In addition to being kinda slow it's also a bit unnerving that the file system invalidates relatively easily. While it doesn't happen regularly for me, and despite never having suffered actual data loss, it's always unnerving sitting through a forced fsck session.
- magnat 4y ago> when power drops, and the voltage levels on the power rails start drooping, DRAM tends to go insane and starts returning garbage long before the DMA engine and the hard drive stops functioning That doesn't sound right. DRAM can keep its content for a few seconds without power - it's what make Cold boot attacks [1] possible. Also, DRAM has its own buck voltage regulators, usually with hefty inductors, capable of delivering power long after +5V and +12V started to drop. [1] https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
- tankenmate 4y agoIt could look like the DRAM is the problem if the data bus was the actual problem, as the DMA would request data via the bus. This is just speculation here obviously. But if you have lots of hardware on a tri-state bus most of which is not of "data centre" quality then it wouldn't be unusual for bus arbitration to go out the window in a fluctuating power condition. So from the DMA through to write operation you have data corruption issues, and you'd think it was probably the DRAM but in fact if the bus arbitration is corrupted then you still get corrupted data. I suspect sure that the vast majority of PCs don't have error detection (let alone ECC) on their data buses (even something as simple as a parity bit), but I could be wrong.
- nicolaslem 4y agoHaving memory return a few bits flipped can have disastrous consequences on a running system. On the other hand having memory with only a few bits flipped is still a gold mine for a cold boot attack.
- yjftsjthsd-h 4y ago> After they discovered this problem, they added extra capacitors to the power supply, added a power fail interrupt, and taught Irix so that when the power fail interrupt was triggered, it would frantically cancel DMA transfers in order to avoid this problem. Hilarious, but, I suppose, effective. Perks of controlling the entire vertical...
- moloch-hai 4y agoI like how almost everybody back then earnestly believed that if power dropped, the drive would use its spinning-down motor as a generator to power finishing the current sector write, and then home and lock the head. I don't know if any drive ever did that. But certainly the drives actual people actually had would not. Power hiccups, and whatever is being written becomes garbage (and maybe a few sectors after it, too), and the heads flop loose. Maybe a top-quality drive would turn off current to the write head if power sagged, so that the controller going crazy would not have lasting consequences. But certainly cheap drives never had anything that might have cost an extra penny.
- dtgriscom 4y ago> the drive would use its spinning-down motor as a generator Is that what it means to have a "hybrid" drive? Prius and Seagate had a kid?
- wankle 4y agoThe added capacitors probably also greatly improved filtering of the power adding additional buffering against power fluctuation.
- einpoklum 4y agoThen wouldn't the engineers have added them in the first place?
- mananaysiempre 4y agoNon-archive link: https://minnie.tuhs.org/pipermail/tuhs/2017-May/011552.html https://minnie.tuhs.org/pipermail/tuhs/2017-May/011552.html. I don’t know why the number is different, but it seems to be the same message.
- dang 4y agoChanged from https://web.archive.org/web/20170515160229/https://minnie.tuhs.org/pipermail/tuhs/2017-May/009935.html https://web.archive.org/web/20170515160229/https://minnie.tu.... Thanks! Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html It's fine to post archive links in the comments! but not at the top level, unless you've searched and there's really no alternative.
- mustache_kimono 4y agoUm, "worse is better" if your only metrics are things like time to market. How many Linux technologies have not been able to surpass their counterpart technologies after years of iterating? Two are top of mind: epoll and btrfs. Sometimes designing a system is the best approach. Sometimes iterating on a "worse is better" technology is the right approach. There is no single answer. I think we need to be more rational about the real reasons Linux is/was so successful. Yes, sometimes it was about "worse is better" but certainly not the majority of the time. My guess is -- the reason Linux was so successful can be summarized much more easily as: free as in beer, unpretentious (does not require adopting some high UNIX religion), appealing licensing (I don't love the GPL/licensing religion but lots of people do!), and it was very, very lucky.
- pjmlp 4y agoSince when did epoll got better than Solaris or Windows alternatives?
- mustache_kimono 4y ago> How many Linux technologies have not been able to surpass their counterpart technologies after years of iterating? Two are top of mind: epoll and btrfs. I'm saying epoll is an example of a technology which has not been able to surpass its Solaris or Windows equivalents.
- pjmlp 4y agoAh sorry, got it the other way around.
- ajross 4y agoSeems like there's a semantic problem here. epoll won. It clearly "surpassed" its competitors by most definitions. Arguments against it aren't grounded in epoll's capability or performance. They're about aesthetics. People used to kqueues think epoll is ugly. Well, OK. I think that's fair. But being beautiful isn't sufficient to declare a software feature as having "surpassed" another, again by conventional definitions. It's just a way to win an argument. Really the epoll nonsense is a perfect microcosm of exactly this kind of argument. For 30 years the BSD folks have been making fundamentally aesthetic arguments into a market that demands practical solutions. And... losing, kinda. FWIW: I think the btrfs argument is rather stronger on a technical level. The problem there is that people stopped caring about local storage filesystems about 10-15 years ago. Local devices are a solved problem, and all the innovation in storage technology is happening in the cloud today, in front of software layers that are only vaguely understood as "filesystems" in the Unix sense.
- mikewarot 4y agoUnix/Linux is successful because for decades its apparently been ok to ignore the gaping security hole specifically left out of the cloning of Multics. Without a way to run untrusted executables, it us completely unfit for the current 24/7 connectivity and mobile code environment we find ourselves inhabiting. We've patched around it with VMs and Containers, but we all just need a way to hand a file to an untrusted program, and that's the balls part of Multics that Unix cut away.
- hulitu 4y agoI don't think Multics run a RCE program like Firefox or Chrome. When your RCE program has "accelerated graphics", all bets are off.
- deleted 4y ago[deleted]
- mixmastamyk 4y agoSounded familiar: https://news.ycombinator.com/item?id=34377822 https://news.ycombinator.com/item?id=34377822