With the news coming in, seeing articles about Bat Boi isn't something that isn't too bad these days.

Maybe getting overrun by infernal creatures (think Doom 2, except with no Doomguy) might be a better fate than the indifference we see now.

This reminds me of a project. I can't find any info on it, but it was called PhonebookFS. You had a directory full of encrypted chunks, and you would use an encryption key to mount layers of it. Even if you knew all the passwords to each layer, there was randomly generated chaff in every repository for plausible deniability.

Now, imagine that for phones. One PIN might get you to your work's stuff. Another PIN, your personal contacts. A third PIN, a "clean" account that is intended to be scoured. None of the accounts know about each other, and there is some TPM like chip that if "x" amount of bogus PINs are entered, will quietly deny access to everything else but the least secure for a period of time, or even erase those account keys.

A duress code would be nice. However, instead of a factory reset, it would do something like screw up the ECC on the flash drive or do something to make it look like a hardware fault happened, where any data extracted from the device would be poisoned or unusable.

I am still surprised that most authentication mechanisms other than a few safes, don't have a duress ability. For example, jacking people for their phones is a common thing. Having the ability to type in a duress code which would make it look like the info was present, but protected the user would go a long way.

For remote logins, a duress code would be useful, which would allow the user to log in... then a few minutes later, they get kicked off, or even just tarpitted, where the social media account may spent minutes to just allow a single page click, or spend a long time refreshing things. For company networks, it could allow the user to show shares on machines that have disinformation.

I prefer the statically linked model, just because it means less stuff that can go wrong. A binary that runs on Debian will run on RedHat. Yes, some stuff like libc may be an issue, but with static linking, anything above that should be there in some capacity.

It also allows easier use of backported libraries. For example, if a library is tested, audited and certified, it can be critical that it, at that specific version, be included, and not a newer one, as a newer one may introduce bugs that were not present in previous revs.

Both models are valid, be it the Python way of doing things where one has the libraries on the system, or the Rust way of doing things where just what is needed is included. I personally prefer the Rust way, because it has a smaller attack surface, and it is a compiled language, so performance is better.

A number of years ago, I would scoff at a Chinese EV, for a few reasons (all IMHO):

1: China watching where I am 24/7.

2: Parts/service? What's that?

3: Kill switches built in.

4: Oddball or worthless UI/UX.

Well, as time has gone on, IMHO, the companies have lowered stuff. Watching where people are going is now common across makes. Same with kill switches to disable vehicles. Parts? One specialized board is the difference between a working vehicle and scrap metal. UI/UX? A number of makes refuse to use common sense standards like Android Auto or Apple CarPlay. Now add on the price premium that one pays in the US. Between tariffs and other things, the US pretty much subsidizes the worlds' car industry.

For example, the BYD Shark, a serial hybrid truck that only RAM is able to have something similar... and the REV isn't out yet.

Now add the price differences. People can't afford to pay upwards of six digits for a modest vehicle.

Maybe we should go one up and also move to a web of trust, perhaps with some defaults ready to go or even pre-checked of people who are good BS detectors? This way, it is a system that can't easily be seized by one party, unlike the hierarchal system of SSL/TLS based PKIs we have now.

SAP could buy SUSE and use it to create a complete stack, perhaps with HANA.

Each has a different take. RHEL is popular, but Ubuntu has been taking a lead over it since Ubuntu is very popular and tends to have newer tools to build on, while RHEL tends to be enterprise focused and fixes backported to it. Oracle Linux is a downstream of RHEL, and it works just as well as RHEL, but there is a lot of apprehension about Oracle Linux. It would (IMHO) be nice if Oracle ported official ZFS (TM) to Oracle Linux and supported it, or just adopted OpenZFS as the flagship standard.

SUSE is a solid alternative, enterprise quality, and overall a solid fit for a company.

You would be surprised where SUSE is used. It is used as an enterprise operating system in a lot of companies. It works well, and even though it is a RPM based OS, it is not a RHEL downstream.

It is used everywhere, a lot in the US, and has a lot of management capability. It also has a SMIT-like management tool.

Because SUSE is European, it really needs to be kept going as a viable distribution on an enterprise level. Otherwise, sovereignty is at risk. Ideally, some multi-national NGO can be made to handle SUSE patching, as well as OS design for future specifics. On one hand, this needs to be open that people can find bugs and patch quickly. On the other hand, it needs to be very much focused, so it doesn't languish in committee. For example, RHEL is moving towards an immutable Linux model, and it might be wise to consider that route, just as another layered defense against malware, or perhaps have the OS bring up a hypervisor and proceed to load the rest of the system in KVM or Xen, as a way to keep desktop items from being able to do rogue firmware flashes.

SUSE needs to be well maintained, because it is one of the top three enterprise operating systems out there.

This is of similar usefulness as the MacBook made in 2016, with the m3 CPU (not M3, Intel m3). It wasn't a screaming machine by any means, and it only had one USB port... but it was good enough for most things, like basic Web apps, PowerPoint, Excel, etc.

I am thinking about the Neo + the TouchID scanner upgrade.

The Neo is about the cost of a decent tablet, offers decent functionality, a USB dock can be added so it can be plugged into a basic keyboard and monitor setup. This is ideal for taking a personal PC with the business laptop on a business trip. (I always keep my personal stuff on my own device.)

For this, it is ideal, and if it gets lost or stolen, iCloud Lock provides a decent defense of the data present combined with benefit denial.

Is this better than an 11" iPad? I prefer the 11" iPad with a keyboard because it is easier to wrangle, and some laptop cases have a spot for a tablet. The tablet is definitely more secure, with its built in cellular connection. However, the restrictions on workflow on a tablet compared to a desktop OS can get annoying.

All I ask is that they keep old repositories around forever. I've seen some repos lost, like PhonebookFS, which could be really useful these days.

PhonebookFS was a FUSE mounted filesystem that had multiple layers. Mount one layer, get a different set of files than another layer. Even then, there was a bit or random sized "chaff" which was not owned by any layer in the PhonebookFS, providing plausible deniability.

Another advantage is that if one buys movies on DVD, they cannot be taken away from them. This isn't DIVX (not the codec.) Blu-Ray is still iffish on what movies are copyable and which are not, but DVD is good enough, and can easily play offline if one has a player for it.

I just hope Apple doesn't mess it up. I prefer an information-dense UI, like how Windows 2000 was, pre XP/Luna. However, with the push for the same UI for tablets as desktops, I worry Apple will make the same mistake MS did with Windows 8 and 8.1.

What annoys me is that there is a huge market need for iPods. I used to ship them with every user, pre-provisioned in the Mac MDM and ready to be used as an additional device for 2FA authentication. If someone lost their phone, they could still get into their company account, without having to use a YubiKey.