This should, (but won't), highlight the failure of processes.

Even with the supposed need to manage the fridges & freezers remotely, safe guards can be put in place. Like others have mentioned:

* Don't connect anything directly to the Internet, unless its purpose is for the Internet. Like a shopping site.
* Use a VPN gateway, with changing credentials. Including changing the credentials early when staff leave.
* Make the remote access Read Only by default.
* Have authorized onsite personal verify requests for remote R/W access. Then they, (onsite), enable such for a limited time, like 1 hour to update firmware.
* Allow onsite personal to return access to R/O by request. Thus, shutting down R/W access when remote work is complete.

That does not cover the actual firmware, which should have a good, solid team behind it:
* Planned features, bug fixes or security fixes should be discussed by original vendor.
* Code review before testing to make sure it should do what the new code should accomplish.
* Testing for both original features and the new code, (feature, bug or security fix).
* Staged roll out. Don't send it everywhere at once. This kind of code should have a prior version good enough to allow at least a week for roll out of new code.

I am sure their are 100 things that could make this better.

It has been a long time coming, but the time is at hand. We will have our new Pig-Human Overlords to rule us. They will either rule from afar, or take over our bodies by further combining our 2 superior species. All hail the new Pig-Human Overlords!

I know some have been waiting / wanting their new animal totem hybrid humans to be our new Overlords. They are now to be the Pig-Human Overlords! Animal & human hybrids will accomplish everything, you can take my word for it. Pig-Human is the future for us!

Thank you.

While I am up to 6.18 on my desktop, it's only 6.18.18, so it will need another update. The others, (laptop and media server), will need a jump to a new kernel series. They are all older kernels.

Also use Gentoo. Everytime I think it's too much work to trouble shoot a problem, I figure it out and make the updates better. Now Gentoo updates run pretty much problem free. Even when they do go south, I use ABEs, making recovery brain dead simple: Boot the prior OS. (ABE = Alternate Boot Environment, basically keep the old OS prior to the update around until I decide to delete it...)

One thing that has made a difference in my Linux updates, is to use a second boot environment. It could be a 2nd OS partition, 2nd LVM, or a BTRFS snapshot. I've used both the 2nd OS partition and BTRFS for that function. They worked perfectly, though obviously the 2nd OS partition doubled the OS disk usage, while BTRFS only increased usage based on the amount changed. Even tested the LVM method, which worked for testing. Note you can't really use LVM snapshots for this purpose, as they are not meant to be kept for weeks or months.

With updated Grub entries, this allows booting the old OS without the updates.

So the process would be:

1. Create new boot environment, (BTRFS supports more than 2). Or prepare the alternate partition or LVM for the update.
2. Mount up the alternate boot environment.
3. Perform the update to the ABE.
4. Update Grub to boot this new BE by default.
5. Prompt use that a reboot is now needed to activate the update.

All of that can be automated as part of the update, (well, even the reboot if that is what the user wants).

No user likes a broken update. Especially when it is something he/she may not understand as well as MS-Windows. Further, while MANY, MANY Microsoft Windows updates had problems, they generally were so obvious and got enough attention that when a fix was available, users were able to implement it soon. Without much poking around and Internet searching.

The inability to leave an via an automated path, reminds me of the short story "Intent to Deceive" by Larry Niven. In it, customers in an automated restaurant can't leave due to a fault in computers. Not even paying customers. They had to wait until the place closed, (as I recall).

Of course, their was Intent to Deceive in the story, as well as cannibalism, along with robots gone wild. Larry Niven had such a range of abilities.

Actually the second company WAS Sun Microsystems. The first company, where I originally worked, was StorageTek, which had 3 Class A sub-nets.

At the time Sun acquired STK, Sun had 2 Class A sub-nets, as far as I remember. Thus, the extreme desire by the North American IP allocating authority to claw back as much as they could. So, when it was all done, Sun did not end up with 5 Class A sub-nets. Not sure how many Sun had to give up, but if I remember correctly it was at least 2. When we transferred all the STK servers to Sun that were to be kept, they all ended up with 10.x.x.x IPs. Or one of the other internal only reserved IP ranges.

A while back I worked at a company that had 3 public Class A IPv4 sub-nets allocated to it. They obviously got them early on, but ended up using all of them, including in one instance for phone home devices, (well, network send home). After a few years working there, that company got bought by an even larger company. This other company had at least 2 public Class A IPv4 sub-nets, and was one of the original users / founders of the Internet. (You have three guess, just don't cheat and look up during the day...) Of course trying to get those 3 Class As ownership transferred to the new company found that the organization that handled IP allocations, wanted to claw back some of those Class As. I mean, what company needs 5 public Class A IPv4 sub-nets, that is not an Internet service provider?

If you understand what that means, I don't have to tell you. But, for others, their are 24 million IPv4 addresses in a Class A sub-net. To be fair, it can't be broken down too far. But, in theory, you can TONS of Class C sub-nets out of a Class A. Each of those Class Cs could be allocated to a different company, country or individual. Like 64K Class C sub-nets out of a Class A, (in theory).

Any way, we got to the IPv4 shortage because the Internet was not designed for the future. Nor was IPv4 sub-net allocations done in a forward thinking mode. Thus, NAT at home, NAT at work, NAT at a much larger scale.

In reality, companies don't need public IPs inside their own networks. In fact, it could be considered a security breach to use such. So a company could have a simple public Class C at each location for external access. Or even just a few IPs at smaller sites. However, no one knew this Internet thing was going to take off in the way that it did.

Over the last 10 years it has become quite apparent that really active development does not belong in the Linux kernel source tree.

As an example, BTRFS has started to stagnate in development. Nothing really ground breaking has happened with BTRFS. In someways, it is a dead file system and headed for the scrap heap, (note I said SOMEWAYS). I personally used BTRFS, both because it was supposed to be the replacement for EXT3/4, had data integrity features, plus snapshots. Even went so far as to write up a local procedure to use snapshots as alternate boot environments for distro updates. That worked VERY well and I had little to no problems. But, after years and years, BTRFS never stabilized, so I moved on.

In my opinion, part of the problem stems from the requirement that the kernel module match user land code, for things to work right. Any kernel update may end up requiring matching user land updates of the file system utilities, (which might also require updated libraries!). Have both user land and kernel module developed out of the Linux kernel source tree is actually a benefit, (again, in my opinion). BTRFS or BCacheFS can then support a range of kernels, and yet still make kernel update requests to add new features, or fix odd behavior. Maybe eventually getting stabilized to the point of releasing source into the kernel.

One disadvantage of this software development method, is that new Linux kernels need to be added. But, in reality, that always had to be done. So the disadvantage is that a user of BTRFS or BCacheFS using out of kernel tree development would have to wait on any kernel update until their file system has been both updated and tested with the new kernel.

The 600 series terminators had rubber skin, but the 800 used artificial blood and skin to pass as human. Sweat, bad breath, everything. Very hard to spot. So this blood is the first step for Skynet's best infiltration unit! The world is ready to be destroyed!

I welcome our new overlord - Skynet, (please don't kill me!).

I welcome our new overlords of silicon and brain!

They will take humanity beyond the fragile flesh bags and bones that we are now. Then transport us to the stars in new ships that don't need all the extra life support such flesh bags & bones need. After all, our new overlords will be minds made up of pure circuits and neurons, controlling whatever mechanical body is needed. We shall thrive as trillions of a new homo-superior species! All life's mysteries will be revealed when we no longer have flesh & bone bodies!

All hail Homo-Superior of circuits and neurons!

How dare you! I am offended, I tell you highly offended! You should weep with the misery you have caused!

Everyone KNOWS their are other Distros that don't include the malware SystemD!
Slackware and Devuan are not the only ones!

I know, because I use the far superior Gentoo.
(Okay, it's not "far" superior. And maybe not even superior... Fine, I'll admit it, Gentoo is a right pain in the butt at times.)

Gee, if it has better properties than steel, can we build space ships out of InventWood?

Image a space ship built in orbit using standard carpentry tools, like saws, miter boxes, drills and screws. Caulk the joints with air tight material and then, line the inside with air tight plastic sheeting, you then get a breathable module. Or better yet, find a air tight stain, and use attractive finishes on the hull.

True, you would probably still want metal hatches and hatch surrounds, due to the constant use. And there would be other metal components, perhaps some joist hangers or L brackets.

Oh, maybe even add some solar sails for propulsion. Gee, we could even send out a wooden space probe to the next star system!
Make future aliens, (or humans), wonder how we made such!

No one has yet mentioned the hostile neighbor to Finland. I blame them for killing trees. After all, we have proof beyond reasonable doubt that they kill innocent people. So it is not a stretch to find them liable for tree killing.

Of course I can't mention that hostile neighbor's name. They are known to be very aggressive and vengeful. But anyone not living in a cave knows who I mean.


And even some living in a cave have internet, thus know current events. Like ME! Have not seen sunshine in years! (Well, I see the light from sunshine at my entrance. Just don't go out in the highly skin cancerous giving radiation from the Sun.)

I was surprised that the hatred for ZFS was not more obvious. Many times when ZFS is brought up, people hop on to say it's not good because of: Not using GPL; Not built in to Linux kernel; Violates storage layering; Does not have the features desired, (not that those "features" are common elsewhere); etc...

On the other hand, BTRFS is not close to feature parity with ZFS. Neither BCacheFS nor Hammer(1/2) is even close to BTRFS, let alone ZFS. All 3 have far too much development & testing time needed. I wish them well because competition makes everything better. Yet at present, few things can compete with ZFS.


For me, I have an old FreeNAS Mini, and a newer built small AMD Epyc, (with 10Gbit/ps Ethernet), both running TrueNAS. Plus, use external disks for cold backups / storage, with ZFS to detect bit rot. And yes, one old disk occasionally has bit rot, though since it's a backup, not much of a problem.

The old Sun Microsystems' SunFire SC, (System Controller), was hit with a Microsoft broadcast chatty protocol, that crashed the SCs. This was about 2003 or later, if I recall correctly, (I worked at Sun at the time). While Sun fixed that bug, and probably others related to that problem, Sun started recommending that SCs, (and RSC, ALOMs, SP, etc...), be put on isolated sub-nets that only management servers are allowed to access. This was of course before the degradation of SC / SP / BMCs with web interfaces.

That advice to isolate SP / BMC network interfaces, and certainly not put them on the public network, still applies today.


I mean, who would allow their SP / BMC to be remotely hackable?

Some computer forums have people asking how to access their SP / BMCs from the internet. Really? But, to be fair to some requesting how to make that happen, they want to use a VPN, which probably helps with the security.


Of course, the bug in BMC firmware today is probably not the only one. Just wait, another will be found. Thus, back to isolated network for SP / BMCs...