I'm surprised to hear that. I have never read Applied Cryptography, but I find that an incredibly damning simile (though maybe it wasn't intended to be?). Didn't Schneier develop Blowfish?
I stand by my comment, however harsh it may seem. Some of the disdain held by cryptographers, especially of a certain generation, is in no doubt a reaction to Schneier's prominence in the public eye as Mr. Crypto. The fact that he is highly quotable and media-savvy makes him a go-to person whenever a comment is needed on something (anything!) happening in security.
Going off of the press release, it doesn't go into effect until 120 days after publication and doesn't apply to current senior executives which are defined as "workers earning more than $151,164 annually and who are in policy-making positions." I would also imagine that it will immediately be challenged in court.
I was under the impression that workers earning less than $151,164 annually usually don't have noncompetes anyway? Sounds like a lot of people will get bucketed into "senior executives" group. At least new noncompetes can't be created.
Non competes are everywhere. Famous case with Prudential Security[0] where they had everyone sign non competes, that includes minimum wage workers, and they enforced them, which put an outsized strain on the minimum wage workers in particular.
That's the motivation behind this rule. About one in six food outlets were demanding non-compete terms in employment, to prevent their employees from quitting to work for higher-paying outlets.[1] (Not McD and Burger King; mostly the smaller ones.)
I absolutely agree, but I make it a point to mention their limits of enforceability whenever I can because it is information worth spreading for those worried about one.
A stay on the ruling could happen, but that would be up to the courts. Not a lawyer, but considering that there could be damages from the removal of non competes and someone leaving to get another job, there could be a stay on the order rather than letting it go into effect. While it works its way up the court system.
These are web browsing statistics. Basically nobody does significant amounts of browsing from a Steam Deck.
But even if they did, the install base of the Steam Deck is far too small to move the needle here. The install base of desktop and laptop computers is billions of devices vs. millions for the Steam Deck.
I think you're missing the connecting lines here: with the Steam Deck, Valve made significant investments into WINE emulation and Proton development and all of those dependencies needed for its product that are also applicable to desktop. That convinced a lot of people who were using Windows just for gaming to make the switch, and they all browse the web. I'd argue those types are most of the new users we've seen coming to Linux in the last few years even - and I'd attribute all of it to Valve.
For instance this year I gutted my windows install down to a 20GB partition after moving one game I play over to Linux at a time and testing it works for a while.
Guess what... I did this after I purchased a steam deck and saw how much better proton and wine are.
It depends how far you stretch "because of the Steam Deck". Sure, people aren't doing much web browsing because of the Steam Deck. How many people gave it a try because Valve decided to go with it for the Deck? How many people have been enabled to stick with it because of the technologies Valve developed for the Deck (proton and gamescope come to mind)?
Looking at the Statcounter report, it explicitly excludes mobile devices and separates out ChromeOS. I'm guessing that Statcounter uses UA strings and it is conceivable that HTTP requests are happening outside of explicit web browsing.
Their data source is the analytics JavaScript that webmasters install on their sites. Non-browsing HTTP requests are unlikely to target pages with those scripts installed, and even less likely to download and run them.
Hmm, I am not a Steam Deck user, but I have Valve to thank for being able to switch to Linux.
What kept me from it was the fact that I couldn't reliable play my gaming library on it. Thanks to the efforts they put to improve things with WINE/Proton, I could happily switch to Mint around a year ago, and couldn't be happier with it.
When Valve announced the Steam Deck, I decided to bite the bullet and move from Windows 10 for gaming and MacOS for personal use and development to a unified Arch KDE Plasma desktop. I now also have a steam deck, which makes for a nice, consistent experience when traveling with it and docking in desktop mode. It certainly made me realize that gaming on Linux was viable, which allowed me to discover that the entire OS was not only usable but provided a better experience than I had on Windows or Mac. So you can attribute at least one conversion, and that was before I ever picked up a steam deck. I have been happily using Arch with KDE since the second half of 2021 now.
It bothers me on a regular basis that there is no RFC 3339 acceptable way to include date and time in a file name in Windows as a colon is a special character. I also wish you could use hyphens in the date while ignoring the colons and still be ISO 8601 compliant, for example 20230831T1510-0500 is compliant and can be used in a filename, while 2023-08-31T1510-0500 (and similar variants) is not. As an aside the "Get-Date" function in PowerShell doesn't understand the first timestamp without the hyphens and colon.
I hadn't realised that there was a problem with Windows. MacOS has a different problem with a colon in a file name. For two of the three most popular operating systems to have this problem does show a distinct lack of thought.
I was underwhelmed to discover that this is simply a list of extensions (currently at 73) that exist in both the Chrome Web Store and Firefox Addons and not some sort of cross-platform support.
One of the main purposes was to make developers lives easier so you can have a single codebase instead of juggling with browser specific APIs and configs. Otherwise many developers would just go with a market default.
The biggest problem I found is that Chrome Manifest V3 requires background.service_worker (they removed background.scripts), while Firefox Manifest V3 requires background.scripts (they never implemented background.service_worker)
You can generally have a common background.js file, maybe with a few conditionals, but the manifest.json file needs to be different for Chrome and Firefox.
I decided to keep two foo-manifest.json versions in a manifest/ subdirectory, and copy one to ../manifest.json depending on which browser I'm testing. It's a bit tedious. Not sure if a better solution exists.
> The biggest problem I found is that Chrome Manifest V3 requires background.service_worker (they removed background.scripts), while Firefox Manifest V3 requires background.scripts (they never implemented background.service_worker)
> I decided to keep two foo-manifest.json versions in a manifest/ subdirectory, and copy one to ../manifest.json depending on which browser I'm testing. It's a bit tedious. Not sure if a better solution exists.
Personally, I favor having a build step that produces the final manifest. The basic idea is that you have a common manifest.json + paired down browser-specific files that override the general settings as necessary. It's not a perfect solution, but I think it makes maintenance a bit easier.
"Years" is overstating it a bit; Vulkan's SDK came out a little more than a year and a half after Metal was available on iOS and 8 months after it was available on Macs.
