I do think the techie / scifi sensibility plays a lot into all this. But the cosmos doesn't owe anything to the fantasies of scifi authors (or the linguistic particulars that make one tech sound more like "the future" than another one, like batteries).
Information tech played out much differently than 20c scifi pictured it. Same for transportation (incl. space flight and cars).
..when we started seeing how lithium-ion powered cars were performing vs fuel cell vehicles, and doing the math on their relative efficiency.
As for Toyota, I think their fallout with A123 Systems (re: the latter's battery patent) defined not just Toyota's but the Japanese attitude in general toward BEVs. There seemed to be a reckoning over there that they just weren't going to be able to compete with the US or China on battery tech. I even think this pro-H2/anti-battery mood contributed toward the ouster of Nissan's CEO, Carlos Ghosn, who brought the Leaf BEV to market.
As someone who has long championed BEVs as superior, I feel somewhat vindicated in reading about Toyota's FCEV flop, especially when people cite long refueling times (a weakness of BEVs). But I will also say that I thought BEV "fast charge" was a dead end and that the future would be swap-able battery packs allowing "re-fueling" in just a few minutes. I still think that makes sense for the future, and I can see how car mfgs would start supporting swap-able "booster" packs which could eventually lead to cars that use 100% swap-able batteries. Otherwise, the Chinese model for battery swap might also take hold. Finally, I think swap-able batteries call for an industry 'surplus' of battery stock that would be queued for re-charging at optimal time-of-day at refueling stations... this would act as a big enabler for intermittent renewable energy (over and above what V2G provides) as consumers would feel less pressure to plan the charging of their cars at certain times of day (and less pressure to find charge points and keep their cars attached to the grid).
Yeah, but most people probably should have something like first-party isolation enabled anyway. That would prevent the targeted site in the iframe from accessing any cookies or cache that is available when the target domain is displayed in the Location Bar. The attacking site would see a "you're not logged in" version of the target site... https://www.ghacks.net/2017/11...
First-party isolation (if it is turned on) should prevent "site B" identity from being accessed via cookies, because the FPI context of site A (the iframe embedder) won't have access to the cookie/cache storage that is used when site B is visible in the Location Bar. So the embedded iframe of the target site (B) would not display personal information, but instead show the page as if you needed to login.
Easiest way to turn on FPI in Firefox is to set Enhanced Tracking Protection to 'Strict' in Settings. It can also be specifically enabled via about:config.
And its not about sparing children from sexually explicit material... They are using children as an excuse to dismantle public services (otherwise, they would be requiring book stores to see ID before making a purchase, the way liquor stores do).
Where I grew up kids got underage library cards and the kids section of the library was separate. Totally un-controversial.
Distro repositories place too many burdens on app developers, FOSS and proprietary alike. There are a lot of FOSS app devs who don't want their emails filling up with demands from umpteen different Pumpkins-On-Ice distros, not to mention emails/issues from the users of those marginal distros. The fact that you have to deal with at least 5 major ones, and their maintainers are "helping" you by pelting you with "you did it wrong, please jump through these 10 extra hoops to make it work on our OS" is already a pretty bad situation.
Because when you try to cope with all that, and take the average of what they're all asking/demanding, the app devs who stick around in the environment will have a particular mindset geared to avoiding interesting features that rely on vertical integration. You will get a lot of averaged mediocrity, or at best some excellent results _decades_ after that type of app reached excellence on Windows and OS X, after those interesting integrations became ho-hum and commonplace enough to show up in most distros by default.
Snap/SnapCraft BTW is basically a new desktop platform in itself. There is no such thing as a platform-independent "run anywhere" platform. Its an OS platform which means it will make certain demands from whatever is beneath it to meet its minimum feature set. Most of the other "run anywhere" formats are only packaging systems created by people who don't know any better; they will appear more flexible to advanced users with admin skills, but largely unusable to most other people.
Here's the thing: This is the desktop. It has to have a certain level of richness, and that has to be "built-in" or standard. If you have a good desktop platform like OS X has been for many years, users will read about the rich new features and think about cool stuff they can do and often buy the Mac/PC for that reason and learn how to develop for that platform. If the platform is good, the overwhelming number of dependencies for most apps will be _inside_ the OS.
Devs do not want a multi-headed hydra of distro culture getting in the way of the creative urge, they don't want to hear they should be helping develop the OS layers or that their life would be far easier by chopping off features X and Y because they're inconvenient for 1/3 of the distros out there.
It should be rich. It should be "standard" (every install of the OS has it). That's a line that has to be walked in the the consumer space and FOSS enthusiasts refuse to walk it in the name of freedom.
My understanding of "containers" is they were originally a way to collect or organize different apps that may need different service configs or library versions. They were billed as a way to maximize hardware utilization (thus, a tool for admins or system architects).
The "VM" idea is used very loosely with avid container users, IMO. To me, VM means either a bytecode RE like Java or a hardware-enforced isolation space managed by a hypervisor Xen, KVM, etc. To these users, VM seems to mean a container-like package with extra security measures tacked-on, and that security is usually implemented rather poorly (for example, using jails or namespaces or chroot or similar). The idea that "containers" are about security and thus VM-like emerged relatively recently.
Oh, and if you say "But we need the Freedom to make all these things different because a sliver of the techie demographic and server admins like it that way"
So what that means is the Android model (which is mostly the MS and Apple model)... wins completely, and deservedly so.
I don't think the containerization idea is so bad. They often have _better_ reproducibility at runtime than traditional Linux packages, which BTW represent a sort of anti-Desktop rubric that demands a bit too much from users (who become captives of the OS vendor's repository unless they learn a lot of skills) and way, way too much from dedicated app developers (like, package your app in 8 different ways and test it in 8 different sets of lib versions and etc/env settings or you're not cool in Linux land).
Apple Macs had an early version of this container-like dependency system. An app dev could take the easy road and package all their non-OS dependencies within their own app folder... drag and drop installation. IIRC, something similar is possible with Windows msi installs (one double-clicks the msi, and most of its 3rd party dependencies go under a single folder).
So this business where we make OS maintainers the ultimate arbiter of which apps can have which libraries/versions and making installs a process of spewing the app's files all over the filesystem in hundreds of pieces.... it is not working on the desktop. Apple and Microsoft knew it didn't work way, way back. Enough is enough.
OTOH, there are at least several more large steps before using "Desktop Linux" is anything like a real consumer OS on a long-term basis. For one, having the kernel as the identity of the OS will still cause much confusion among consumers. And the not-committing-to-a-GUI is even worse (in my book, different GUI = different OS and that's how it goes down when users need tech support: on a Linux distro they are told to use the CLI almost always). And not having an official hardware certification program that licenses a special compatibility logo is also quite bad. A lot of confusion and brokenness there, and I know because I did the whole turn people on to desktop Linux for over a decade.
On brokenness: It really is broken if the GUI isn't standardized heavily, not just the graphical forms but also the responses, menus and the settings/admin integrations. In computer science, a shifting interface is by definition broken because an "interface" is a "contract" or promise for consistent interaction. Linux enthusiasts suddenly drop this idea of consistency when it comes to _user_ interfaces. Its not flying and that's why (I say this here every couple years) you cannot even GIVE it away to most people.
Someone found it before I did... (the hack is from 2008 not the 90s)...
https://yro.slashdot.org/comme...
Yep, Brad Carter did this with a tape recorder. I think it was in the late 90s.
Cactus Cactus!
Regardless of where its made, they are very carefully choosing who to ship to and who not to, because word of this obscene backlog faded from their coverage long ago.
And yes... they have my money!
Oh, yeah, someone is selling the idea that crypto is un-trackable. TBH, that sounds even worse than the old ad networks they are blocking (and replacing). No thanks, Brave.
The thing VPNs are good at is preventing your ISP (and adtech) from tracking which sites you use. ISPs sell this info now.... Oops!
Now, tell me a VPN doing business in this country, that I'm paying for, with "Private" right on the product description and no prominent ad copy stating otherwise, is going to sell my info. That would result in a big-ass lawsuit.
But a major ISP can hide behind their "many things to many people" business model. No one is going to be able to pin them down on privacy policies.
Mastodon's retention has been really good, especially considering there is no PR or marketing dept, and no manipulative algorithms that try to make people addicted to it. And they got slammed from traffic coming from a major multinational corporation, which they handled pretty well.
https://www.techdirt.com/2023/...
Someone else pointed out that Mastodon's software only tracks "new logins", so you would expect to see a "slump" as auto-logins become the norm after people get settled with a site+client.
And speaking of manipulation:
Testing can show the presense of bugs, but not their absence. -- Dijkstra
