Exactly. It was since the 1980s where you could wait, and something that was needed would get a price cut. Now, we are getting the same performance, except increased prices and less reliability. Due to tariffs, I had to FOMO a bunch of upgraded, which I'm glad I did, because they are now 2x the price.

IMHO, this pricing hardware to oblivion isn't going to help the hardware guys. It just means the apps that run on that platform wither to no consumers buying them, and some other platform, perhaps Chinese RISC-V boards or computers becomes the developer hotbed.

I wouldn't be surprised to see the market for Linux based gaming consoles like the Steamdeck start opening wider, if only because the hardware can be made relatively cheaply.

IMHO, for the high prices of some of those units, I'd rather pay for a fridge that is a multi-fuel fridge (uses absorption cooling, and can run the burner from electric) and have that. This way, if there is a long power blackout, the fridge can run from natural gas or propane, with the only thing needing electricity is the light inside.

For this price, I can buy a Mac and go into Mac gaming... ...oh wait.

But still, when console prices wind up this high, it only will hurt the software sellers because fewer people will be buying consoles, diminishing the audience of their games.

I would say SOE is eating their seed corn. You want inexpensive consoles so you can sell stuff for them. Basic razor and blade marketing.

Is there anything bad with using Entra with AWS, assuming phish resistance, CA, and other stuff is set up in a sane manner?

Of course, my biggest gripe about Entra is that it is one basked that secures a ton of eggs, and if someone compromises that basket, entire governments can be compromised.

The one thing I like having with any critical authentication is FIDO2, webauthn, or a phishing resistant authenticator that does a biometrics check. Even my back tier social media accounts have PIV protection on them, to resist account takeover. As a failsafe, Google TOTP, which is not phish resistant... but it is an extremely solid security measure other than that.

I'm starting to see some decent stuff that if used correctly helps. Microsoft PIM is a good thing. Azure's P2 auth in general isn't bad. I just wish this could be the standard across the board.

Now that this helps with authentication, as well as authorization, it becomes an issue of assigning who to what and what fences. For example, a user can have access to GA... but it may require someone else to "turn a key" to allow them to have it.

Since the Mac Pro is gone, can we get an XServe instead? There are still a number of business cases where Macs that are easy to rackmount without needing special third party stuff are important. Of course, one can toss a number of Mac Minis onto a shelf, but that isn't really enterprise tier.

XServes were one of the best 1U servers made. Ironically for a time, Apple was #1 in the storage front because companies used those combined with rebranded Promise arrays, until Apple decided to not bother with the enterprise.

If it were actually designed that way, there would be a hardware switch or jumper on the back, defaulting to OFF. If a user wants that stuff, they can go and enable it themselves. If a user wants to turn that on, say for some cool offers, they can. Otherwise, no.

Definitely. Virtually all "smart" TVs always lag behind, so why even bother. Instead, I use HDMI or a similar port and use a decent set-top system like an Apple TV to do the job "right". In fact, I don't have any interest in giving a TV an Internet connection at all, just so their screenshot uploads are blocked. However, with stuff like Amazon Sidewalk where a neighbor's IoT device can allow another device to connect without user authorization, that option may be fading fast.

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.