> this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily saying they're gonna come for everyone else's job too, and you have the hyperscalers taking up every bit of oxygen in the room.
I hear these complaints multiple times per day. Not just "nearly daily". The backlash has long since drowned out the original source. The ad nauseam anguish has been steadily increasing for months.
I almost prefer to listen to asshole CEOs at this point. At least they have more to say than just repeating these same points.
Being dismissive of AI panic is healthy. What you're engaging in is not.
That depends entirely on how much needs to be downloaded for each round trip.
A lean website can work just fine on complete trash connections like GPRS or Comcast without incremental loading. Web developers are not incentivized to make lean websites.
SPAs add unnecessary complexity -> increasing page weight -> making finer grained incremental loading more important -> requiring even more code. It's a self-induced problem.
As a corollary, McMaster Carr is often used as an example of a website that didn't fall into the SPA trap, and customers greatly benefit from that [1]. The front page weighs about 14 MB with all of the images, but the loading experience is great even with network throttling simulating a poor connection. There is a good reason the site has this reputation.
Overengineering is the true root of all evil. Web developers cannot learn that fast enough.
Not the GP, but to me this case feels like extortion.
I have the same problem with paying for extensions like Dark Reader, DeArrow, and any ad blockers. None of these apps should exist in the first place. They were created because the default state of the web is barbaric. And some developers have the gall to charge for the luxury of making the experience tolerable?
But they’re saying it feels like extortion. The problems of the web aren’t the fault of those extension developers, nor can they do anything about it besides trying to mitigate it. It’s in our best interest that they can do so sustainably, meaning charging for it. It’s not gall, they’re fighting it for themselves and making the solution available for all.
That comment places a lot of blame where it doesn’t lie. It’s like calling surgeons extortionists for having the gall to charge for treating you. Yes, ideally that should be free and available to all, and perhaps if those people had the freedom to choose (e.g. having their own needs met so they didn’t have to work) they would do it. But that’s not how the system is setup, and their skills don’t translate to fixing the problem at the root. Not all of us are cut out to be politicians (and as we all know, being well-intentioned as one still doesn’t mean you have the power to enact policy).
The definition of extortion is the coercion of money in "exchange for protection", where the threat to be protected against is typically perpetrated by the coercer. I'm not using the term in the literal sense, as if an antivirus software firm is producing computer viruses. Thus, this case "feels like extortion", not "we are being extorted". (It may as well be advertising firms selling ad blocking software because the net effect to the end user is the same, but I digress.)
FWIW, I don't consider surgeons to be extortionists. That's an absurdity that you are using as illustrative of why I'm wrong to call software developers extortionists when they charge for a privilege that should be a right. There are two issues with the comparison: 1) I did not call software engineers extortionists (but sure, I can see how you drew that conclusion), and 2) people absolutely should have a right to life-saving surgery and should not be denied on the basis of payment.
There is a huge preexisting problem: health care is not a human right [1]. There are other issues with health care that isn't just money. Many life-saving transplant patents are stuck in a wait list, for instance, and many die waiting. I do what I can. I'm a registered organ donor and try not to destroy my liver. I just haven't died yet, and I still need it. But this line of reasoning is off in the weeds, and I won't pursue it further.
Perhaps what it comes down to is that you have a pro-capitalist outlook, and I have They Live sunglasses.
> FWIW, I don't consider surgeons to be extortionists.
Of course, that’s the point of the comparison. If I thought you thought surgeons were extortionists I wouldn’t have used the example because it wouldn’t have served to illustrate the point.
> But this line of reasoning is off in the weeds, and I won't pursue it further.
Indeed, that strayed completely away from the point. This has nothing to do with healthcare.
> Many life-saving transplant patents are stuck in a wait list, for instance, and many die waiting.
I know. I’ve made that point in a sibling comment hours before your post.
> It’s like calling surgeons extortionists for having the gall to charge for treating you. Yes, ideally that should be free and available to all
What do you mean by "should be"? Surgery is free and available to everyone. So why would one accuse surgeons of being extortionists? So I am not sure how the surgeon comparison works. That example supports the parent commenter's point that these extensions should be free.
Of course, there is still the practical question of who will do the work and how they will make a living. We can do what we do for surgeons. Maybe have a nonprofit consortium that people fund, so that it can support the extension developers. Yes, people would be spending money either way, but at least that money would be going toward a larger cause. Just like we pay taxes so the government can fund surgeons, who can then treat people.
I meant “would be”. Not that I think it makes that much difference here.
> Surgery is free and available to everyone.
That’s definitely not true worldwide. I think if you stop for a minute you can come up with at least one country. And even in those where it is free in public hospitals, it’s not uncommon for some to have a waitlist of years to the point you can die before it even happens. Also, did you know there are places where they don’t even have hospitals, let alone surgeons? The world is a big place, lots of disparity.
> So why would one accuse surgeons of being extortionists?
Even given all that, I think if you engage with the argument in good faith and steel man it instead of nitpicking, you’ll understand the point and can come up with your own example to satisfy you. Just pick a job you can’t do and have to pay for someone to fix something which wasn’t your fault or the fault of the other person. I believe you’re a smart person and could surely come up with something with little effort.
> there is still the practical question of who will do the work and how they will make a living.
That’s… The point. Especially for programmers, how many of us would do this shit for free, full time and beyond, for the sole purpose of benefiting others, if we had the opportunity to because we didn’t have to worry about basic needs? A large number. Way less than the number of programmers in the world right now, and that’s a good thing.
> Maybe have a nonprofit consortium that people fund
Fantastic idea. Are you doing it? Can you? Do you know where to start? And if you can’t, is that your fault? Should you be blamed for it? Are you an extortionist? Do you have gall for not doing it?
All fair points. Sorry, I spend a lot of time on regional forums, and I had a brain malfunction and forgot that when I write on HN, I am writing on a worldwide forum. Sorry for the unnecessary nitpicking.
Re non profit, I do donate to a few nonprofits I like, like those working on fediverse and my favorite langs. But I don't know of anything that does this for extensions. I'd have definitely voted with money if something was there. So, yeah, no, I am not doing anything to start a nonprofit for extensions. You have a good point.
> I do donate to a few nonprofits I like, like those working on fediverse and my favorite langs.
You already do more than most, and I commend you for it.
> So, yeah, no, I am not doing anything to start a nonprofit for extensions. You have a good point.
To clarify, the idea here was in no way to put you on the spot. Rather, what I’m saying is that none of us are doing so and that it’s not really fair to blame anyone for it. Most people don’t know how or don’t have the skills or inclination, and that’s understandable.
On the extreme end, a web app can do all of its own rendering in a canvas with WebGL/WebGPU. Some apps do exactly this: Figma, Google Maps, Google Docs. Just to name a few. (edit: Earlier I claimed PDFjs uses canvas, but it does not. I was confusing it with Google Docs [1].)
It's a thing you can do. But it is very bad for extensions and extension developers for the same reasons that Java applets, Flash, and Shockwave were bad for the web. These apps are difficult for end users to customize. It's a real bane to tinkerers. And it's a shame that "view source" has slowly grown completely useless over the decades.
Why are HTML5/JS games so much laggier and buggier than Flash games?
Maybe it's not due to differences in the technologies used. I can imagine it's because less people make these games and spend less time per game to optimize it. Years ago there were thousands of flash games of each genre, a lot of them very well made, likely optimized for speed, pure works of art. Now I see the same 100 HTML5 games on all the sites, maybe reskinned a bit. I don't think we'll ever have in terms of quality as what was available on Kongregate or Armor Games.
I might download an old browser with Flash and some games. Years ago there was a collection of a few TB of Flash games, hope it's still around. Maybe some games that required network will not work, but most didn't.
Why are HTML5/JS games so much laggier and buggier than Flash games?
I’m not sure that’s actually the case.
Steve Jobs argued in his “thoughts on Flash” letter that Flash was too buggy, insecure and resource-hungry for mobile platforms. I worked on Chrome around that time and the Flash plugin was definitely one of the biggest sources of problems.
I think all the stuff you’re complaining about is to do with business models and not really anything to do with the technology. I reckon if Flash were still around we’d probably be in much the same place we are now. People would be complaining about restaurant menus being written in Flash instead of plain old HTML, etc etc.
I played Flash games 10-15 years ago on a 15 year old computer. I've tried HTML5 games on a 5 year old computer with a good CPU and lots of RAM, yet the experience doesn't compare at all. I doubt I'm looking through things with rose-colored glasses. I think I remember some games lagging, like if you'd spawned 1000s of enemies in a Tower Defense-type game, but that was very rare.
It's still likely that older games had more users so were optimized while newer games for Desktop don't have even 1% of that userbase since most people use a smartphone for simple games.
The electricity rates in the SF Bay Area are astronomical primarily because PG&E is trying to pay off the fire damage and deaths they have been causing regularly since 2015.
In my opinion, the company is a colossal disaster. But more importantly, CPUC is complicit, bordering on incompetent [1]. Our regulatory commission is not in the business of protecting utility consumers.
Using these electricity rates as an example of where rates are going because datacenters are being built in those areas is wild! The rates have essentially nothing to do with datacenters.
> If you can confuse or buffer overflow the FS process by sending it messages, you can then edit state inside that process you weren't supposed to be able to access, and as that process controls the security system for everything it's game over.
The assumption here is that the FS is the root of trust for the kernel. (A claim I consider dubious, but what do I know about knowing things?) It's another way to say that if you don't harden your root of trust, you're SOL. Which, ok, fair enough. But that's frankly irrelevant because hardening the root of trust is table stakes. The system cannot be secured without it, regardless of the threat model.
All of the concerns about a definition of "getting hacked" falls out of ignoring the hardening of the root of trust. I don't wish to put words in your mouth, but my interpretation of the argument is essentially, "we can't have nice things because the root of trust cannot be hardened sufficiently to prevent all intrusions."
Iff the FS is the root of trust, and it is not possible to confuse the FS by sending it messages, then there is no game over. You have a root of trust that cannot be broken.
> Microkernels have no way to stop this, which is one reason very few operating systems move the core FS out into a separate process.
My reading of the history reaches a very different conclusion. First, the primary reason that very few operating systems in practice use a microkernel design is because Linus Torvalds believed it was too slow for early 90's hardware [1]. And everyone else just does whatever Linux is doing.
Second, security through surface area reduction (and more broadly, defense-in-depth) was always the point of the microkernel design [2]. Trivially, the principle of least privilege is how one arrives at a secure system. Monolithic kernels, to this very day, continue to prove that they cannot be secured in any practical manner. I can only assume we need things to get worse before kernel developers will tighten up and take security seriously.
> So you might as well just run it in-kernel and reap the performance benefits.
There's that same mentality. Apparently "speed at all costs" is the willful trading of security for performance. That position is just as flawed as trading essential liberty for temporary safety [3]. It doesn't matter how fast the thing is when the slightest bump always causes it to explode, killing everyone on board.
Ah, I'm not saying we can't have nice things or build more secure software. I think we can build more secure software! But the argument I'm responding to is one that I've seen many times over the years on HN and elsewhere, which is some form of "capability based programming languages fix everything". It's always posited as obvious and easy, as if merely saying "capability based language" is the only explanation required and somehow the entire software industry just missed the memo. Sometimes microkernels often come along for the ride, but not always.
You're completely right that the root of trust has to be secured. I argue that the core filesystem is indeed a part of the ROT, which is why e.g. Apple has put so much effort into making it immutable and fully tied to a cryptographic root hash that's checked by the secure boot process. Moving the FS out of the core kernel wouldn't change much though - if you have a bug in your FS code at runtime then you're just SOL even if everything is arranged in a Merkle tree.
The argument being made by josephg in the sibling comment is that in SEL4 or similar the page cache would be separated from the crypto code. And maybe he's right, but the better way to get the same outcome is to not have IPsec in the kernel rather than not have the core FS - as the latter is a ROT and IPsec isn't.
I disagree that the question of what "getting hacked" means is a reformulation of trust roots. A threat model isn't the same thing as a root of trust. The argument over what appears to be minor semantics is important because it scopes your goals and effort. One of the most common failure modes I've seen in security projects is not defining a threat model up front, often leading to an automatic fallback to "the threat model contains everything" followed by despondency and failure when it turns out to be impossible.
I don't think Apple or Microsoft care much about Linus' opinions tbh. Both NeXT/macOS and Windows NT started out as microkernel designs and all of them have oscillated back and forth over the years. The original concept was indeed far too slow and a lot of functionality went back to monolithic. Then over time some functionality got lifted back out e.g. the GUI subsystem on Windows. Core FS remains though in any OS as the cost/benefit ratio of moving it is so poor.
> "capability based programming languages fix everything"
There is some truth to this idea, though. Setting aside the unsafe boundary, (FFI, direct MMIO access, etc.) a capability system in a programming language would solve some kinds of these problems. Not all; it doesn't solve logic bugs when a capability is in scope.
> It's always posited as obvious and easy
I do believe it's probably pretty obviously true, by now. But not at all easy.
> Moving the FS out of the core kernel wouldn't change much though - if you have a bug in your FS code at runtime then you're just SOL even if everything is arranged in a Merkle tree.
Perhaps, but that's only because traditional file systems are global state. A capability system turns that notion on its head specifically because global state is really the problem. The combination of capabilities and user mode file access would be quite a strong isolation boundary. The bug(s) would have to be "trivially flawed" in a way that these subtle exploits are not.
> A threat model isn't the same thing as a root of trust.
Ah, I didn't say that. I said (roughly) that security relies on a strong root of trust for every thread model. I think the distinction is important. They are not the same, but the thread model can be completely ignored (because it doesn't matter) until the root of trust is secured. In other words, a weak root of trust fails all threat models.
> I don't think Apple or Microsoft care much about Linus' opinions tbh.
True. macOS and NT are (or were?) "microkernel-ish" the last time I was in those weeds. No idea how they've evolved since.
You've made some good points, as well. I see where you are coming from.
We agree that a properly sandboxable capability-capable (ugh, lol) language would indeed be a really good security upgrade. I was sad when the SecurityManager died for that reason, even though the reasoning was very understandable.
But those claims have also got to be moderated. As no such thing has ever existed, we can't truly know how well it'd work in practice. Only experience can tell us that.
Global state is one of the key issues. Joe-E simply banned it, which is far too harsh and breaks almost everything. Mobile operating systems locked down filesystem access behind permissions and capabilities quite dramatically and were much more secure, but that came with a lot of 'vigorous' debate over owner control and power for productivity/pro-grade applications. macOS has taken an incremental approach and sandboxes off parts of the FS from apps whilst retaining what looks on the surface like a classical global shared state $HOME and / directory (although it's not).
macOS, iOS, Android and Windows have all been steadily moving code out of the kernel over the years. Apple doesn't run the core FS in a userspace process but every other FS that's not as performance sensitive is now a userspace daemon, for instance. They developed their own FUSE equivalent to do this. In Windows a lot moved out in Vista. Graphics, audio, printing, a lot of drivers are out of kernel now.
Linux has lagged behind quite badly in this respect partly because a microkernel design requires close cooperation between userspace and kernel space but the Linux design philosophy is that the kernel is a self-contained artifact.
reply