I paid nearly as much at that time for a 20 or 25 MB disk, which I believe still works. The difference is probably that mine was a SCSI disk for my Amiga computer.
Like others have noted, it gives no indication of the data density on platters.

You're saying nonsense, and clearly have zero knowledge of what you're talking about. Bash is a GNU shell and is still updated to this day, like all the GNU tools.
Contrary to you ignorant anti-systemd folks, I actually implemented my own OS, since 20+ years now, and I was doing my own shell scripts. I quickly ran from sysvinit (used other init that still needed shell scripts), because yes, it was well known and I learned quickly how bad it was, at least on Linux for which it was not made.
Your supposedly well known programs can and have broken system boot countless times, sometimes just because the simple programs you call well known changed behaviour following an update. You clearly never made the work needed to create all these scripts so that your system can boot properly, and never had to understand why it was not booting 100 % of the time, or why you lost data after a reboot. Distro maintainers sure have seen all these problems, far more than I have.
Despite all the work I put in these scripts, I happily benched all that when systemd came. Well, I still have scripts to start my LiveCD.

This there just shows how ignorant you are, par for the course for systemd haters.

So you never heard of MAC address spoofing or of the ability to have a random MAC like in virtualized environement or on some Ethernet or Wifi devices?
The UUID thing is part of the DHCP spec BTW, MAC address is only one (the more prone to errors) of the options used to attribute an IP address.
I'm glad we had some truely knowledgeable people on systemd dev team, ignorant people like the anti-systemd haters wouldnever have make this work.
Which is why no other init managed to be accepted as systemd has.
I understand lower devs have ego problems with systemd, but at least people should have basic knowledge of what they're talking about. systemd haters usually don't know at all what they're talking about, this is another example.

So BusyBox makes no sense then? Because it was designed also for embedded.
Ignorant fools on /. are pretty pathetic, displaying ignorance on nearly every comment, especially in systemd threads, full of nonsensical and clueless hyperbole.

FYI, the journal log of systemd doesn't grow indefinitely, it is perfectly in line with the best good practices that were never followed by every sysvinit scripts.
But I can't say I'm surprised by such ignorant comments from systemd haters.

It's amazing how you actually answered lots of things are wrong on your system, confirming what the GP told you, but you didn't even realize it. Talk about clueless people trying to masquerade as admins. No wonder there are so much zombies on the Internet, you and your server are a danger to the internet.
My frontends have fail2ban configuration with ipset tables for my firewall to automatically ban IP that do SSH login attempts (currently 320+ blocked), and even when I didn't make these setups on all my Internet facing servers, I was never hammered to make journald behave like that.
Perhaps your server is a malware nest, it's not normal to have so much ssh spam from the Internet.
Old versions of journald had bugs which could make it waste lots of CPU times though, and my systems are up to date, perhaps yours is not.

The one that responded to the nonsense you posted above is right though, as it's plain obvious you have no clue at all at what you're talking about.
He was kind enough to not tell you that what you're saying is complete nonsense and it means you don't even understand what initd (PID 1) is.
The solution you gave is sth someone that believes computing is some sort of magic (which is most of people on this planet) would give.
You'd better educate yourself instead of entering debates on things that you don't understand.
Usually, when knowledgeable people, say engineers, don't understand a subject, they educate themselves, they're not saying nonsense to other knowledgeable people, unless they want to look like a fool. Only clueless people do that, that's the Dunning-Krüger effect which is prevalent among anti-systemd people.
It's obvious most of them have zero sysadmin skill and lots have zero computing skill too.

It's amazing how clueless people on ./ have become. This isn't even hardcoded in the resolver, this is a configuration option at configuration time before compilation. On my own systems, the resolver doesn't have this DNS server address. And that's only the default that is configurable and not used at all if configured anyway. I notice enemies of systemd most of the time spread FUD and talk about Windows, like they were enemies of Free Software.

If the first part wasn't enough to cement the idea that you don't know what you're talking about, this is now clear there. No competent sysadmin would want sysvinit on Linux, most of the disasters on servers happened because of it. On desktops too now that I think of it.

I did have criticism of sysvinit 20+ years ago and still have them today, if not worse.
systemd saved us from this disaster that was happening on every Linux system used seriously (server or desktop mainly).
The countless crashes, locked out of sessions users, loss of data, impossible to restart daemons, not rebooting servers... were mostly because of sysvinit, which is an abomination (I'll explain why later). I quickly escaped from this on my own systems (that I build myself from scratch) to install other inits like simpleinit-msb and perfected the scripts so that I didn't have to flip a coin to have my servers or desktops actually reboot 100 %, well, 99 % of the time. And most of all not lose data.
The amount of Linux systems that were not sure to boot after a shutdown, or that would lose lots of data, is scary. Just here on ./, the amount of people that have stuck shutdown with systemd are so clueless they don't realize systemd actually does things right, where before sysvinit would have broke their system that would lose data or break in the process.
You at least read some inittab documentation, so you at least must have some of the knowledge that I acquired 20+ years ago that people today calling themselves "veteran Unix admins" still don't have.
But you still lack a lot of knowledge about both sysvinit and Linux, given the nonsense you put in some of your answers.

So let's see :

No this is not achievable at all using the method you described. I actually tried that back in the day, and it was entirely dependant on the daemons behaviour. I once had a daemon enter a fork bomb and writing countless of pid files on the filesystem, having to power reboot and hope the system was going back safe.
This is a nightmare security wise and a recipe for disaster for any new service you add. The safeguards in RH boot scripts were not there for nothing. And this never worked right even when you manage to reel in your daemons, as some would still not behave correctly without sth like inetd, which didn't even work for socket activation, which is needed for parallelizing socket services.

Again, no, you don't understand what socket activation is, it's not blindly launching a group of process, and socket activation requires no user or wrapper script interaction like the ondemand option of sysvinit. It's impossible to do socket activation with sysvinit. A separate eventd would just do the same thing as systemd already does. I had to do very racy things on my systems just to emulate socket activation and it never worked 100 %. I had to fine tune the scripts every time the hardware died and I changed it, or my perfectly working scripts would not even boot. And I was not even using sysvinit anymore, or the OS would never manage to boot.

The argument is not reversed at all: "Keeping the First User PID Small" has nothing to do with what you're talking about at first (size of initd versus size of systemd init, which has nothing to do with keeping size of iniitd small, it's not a comparison argument). It's related to the next topic and also a reason why Linux on servers was always a disaster waiting to happen.
There's a reason the distributions adopted this RH scheme or scripts, the same reason I abandoned using inittab directly after wondering why everyone was not doing the same. When sth fails, it's a disaster when restarted automatically by sysvinit, and when not, your service is out and you're not even aware, and can do nothing without a clever console scheme, when it manages your tty and console.
sysvinit has no way to boot countless systems like a distribution has to do, without tons of scripts calling tons of executables. Even my tuned scripts with execs everywhere would launch hundreds of processes before the first user could even start. This hasn't changed today, and distributions had easily processes PID in the thousands at boot. And on servers with high process counts (or even desktops), it lead to countless problems, bugs and crashes. One of the reasons I switched to simpleinit-msb decades ago was also to limit this count which would lead to countless problems.
I no longer have the biggest problem you missed out today because of the recent addition of pidfd to the Linux kernel and the 32 bit PID activated on my systemd OS. But for now, servers on Linux are still vulnerable to these decades old bugs and crashes introduced by sysvinit on Linux.
systemd crushes sysvinit in this department, and just mounting your disks when you have things like LVM, RAID, NFS and the like, will put you in the thousands of PID launched. This problem was so hard that server distributions did not even propose it at first, and it would be very error prone if you didn't know what you were doing (losing your data in the process). I saved countless servers professionnally, being the only one knowing what to do. Because I actually scripted all the mounting of LVM on software RAID on Linux (NFS too) before even udev, when you had to create the right devices by hand. People like me who actually used sysvinit and perfectly know the Linux boot process welcomed systemd like a saviour it was.

Here is the big flaw of sysvinit, and one of the reason sysvinit on Linux is a disaster and a design flaw from the start. And the reson I never took these so called "veteran Unix users" seriously.
There are two big problems:
- sysvinit is port of an init that was running on System V Unixes that had 32 bit PID while Linux, though having 32 bit PID today, still by default run with 16 bit PID (or is that 15 bit?)
- The System V Unixes were just designed to crash once their PID limit was reached, while Linux recycle its PID
And sysvinit was designed for, guess what, System V Unix, and just ported like that to Linux.
Back in the day, one of the first Unix admin courses told us about the malware like the fork bomb, which would crash the system. On Linux, it can go on and on, and you're forced to power cycle. But most importantly, on Linux, you reach the limit fast, and then when your PID start recycling, which happens a lot on high workload servers, all things have the potential to break, very badly. sysvinit was not designed at all to deal with recycling processes anyway, nor with double forking daemons. Some malwares use these flaws to try to replace other daemons and gain privileges.
Thanks to systemd, we have now countless of these disastrous bugs truly taken into accounts and at least people try to mitigate them in the Linux kernel. Thus why pidfd and now even 32 bit PID (which I activated on all my OS already), not counting lots of other bugs in the Linux kernel fixed thanks to systemd.
Now, Linux on the server is no longer a disaster waiting to happen, all Linux admins can rejoice I think, as soon as the distros start implementing these by default. sysvinit held us back long enough, I was desperate to see any other init catch on, even when systemd appeared, to save us from this abomination that is sysvinit. Today I can't be more than happy at the turn of event, systemd saved Linux from this disaster.

This is supposing that everyone master shell scripts and the notion of session. In the professional world, I only encountered one professional admin that had enough skills and understanding of init process to write correct scripts. Professional sysadmins would launch scripts directly under the process user or not, not realizing why it would lead to disaster. They never understood this process execution environment thing. And you're asking these people to right correct scripts? I'm talking professionals here.
I always had to modify proprietary daemons scripts which were all broken, every Java daemons all broken, had to do migration scripts that worked in KSH on every single different Unix at the time (even IRIX, and if you know the Unixes, you know how broken most of their tools are, you understand the pain of doing that right, some admins were outright instaling GNU tools directly on their Unix)...
Just reading ./ I see most systemd detractors are fools that have zero understanding of shells, init and Linux, that try to pass as knowledgeable but it's obvious they don't know what they're talking about, even the so-called "veteran Unix admins". I've met countless Unix admins, that mocked me at the time for my Linux OS, but I was correcting HACMP scripts finger in the nose while it was magic to them, remaking my own script tools instead of using the automatic scripting tools on AIX, Solaris and HP-UX. I remember when one was locked out of an admin console for a big iron Z80 IIRC, and I told him I could log him in without even knowing the password, which I did (hint: they were basically Linux custom desktops): he couldn't believe it.

Your utopia is just that, an utopia. In the real world, there is no way sth that didn't repair itself spontaneously in decades will happen just because you say it. Most of what you say I tried decades ago and it doesn't work anyway. When truely knowledgeable people like the systemd devs (from whom I even learned some things) or distro maintainers (who take all the bug reports and see the disaster first hand) look at the landscape, there's just no choice nowadays.
And no decent (in my view) sysadmin would recommand sysvinit, I realized how bad it was in less than 3 months. Perhaps you need to actually build an OS from scratch to realize that though. It's invaluable knowledge though, and required to even write good init shell scripts.

It's very refreshing to find a fellow true seasoned sysadmin that know what he's talking about, not like all these so-called "true Unix sysadmins" that apparently don't know what they're talking about, and constantly appear in these systemd threads.
I had every single one of the problems you had with sysvinit scripts, and more. In my professional time as a sysadmin, of the tens of sysadmin I've worked with, only one understood these enough to know what he was doing. I've never encountered another one. We are actually a few that master these things, and those that understand the nightmare that they are (especially security nightmares) usually choose another better solution.
I very rapidly fled from sysvinit for my own servers, going for years with simpleinit-msd before trying the one from Ubuntu, then I was one of the first to use systemd, which was amazing to me as soon as I read the promise. In the professional world, I had to harden tons of initscripts, coming from anywhere, the worst ones usually came from the proprietary app vendors.
As they receive the bug reports, I have no doubt the distro maintainers got every single instance of problems back to them. That's why I knew systemd would please the maintainers. Clueless people against systemd don't understand what makes life easy for the maintainers actually solves problems they probably never had but still could happen.
Debian networking handling was abysmal all these years before systemd, you couldn't change the network configuration from a distant session without completely locking yourself out of the server unless you knew perfectly what you were doing.
Or once we had a server completely crashing out, because after a reboot (perhaps after a firmware update), the hardware decided to present the network cards in reversed order, completely destroying a configuration that worked for years. Sysadmins were completely at lost at what happened, they called me and I found the problem in 10 mn.
These systemd threads are the perfect example of Dunning-Kruger effect in action. All these anti-systemd folks are so ridiculous, and they pretty much all show they have zero knowledge or understanding of sysvinit scripts reality.

I'm also a JRPG fan and I believe I'm living in reality, and I also play on Wii U.
And the Wii and Wii U have the best JRPG games I've ever played (Xenoblades, Tokyo Mirage #FE). If you're a JRPG fan, PS4 or Vita are NOT the consoles you want. You'd better have a Nintendo 3DS for JRPG if you only want one, and PS4 is the worst of all (if not the Vita). Even a PC is better than those now that the JRPG makers have made their games available on GOG and Steam.
PS3 had some interesting ones, which is why I had a PS3 as a support for the Wii.
But I bought no PS4 in support for the Wii U, and the Nintendo Switch will have the few JRPG (Persona 5) that could make the PS4 interesting, in addition to the Nintendo Switch already being a JRPG heaven before it's even out.

To me it was obvious from day one that this "news" did not make sense. It doesn't on so many technical levels (like assuming the nameserver being one root server for all .kp, though it is never explicitely said).

One more attack against NK, completely oblivious to reality.
Everything that goes out about NK in western media is only pure propaganda, and it's clearly apparent, when on every news about NK, nobody dares saying anything against this propaganda, everything is exactly one voice of conspiracy theories like "this one or that one have been killed surely" like it's a fact.
Despite every single one of the stories like this one having been proven to be completely false.
It's terrifying to see people react like they were in the same despotic regime they believe NK is, because they know they are.
The only thing that protects NK from destruction by the USA like many other countries, is their nuclear weapons and China's support.

If you insist on calling this a bug, unfortunately for you, that means it is a kernel bug, and more specifically a btrfs bug. And there are three workarounds :
- managing the mount manually, which is the most sensible thing to do as all your braindead operation was manual anyway;
- fixing btrfs so that it reports degraded fs as degraded, and not as dead;
- making a user space daemon that manages btrfs, like for LVM;
The most stupid thing to do is to shoot the messenger systemd, and of course, that's what most system illiterate people like you do.
And they advertise their lack of knowledge on forums to really show people how stupid they are, instead of educating themselves.

Like most systemd opponents, you don't know what you're talking about and it's instantly showing.

It shows that you're not understanding *anything* technical, when the link you gave contradicts what you said in the same sentence. The systemd journal is doing append-only plain text logs that are readable even when heavily corrupted. One difference with other logging tools, is that systemd actually informs you when your logs are corrupted. If you even understand logs and know their history, they were always designed to not advertedly affect the OS, so that performance was always the primary goal before reliability, thus why syslogd with UDP and the like. The log system should not put your system to a halt like it did on btrfs because btrfs, well, is just not production ready yet. They actually did that because a systemd user did a bug report. A true sysadmin with a true problem, not an ignorant whiner on a forum with no understanding of Linux.

That's a false statements at several levels. The first false statement is saying "systemd supporters", framing it as a political choice. Actually, "systemd supporters" are "systemd users" that know what they are talking about practically not just in theory, and most of the time the opposite camps are people that don't know of what they are talking about. Most of them are completely computer illiterate, or at least don't understand anything about system administration, and they're instantly spotted. The second false statement is saying that "systemd users" are mostly concerned with the desktop. That's plain nonsense, and even someone who is computer illiterate understands that Linux distributions like Debian and RHEL are not mostly concerned with the desktop and still switched to systemd, and are not going back any time soon.
The systemd approach is very simple : always tell the admin when sth is going wrong. Most sysadmins have a staggeringly low technical level, I discovered this years ago.
They didn't have to care before, because their broken setups where working most of the time by chance, but spectacularly broke at times. And these people were unable to even understand why their setup was wrong, because with sysvinit and all kind of broken helpers, problems where put under the rug and nobody was aware of anything going wrong unless they went deep looking in the logs. systemd shows them their setup was broken, and doesn't silently ignore errors like sysvinit and shell scripts did. That's why all these people are mad at systemd which shows their bad skills (that they advertise on forums, being so illiterate) and claim that servers don't need systemd, because, you know, hardware or network never breaks on their servers.
Every competent sysadmin (and distro ones are among them) has had to fight an impossible battle to make things work most of the time with sysvinit, not a single one of them will claim that all was working with sysvinit. I sure don't, even though I customized lots of servers, like the ones that say all was working well, and then contradicting themselves by saying they can't modify init scripts anymore.

This is a perfect illustration of what I said: philosophical debate to counter technical things. What is the "UNIX way"? There's no clear technical definition.
Anyway, we don't care on Linux, as Linux is not UNIX, and never worked the UNIX way.
Anyway, you don't even have to use this mount utility, and the most important thing is that whining about it won't change anything anyway.
And systemd is not an OS, but that's the kind of things computer illiterate people do.

That's your opinion, that's not mine.
The basic purpose of mammals is passing on their genes.
If a man rapes a woman, violently or not, he may destroy her ability to pass on the best genes she can by messing with her ability to reproduce.
A man who raises children that aren't his own is completely denied the ability to pass on his genes, it's even worse than rape on a woman.
If he's married, it's even worse, as the initial goal of marriage with a wirgin woman, is to assure the husband that he provides for his genes, so it destroys completely any marriage vow.

I agree with that, especially in our times where males even marry women who already have kids and don't want any more.
It's sad to see so many emasculated men in western societies.