Yeah, never use a work device for anything you’re not actually getting paid to do. To do otherwise is just stupid. Save non-work stuff for your own devices.

Sounds like all the meetings should just be done by video and nothing would be lost.

Yeah it’s 50/50 because the executives really don’t like it, but the actual data supports remote work being far more efficient. They’re working really hard to cook the books to make it look like the opposite to appease the execs but they can only do so much. Give them a few more years to cherry-pick data and bury inconvenient results and they’ll be back to the same bullshit that justified productivity destroying (but cheap) choices like hot desking and open plan offices.

Quality programmers are a finite resource. Amazon chewed through the entire unskilled labor market with their warehouses and then struggled to find employees to meet their labor needs. If they try the same stunt with skilled labor they’re in for a very rude awakening. They’ll be able to find people, but only for well above market rates. They’re highly likely to find in the long run it would have been much cheaper to hang onto the people they already had.

That would run face first into proprietary info and corporate classified info.

Behold all the fucks I do not give. If it’s that critical they lose all claim to being proprietary. It’s just like patent, there’s no such thing as a secret patent, so anything that safety critical doesn’t get to stay secret either.

Regulation won’t detail what a company does to that level. They might say something like “fasteners shouldn’t come loose” but it wouldn’t have a torque spec.

It doesn’t now but it’s utterly trivial to fix that. Just make the regulations say that components must meet the manufacturer specifications and require manufacturers to publish and maintain all the specifications of all safety critical components. If they want to keep it secret then that means it’s not safety critical and they’re responsible for any accidents resulting from its failure.

It’s OK for manufacturers to say using aftermarket parts voids the warranty, it’s not OK for them to prevent using them entirely. Likewise if there’s a safety concern that should be handled by regulation and things like safety inspections, not by forcing all repairs to go through the manufacturer. If whatever it is is that critical to the safe operation it should be publicly documented so that third parties can manufacture it correctly to the needed tolerances.

It’s because layering doesn’t really gain you anything so it only has downsides. It’s important to differentiate encryption and hashing from here on since the dangers are different.

With hashing, layering different hashing algorithms can lead to increased collision chance and if done wrong a reduced entropy (for instance hashing a 256 bit hash with a 16 bit hashing algorithm). Done correctly it’s probably fine and in fact rehashing a hash with the same algorithm is standard practice, but care should be taken.

With encryption things get much worse. When layering encryption algorithms a flaw in one can severely compromise them all. Presumably you’re using the same secret across them all. If the attacker has a known piece of input or can potentially control the input a variety of potential attack vectors open up. If there’s a flaw in one of the algorithms used that can make the process of extracting the encryption key much easier. Often times the key is more valuable than any single piece of input because keys are often shared across many encrypted files or data streams.

Banks usually have the absolute worst password policies. It’s typically because their backend is some crusty mainframe from the 80s that limits inputs to something absurdly insecure by today’s standards and they’ve kicked the upgrade can down the road for so long now that it’s a staggeringly monumental task to rewrite it all. Thankfully most of them have upgraded at this point, but every now and then you still find one that’s got ridiculous limits like a maximum password length of 8 and only alphanumeric characters (with no 2FA obviously).

Trimming whitespace from the start and end of a password is fine but you absolutely should not remove whitespace from the middle of a password.

The rest of that sentence is important. Hashing passwords is the minimum practice, not best practice. You should always be at least hashing passwords. Best practice would be salting and peppering them as well as picking a strong hashing function with as high a number of iterations as you can support. You would then pair that with 2FA (not SMS based), and a minimum password length of 16 with no maximum length.

A KDF is not reversible so it’s not encryption (a bad one can be brute forced or have a collision, but that’s different from decrypting it even if the outcome is effectively the same). As long as you’re salting (and ideally peppering) your passwords and the iteration count is sufficiently high, any sufficiently long password will be effectively unrecoverable via any known means (barring a flaw being found in the KDF).

The defining characteristic that separates hashing from encryption is that for hashing there is no inverse function that can take the output and one or more extra parameters (secrets, salts, etc.) and produce the original input, unlike with encryption.

That’s a pepper not a salt. A constant value added to the password that’s the same for every user is a pepper and prevents rainbow table attacks. A per-user value added is a salt and prevents a number of things, but the big one is being able to overwrite a users password entry with another known users password (perhaps with a SQL injection).

Hashing passwords isn’t even best practice at this point, it’s the minimally acceptable standard.

Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.

CEOs have very little to do with the failure or success of most large companies. If they work very hard they can pull a company out of a death spiral, or start it down one, but failure or success takes years if not decades of steady improvement or decline. All the examples of “failures” given in the article are terrible and don’t demonstrate at all that those CEOs were bad.

One of the worst problems with businesses in the US currently is this culture of fetishizing CEOs. They’re paid far too much for what they actually bring to companies, and people grossly exaggerate how much of an impact CEOs have on companies. If you want proof of his just take a look at literally any company Elon Musk is a CEO of. The fact that none of those companies (particularly Twitter) have filed for bankruptcy yet shows exactly how little a truly terrible CEO actually impacts things.

Honestly the article is bullshit. It’s right, but for all the wrong reasons. Intel isn’t failing because it failed to buy OpenAI or partner with Apple. Intel is failing because they’ve made shit design decisions on their chips, sat on their laurels when they were riding high and just raised prices (giving up the engineering lead to AMD and TSMC), and then utterly fumbled the responses to multiple public failures when things started to go down hill.

LLMs are basically just really fancy search engines. The reason the initial code is garbage is that it’s cut and pasted together from random crap the LLM found on the net under various keywords. It gets more performant when you ask because then the LLM is running a different search. The first search was “assemble some pieces of code to accomplish X”, while the second search was “given this sample of code find parts of it that could be optimized”, two completely different queries.

As noted in another comment the true fatal flaw of LLMs is that they don’t really have a threshold for just saying " I don’t know that" as they are inherently probabilistic in nature. When asked something they can’t find an answer for they assemble a lexically probable response from similar search results even in cases where it’s wildly wrong. The more uncommon and niche your search is the more likely this is to happen. In other words they work well for finding very common information, and increasingly worse the less common that information is.

But not really. The Settings menu has never been as useful as Control Panel and there’s still a ton of functionality that can only be accessed from the Control Panel. This and many other moves by MS recently are why Windows 10 is the last version of Windows I’ll be using. With the work Valve has done to support SteamDeck I can finally go 100% Linux.

SteamOS is based on Arch with customization by Valve to make it immutable and a few other tweaks. In theory Valve will release SteamOS Holo (the version used on SteamDeck) for usage on Desktop at some point, but that hasn’t happened yet. In the meantime you can achieve very similar results to SteamOS a variety of ways. Depending on if you care about immutability or not there’s a number of non-Arch distros and even a install script (astOS) that can install Arch configured in an immutable fashion similar to what SteamOS does. There’s also a number of non-immutable gaming focused distros the most prominent of them being Manjaro. Any of them once you install Steam will function very similar to each other and SteamOS.

For now. If enough of the market shifts to Linux those companies will support Linux. Particularly since the CrowdStrike fiasco has spurred Microsoft to crack down on kernel level access which means the days of anti-cheat rootkits are numbered. It’s not going to be long before there’s no functional difference between gaming on Windows and gaming on Linux.