There’s at least one decent way of handling errors and it’s how Common Lisp does it. It’s been sitting there since 1980s and I just can’t wait when it finally enters the mainstream discourse just like it was for the language’s other features.
Rust had conditions, if that’s what you’re referring to. It had some pretty serious usability issues and so it ended up being removed in favor of Result.
Also, maybe I am wrong, but I think conditions are more or less equivalent to passing down a callback that takes an error and either returns a default value, or unwinds.
This is a useful pattern in a pinch, but I don’t think it solves the rest 99% cases?
Or maybe I am misunderstanding conditions? Would love to read a blog post that discusses practical applications of the idea.
Conditions can have hierarchy, which allows for useful aggregation of failure handling. It can be as fine or as coarse as you want. Condition handlers, unlike return value handling don’t have to be call-local so one set of handlers can cover a lot of code. And unlike catch blocks conditions do not immediately unwind the stack which makes these handlers useful.
A sibling comment had mentioned restarts which are really handy when you want to recover computation without expensive reconstruction of the context.
Naturally all of that can be done in a multitude of ways and strictly speaking no language feature outside raw machine code is necessary. There is no magic to it except a bunch of smart people who sat and thought it through before implementing them. But as we talk of language design here the ergonomics are important.
A condition handler can also invoke a restart; AIUI when a function raises an error it can offer restarts to the condition handler that do things other than just calling the original function again with different arguments. Or you can view a restart like a catch block, and the condition handler can choose which catch block to unwind to.
a callback that takes an error and either returns a default value, or unwinds.
That’s just two possible restarts. A condition can provide any number of them, and they don’t have to be built-in (in fact I’m reasonably sure continue-with-value is not a standard restart, just a conventional one).
This was what my “noob” PL mind was telling me as well.
I have only matured to the point where I feel unions (options in rust I think) is good if we want a singluar value and then pattern match. As such errors are value really reasonates with me and not taking them as exceptions. (Have written lot of ruby where exceptions and errors were mixed and ran into all issues with exception handling)
The key is that you separate the process of finding the appropriate handler from unwinding the stack. Once found, the handler is called ON TOP OF the existing stack. It might then decide that unwinding is the correct response (and often does) but there is also the option of fixing things up and returning to the point of failure to retry and continue.
It’s like a page fault handler setting up an address mapping and putting either default or swapped-in data there and then retrying the instruction that trapped, instead of simply terminating the program. No one these days would dream of doing serious work on a machine that didn’t have that behaviour.
Using standard OOP features to help find the right handler is part of it, but whether you’re using C++/Java-style virtual functions or Lisp/Dylan/Julia generic functions for that is much less important.
Conditions are an improvement upon exceptions but suffer from the same issues: it’s an implicit untyped side-channel, which is trivially overbroad (although the strong expression orientation of CL and Smalltalk mitigate that somewhat).
That’s just another way to say “conditions are not return values”
No, it’s something different from that. Input arguments are part of the type of a function too, and by your reasoning “it’s just another way to say ‘conditions are not input arguments’. In Java, “checked exceptions” ARE part of a function’s signature and “unchecked exceptions” are NOT part of its signature. Being part of the function signature means (a) the property must be declared, and (b) the property is verified by the compiler. Perhaps you want those features, perhaps you don’t, but the fact that you do or don’t enforce those is an important property.
The problem everyone has with exceptions is, eventually, that they’re too powerful and too dynamic. While I appreciate that Lispers are on a higher plane of enlightenment and are more right about everything than I could possibly ever hope to be, I still can’t believe that the solution is to make them more powerful and more dynamic.
I get that they’re not the same as exceptions, but from what I’ve seen they appear to be a strict superset. They can do all the same nonlocal control flow that gives exceptions a bad name, and also some other even more nonlocal stuff, all while being impossible to reason about statically.
Some people (me, for example) complain about exceptions being a form of non-local control flow that is hard to reason about. That is one of the major problems new programming languages, like several of those listed in the article, have tried to address. I don’t know what you expect the mainstream discourse to take from Lisp here, given that they are trying to go in the opposite direction.
I’ve used C++ exceptions and Java exceptions. There is no comparison of those to the ergonomics of CL condition system. Some things are actually different.
For a long time things like automatic memory management, macros or lambdas had a lot of opponents too (and still have them), yet they were gradually adopted over the decades. It is often hard to explain why a certain feature is nice to someone who has very superficial understanding and no experience actually using them in a codebase, hence adoption is unavoidably slow.
I feel like I should create a bingo chart for Lobsters (or a certain orange site), since “Lisp solved this” (as well as “Haskell solved this”) are just classics that you see over and over again.
(Fwiw, I have no experience with continuations, but the fact that they sound a lot like exceptions makes me highly, highly skeptical. Maybe with enough static typing on top.)
What’s your marketing budget? If you aren’t aligned with the marketing budget havers on this, how do you expect them to treat you when your goals diverge?
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare. It’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
Sigh. Lobsters won’t let me post. I must be getting rate limited? It seems a bit ridiculous, I’ve made one post in like… hours. And it just shows me “null” when I post. I need to bug report or something, this is quite a pain and this is going to need to be my last response as dealing with this bug is too frustrating.
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare.
Can you tell me more about these? I think “infeasible” is not accurate but maybe I’m wrong. I don’t see how DoH consolidates anything as anyone can set up a DoH server.
t’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
You can definitely set up a webpage in 2025 pretty with HTTPS, especially as you can just issue your own CA certs, which your users are welcome to trust. But if your concern is that a government can exert authority within its jurisdiction I have no idea how you think HTTP is helping you with that or how HTTPS is enabling that specifically. These don’t feel like HTTPS issues, they feel like regulatory issues.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
There are numerous, globally distributed CAs, and you can set one up at any time.
Lobsters has been having some issues, I had the same trouble yesterday too.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s, the fact that something is technically possible doesnt matter in a world where nobody does it.
especially as you can just issue your own CA certs
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
There are numerous, globally distributed CAs, and you can set one up at any time.
That’s a lot more centralized than “I can do it without involving a third party at all.”
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
Strange but I will have to learn more.
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s
Sure, because that’s by far the easiest option and most people don’t really care about centralizing on Cloudflare, but nothing is stopping people from using another DoH.
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
iPhones being able to do that isn’t really relevant to HTTPS. If you want to say that users should be admins of their own devices, that’s cool too.
As for joking, no I am not. You can create a CA, anyone can. You don’t get to decide who trusts your CA, that would require work. Some companies do that work. Most individuals aren’t interested. That’s why CAs are companies. If you’re saying you want a CA without involving any company, including non-profits that run CAs, then there is in fact an “open” solution - host your own. No one can stop you.
You can run your own internet if you want to. HTTPS is only going to come up when you take on the responsibility of publishing content to the internet that everyone else has to use. No one can stop you from running your own internet.
That’s a lot more centralized than “I can do it without involving a third party at all.”
As opposed to running an HTTP server without a third party at all? I guess technically you could go set up a server at your nearest Starbucks but I think “at all” is a bit hard to come by and always has been. Like I said, if you want to set up a server on your own local network no one is ever going to be able to stop you.
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
Which drawbacks? I ask not because I believe there are none, but I’m curious which concern you the most. I’m sympathetic to wanting things and not wanting their consequences haha that’s the tricky thing with life.
HTTPS: I want the authentication properties of HTTPS without being beholden to a semi-centralized and not necessarily trustworthy CA system. All proposed alternatives are, as far as I know, bad.
DNS: I want the convenience of globally unique host names without it depending on a centralized registry. All proposed alternatives are, as far as I know, bad.
These kind of accusations are posts that make me want to spend less on lobsters.
Who knows if it’s planned or accidental obsolescence? Many devices and services outlive their teams by much longer than anticipated. Everyone working in software for a long while has experienced situations like those.
I also find the accusation that HTTPS is leading to broken devices rather wild…
I want to offer a different view: How cool is it that the devices was fixable despite Google’s failure to extend/exchange their certificate. Go, tell your folks that the Chromecast is fixable and help them :)
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
The world where we’re thinking it’s cool that these devices are fixable tidily neglects the fact that 99% of the people out there will have zero clue how to fix them. That it’s fixable means practically nothing.
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
Who cares? No one is defending Google. People are defending deploying HTTPS as a strategy to improve security. Who cares if it’s Google or anyone else? The person you’re responding to never defends Google, none of this has to do with Google.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
Who cares? Also, there is a very obvious 3rd option - that competent people can make a mistake.
Nothing you’ve said is relevant at all to the assertion that, quoting here:
This is the future the “HTTPS everywhere” crowd wants ;)
Even though you’re quoting me, you must be mistaken - this post is about Google, and my response was about someone who is defending Google’s actions (“Who knows if it’s planned or accidental obsolescence?”).
I haven’t a clue how you can think that a whole post about Google breaking Google devices isn’t about Google…
To the last point, “https everywhere” means things like this can keep being used as an excuse to make fully functional products in to ewaste over and over, and we’re left wondering if the companies responsible are evil or dumb (or both). People pretending to not get the connection aren’t really making a good case for Google not being shit, or for how the “https everywhere” comment is somehow a tangent.
Take what you want from my employment by said company, but I would guess absolutely no-one in private and security has any wish/intention/pressure to not renew a certificate.
I have no insider knowledge about what has happened (nor could I share it if I did! But I really don’t). But I do know that the privacy and security people take their jobs extremely seriously.
This isn’t about who you criticize, I would say the same if you picked the smallest company on earth. This is about the obvious negativity.
This is because the article isn’t “Chromecast isn’t working and the devices all need to go to the trash”.
Someone actually found out why and people replied with instructions how to fix these devices, which is rather brilliant. And all of that despite google’s announcements that it would discontinue it..
This is the future the “HTTPS everywhere” crowd wants ;)
I’m not exactly sure what you meant by that, and even the winky face doesn’t elide your intent and meaning much. I don’t think privacy and security advocates want this at all. I want usable and accessible privacy and security and investment in long term maintenance and usability of products. If that’s what you meant, it reads as a literal attack rather than sarcasm. Poe’s law and all.
Not all privacy and security advocates wanted ‘HTTPS everywhere’. Not all of the ‘HTTPS everywhere’ crowd wanted centralized control of privacy and encryption solutions. But the privacy and security discussion has been captured by corporate interests to an astonishing degree. And I think @gerikson is right to point that out.
Do you seriously think that a future law in the US forcing Let’s Encrypt (or any other CA) to revoke the certificates of any site the government finds objectionable is outside the realms of possibility?
HTTPS everywhere is handing a de facto publishing license to every site that can be revoked at will by those that control the levers of power.
I admit this is orthogonal to the issue at hand. It’s just an example I came up with when brewing some tea in the dinette.
In an https-less world the same people in power can just force ISPs to serve different content for a given domain, or force DNS providers to switch the NS to whatever they want, etc. Or worse, they can maliciously modify the content you want served, subtly.
Only being able to revoke a cert is an improvement.
Holding the threat of cutting off 99% of internet traffic over the head of media companies is a great way to enforce self-censorship. And the best part is that the victim does all the work themselves!
The original sin of HTTPS was wedding it to a centralized CA structure. But then, the drafters of the Weimar constitution also believed everything would turn out fine.
They’ve just explained to you that HTTPS changes nothing about what the government can do to enact censorship. Hostile governments can turn your internet off without any need for HTTPS. In fact, HTTPS directly attempts to mitigate what the government can do with things like CT logs, etc, and we have seen this work. And in the singular instance where HTTPS provides an attack (revoke cert) you can just trust the cert anyways.
edit: Lobsters is basically completely broken for me (anyone else just getting ‘null’ when posting?) so here is my response to the reply to this post. I’m unable to reply otherwise and I’m getting no errors to indicate why. Anyway…
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
This is getting ridiculous, frankly.
You’ve conveniently ignored everything I’ve said and focused instead of how a ridiculous attack scenario that has an obvious mitigation has 4 words that somehow you’re relating to SCOTUS and 1st amendment rights? Just glossing over that this attack makes almost no sense whatsoever, glossing over that the far easier attacks apply to HTTP at least as well (or often better) as HTTPS, glossing over the fact that even more attacks are viable against HTTP that aren’t viable against HTTPS, glossing over that we’ve seen CT logs actually demonstrate value against government attackers, etc etc etc. But uh, yeah, SCOTUS.
SCOTUS is going to somehow detect that I trusted a certificate? And… this is somehow worse under HTTPS? They can detect my device accepting a certificate but they can’t detect me accessing content over HTTP? Because somehow the government can’t attack HTTP but can attack HTTPS? This just does not make any sense and you’ve done nothing to justify your points. Users have been more than charitable in explaining this to you, even granting that an attack exists on HTTPS but helpfully explaining to you why it makes no sense.
In the near future, on the other side of an American Gleichschaltung, a law is passed requiring CAs to revoke specific certificates when ordered.
If the TLS cert for CNN.com is revoked, users will reach a scary warning page telling the user the site cannot be trusted. Depending on the status of “HTTPS Everywhere”, it might not be able to proceed past this page. But crucially, CNN.com remains up, it might be accessible via HTTP (depending on HSTS settings) and the government has done nothing to impede the publication.
But the end effect is that CNN.com is unreadable for the vast number of visitors. This will make the choice of CNN to tone down criticism of the government very easy to make.
The goal of a modern authoritarian regime is not to obsessively police speech to enforce a single worldview. It’s to make it uneconomical or inconvenient to publish content that will lead to opposition to the regime. Media will parrot government talking points or peddle harmless entertainment. There will be an opposition and it will be “protected” by free speech laws, but in practice accessing its speech online will be hard to impossible for the vast majority of people.
If the USA apparatus decides to censor CNN, revoking TLS cert wouldn’t be the way. It’ll be secret court orders (not unlike recent one British government has sent to Apple), and, should they not comply, apprehension of key staff.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
And my comment is not defence of Google or Cloudflare, I consider both to be malicious for plethora of reasons.
You’re still thinking like the USSR or China or any totalitarian government. The point isn’t to enforce a particular view. The point is to prevent CNN or any other media organization from publishing anything other than pablum, by threatening their ad revenue stream. They will cover government talking points, entertainment, even happily fake news. Like in Russia, “nothing is true and everything is possible”.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
Nothing is preventing the US from only allowing certs from US based issuers. Effectively, if you’re using a mainstream browser, the hypothetical law I have sketched out will also affect root CAs.[1]
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
[1] note that each and every one of these attempts to block access will have quite easy and trivial workarounds. That’s fine, because as stated above, having 100% control of some sort of “truth” is not the point. If nerds and really motivated people can get around a block by installing their own root store or similar, it will just keep them happy to have “cheated the system”. The point is having an atomized audience, incapable of organizing a resistance.
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
The flags are me and they’re because your posts have been overwhelmingly low quality, consisting of cherry picking, trolling, rhetoric, and failing to engage with anyone’s points. You also never proposed any such attack, other users did you the favor of explaining what attack exists.
The closest thing you’ve come to defining an attack (before others stepped in to hand you one) is this:
Holding the threat of cutting off 99% of internet traffic over the head of media companies
It’s not that interesting why you’re getting flagged. IMO flags should be required to have a reason + should be open, but that’s just me, and that’s why I virtually always add a comment when I flag a post.
This is one of the only posts where you’ve almost come close to saying what you think the actual problem is, which if I very charitably interpret and steel-man on your behalf I can take as essentially “The US will exert power over CAs in order to make it hard for news sites to publish content”. This utterly fails, to be clear (as so many people have pointed out that there are far more attacks on HTTP that would work just as well or infinitely better, and as I have pointed out that we have seen HTTPS explicitly add this threat model and try to address it WITH SUCCESS using CT Logs), but at least with enough effort I can extract a coherent point.
I have around 30 flags right now in these threads (plus some from people who took time off their busy schedule to trawl through older comments for semi-plausible ones to flag). You’re not the only one I have pissed off.[1]
(I actually appreciate you replying to my comments but to be honest I find your replies quite rambling and incoherent. I guess I can take some blame for not fully cosplaying as a Project 2025 lawyer, instead relying on vibes.)
It’s fine, though. I’ve grown disillusioned by the EFF style of encryption boosting[2]. I expect them to fold like a cheap suit if and when the gloves come off.
[1] but I’m still net positive on scores, so there are people on the other side too.
[2] they’ve been hyperfocussed on the threat of government threats to free speech, while giving corporations a free pass. They never really considered corporations taking over the government.
Hm, I see. No, I certainly have not flagged all of your posts or anything, just 2 or 3 that I felt were egregious. I think lobsters should genuinely ban more people for flag abuse, tbh, but such is the way.
It’s interesting that my posts come off as rambly. I suppose I just dislike tree-style conversations and lobsters bugs have made following up extremely annoying as my posts just disappear and show as “null”.
I’ve been getting the “null” response too. There’s nothing in the bug tracker right now, and I don’t have IRC access. Hopefully it will be looked at soon.
As to the flags, people might legitimately feel I’m getting too political.
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
The point of this hypothetical scenario would be that the threat of certificate revocation would be out in the open, to enforce self-censorship to avoid losing traffic/audience. See my comment here:
I’m not sure any of those are good examples of planned obsolescence. As far as I can tell, they’re all services that didn’t perform very well that Google didn’t want to support, tools that got subsumed into other tools, or ongoing projects that were halted.
I think it’s reasonable to still wish that some of those things were still going, or that they’d been open-sourced in some way so that people could keep them going by themselves, or even that Google themselves had managed them better. But planned obsolescence is quite specifically the idea that you should create things with a limited lifespan so that you can make money by selling their replacements. As far as I can tell, that doesn’t apply to any of those examples.
I get that it’s a tongue in cheek comment, but this is what falls out of “we want our non-https authentication certificates to chain through public roots”.
There is no reason for device authentication to be tied to PKI - it is inherently a private (as in “only relevant to the vendor” , not secret) authentication mechanism so should not be trying to chain through PKI, or PKI-like, roots.
Why is this a hyperbole? It is clear that even an enterprise the size of Google, famous for it’s leetcode-topping talent is unable to manage certificates at scale. This makes it a pretty good point against uncritical deployment of cryptographic solutions.
When Microsoft did that I wasn’t standing embarrassed in front of my family failing to cast cartoons on the TV. So it was their problem, not my problem.
Maybe. I think there are two ways to interpret it - “HTTPS Everywhere” means “literally every place” or it means “everywhere that makes sense, which is the vast majority of places”. But, to me, neither of these implies “you should deploy in a way that isn’t considered and that will completely destroy a product in the future”, it just means that you should very likely be aiming for a reliable, well supported deployment of HTTPS.
I was replying more to the “planned and enforced obsolescence” conspiracy theorizing.
It is true that managing certificates at scale is something not a lot of large organizations seem to be able to pull off, and that’s a legitimate discussion to have… but I didn’t detect any good faith arguments here, just ranting
We have that old Rockland FFT analyzer with failed supply to the EL backlight for some time now. Going in to see if it could be an easy fix.
Also working on integrating Modbus TCP interface to our product. For a long time we relied on middleware over our WebSocket API done by integrators to do the job. However it’s a bit of headache for everyone to have an extra party involved in every round of changes.
Sure, it’s this one. Our phone products have Modbus integration too as it’s very common requirement in the automation world. But Evacsound interface is quite a bit more elaborate.
For the past 6 months we’ve been banging our heads against APFS running out of disk space on our CI while showing 60GB free space. And I mean, it runs out of disk space hard, can’t even save the zsh history.
This started with Sonoma. Upgrading to the latest point release made no difference. The internet is littered with what looks like the same problem and the suggested fix is always to empty your trash (can’t you read, I still have tens, even hundreds of GB free, I shouldn’t need to clean my trash). My current theory is that APFS is not able to keep up with recycling some internal garbage and reports it as generic ENOSPC. Mac OS, at least from the CI perspective, is worse than Windows.
P.S. If anyone has any clue what’s going on with APFS space issue, I am all ears.
EDIT: Forgot to add, the bizarre thing is that once you login into such a machine, it’s no longer out of space and you can write as much as you need. This is the reason for my “cannot recycle garbage fast enough” theory.
I do a lot of low level filesystem development and I’ve hit this frequently. It’s like it’s caching globally some free count and it gets desynced and freaks out. Very annoying.
Nope, looked into this: there are no snapshots besides the standard few and backup is disabled. We’ve even monitored if any transient snapshots are being created during the CI run but didn’t see anything suspicious.
The only way I know of to run out of space when you have plenty of space is to run out of inodes. If logging in fixes the problem, that suggests some per-user process such as a LaunchAgent is doing something to fix the problem. And in fact there is a LaunchAgent that deletes caches (/System/Library/LaunchAgents/com.apple.cache_delete.plist), so perhaps you’ve somehow accumulated so much cache that you’ve run out of inodes? I can’t imagine what might be making so many cache files though.
Thanks for the information, much appreciated. I am not familiar with the cache files you are talking about (need to do some research) but I can tell you what we do: we compile (e.g., with Apple Clang) a large number of files and there are quite a few intermediate files being created and deleted in the process by the build system.
So we definitely don’t create any cache files ourselves but it’s possible Apple does automatically (maybe some kind of search indexing).
Another problem with the cache file theory is that we monitored disk space as the build progresses and there is always plenty of free space reported. But it’s possible APFS somehow does not count cache files towards usage.
You monitored disk space, but did you monitor inode count? If you have plenty of disk space but are getting ENOSPC then that suggests you’ve run out of inodes.
Every time this topic comes up I post a similar comment about how hallucinations in code really don’t matter because they reveal themselves the second you try to run that code.
That’s fascinating. I’d really enjoy hearing some more about that. Was this a team project? Were there tests? I feel like this would be really valuable as a sort of post mortem.
Lots of different teams and project. I am talking 30% of a 1k engineer department being feature frozen for months to try to dig out of the mess.
And yes there were tests. Tests do not even start to cut it. We are talking death through thousands deep cut.
This is btw not a single anecdote. My network of “we are here to fix shit” people are flooded with these cases. I expect the tech industry output to plummet starting soon.
Again, really interesting and I’ve love more details. I am at a company that has adopted code editors with AI and we have not seen anything like that at all.
That just sounds so extreme to me. Feature frozen for months is something I’ve personally never even heard of, I’ve never experienced anything like that. It feels kind of mind boggling that AI would have done that.
Nope. They had tested it. But to test, you have to be able to understand the failure cases. Which you have heuristics for based on how humans write code
These things are trained exactly to avoid this detection. This is how they get good grade. Humans supervising them is not a viable strategy.
I’d like to understand this better. Can you give an example of something a human reviewer would miss because it’s the kind of error a human code author wouldn’t make but an LLM would?
I’m with @Diana here. You test code, but testing does not guarantee the absence of bugs. Testing guarantees the absence of a specific bug that is tested for. LLM-generated code has a habit of failing in surprising ways that humans fail to account for.
I used AI primarily for generating test cases, specifically prompting for property tests to check the various properties we expect the cryptography to uphold. A test case found a bug.
“Those are scary things, those gels. You know one suffocated a bunch of people in London a while back?”
Yes, Joel’s about to say, but Jarvis is back in spew mode. “No shit. It was running the subway system over there, perfect operational record, and then one day it just forgets to crank up the ventilators when it’s supposed to. Train slides into station fifteen meters underground, everybody gets out, no air, boom.”
Joel’s heard this before. The punchline’s got something to do with a broken clock, if he remembers it right.
“These things teach themselves from experience, right?,” Jarvis continues. “So everyone just assumed it had learned to cue the ventilators on something obvious. Body heat, motion, CO2 levels, you know. Turns out instead it was watching a clock on the wall. Train arrival correlated with a predictable subset of patterns on the digital display, so it started the fans whenever it saw one of those patterns.”
“Yeah. That’s right.” Joel shakes his head. “And vandals had smashed the clock, or something.”
Hallucinated methods are such a tiny roadblock that when people complain about them I assume they’ve spent minimal time learning how to effectively use these systems—they dropped them at the first hurdle.
You imply that because one kind of hallucination is obvious, all hallucinations are so obvious that (per your next 3 paragraphs) the programmer must have been 1. trying to dismiss the tool, 2. inexperienced, or 3. irresponsible.
You describe this as a failing of the programmer that has a clear correction (and elaborate a few more paragraphs):
You have to run it yourself! Proving to yourself that the code works is your job.
It is, and I do. Even without LLMs, almost every bug I’ve ever committed to prod has made it past “run it yourself” and the test suite. The state space of programs is usually much larger than we intuit and LLM hallucinations, like my own bugs, don’t always throw exceptions on the first run or look wrong when read.
I think you missed the point of this post. It tells the story of figuring out where one hallucination comes from and claims LLMs are especially prone to producing hallucinations about niche topics. It’s about trying to understand in depth how the tool works and the failure mode that it produces hallucinations that looks plausible to inexperienced programmers; you’re responding with a moral dictum that the user is at fault for not looking at it harder. I’m strongly reminds me of @hwayne’s rebuttal of “discipline” advice (discussion).
Just because code looks good and runs without errors doesn’t mean it’s actually doing the right thing. No amount of meticulous code review—or even comprehensive automated tests—will demonstrably prove that code actually does the right thing. You have to run it yourself!
What does “running” the code prove?
Proving to yourself that the code works is your job. This is one of the many reasons I don’t think LLMs are going to put software professionals out of work.
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
Can you at least understand why some people are not that excited about LLM code assistants?
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
QA was always on you. If you don’t enjoy using one, don’t? If you feel that it takes your freedom and creativity away, don’t use it. I don’t use LLMs for a ton of my work, especially the creative stuff.
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
Which is at odds with the claim in the same sentence, that ‘comprehensive automated tests’ will not prove that code does the right thing. And yes, you can argue that the comprehensive tests might be correct, but do not evaluate the properties you expect the results to have, if you want to split hairs.
Evaluating code for correctness is the hard problem in programming. I don’t think anyone expected LLMs to make that better, but there’s a case to be made that LLMs will make it harder. Code-sharing platforms like Stack Overflow or Github at least provide some context about the fitness of the code, and facilitate feedback.
The article is supposed to disprove that, but all it does is make some vague claims about “running” the code (while simultaneously questioning the motives of people who distrust LLM-generated code). I don’t think it’s a great argument.
What did you think my article was trying to disprove?
It’s an article that’s mainly about all the ways LLMs can mislead you that aren’t as obvious as hallucinating a method that doesn’t exist. Even the title contains an implicit criticism of LLMs: “Hallucinations in code are the least dangerous form of LLM mistakes”.
If anything, this is a piece about why people should “distrust LLM-generated code” more!
Can you at least understand why some people are not that excited about LLM code assistants?
Because they don’t enjoy QA.
I don’t enjoy manual QA myself, but I’ve had to teach each myself to get good at it - not because of LLMs, but because that’s what it takes to productively ship good software.
I actually disagree a little bit here. QA’ing every bit of functionality you use is never going to scale. At some level you have to trust the ability of your fellow human beings to fish out bugs and verify correctness. And yes, it’s easy for that trust to be abused, by supply chain attacks and even more complicated “Jia Tan”-like operations.
But just like LLMs can be said to do copyright laundering, they also launder trust, because it’s impossible for them to distinguish example code from working code, let alone vulnerable code from safe code.
What I meant was something slightly different. Almost every piece of software that’s not a bootloader runs on a distributed stack of trust. I might trust a particular open source library, I might trust the stdlib, or the operating system itself. Most likely written by strangers on the internet. It’s curl | sudo bash all the way down.
The action of importing code from github, or even copy-pasting it from stack overflow, is qualitatively different from that of trusting the output of an LLM, because an LLM gives you no indication as to whether the code has been verified.
I’d go so far as to say the fact that an LLM emitted the code gives you the sure indication it has not been verified and must be tested—the same as if I wrote quicksort on a whiteboard from memory.
I think this post is more than just another “LLMs bad” post, though I did enjoy your response post as a standalone piece. The author ‘s co-worker figured out it didn’t work pretty quickly. It’s more interesting to me that the author found the source of the hallucination, and that it was a hypothetical that the author themselves had posed.
That’s why I didn’t link to the “Making o1, o3, and Sonnet 3.7 Hallucinate for Everyone” post from mine - I wasn’t attempting a rebuttal of that, I was arguing against a common theme I see in discussions any time the theme of hallucinations in code is raised.
I turned it into a full post when I found myself about to make the exact same point once again.
And that’s fair enough - in context I read your comment as a direct reply. I appreciate all the work you’ve been doing on sharing your experience, Simon!
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That’s why I’m wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL
bugs that happen (i.e. logic issues, race conditions, etc.)
This is an extremely strong statement.
I think a few things are also interesting:
I think people are realizing how low quality the Linux kernel code is, how haphazard development is, how much burnout and misery is involved, etc.
I think people are realizing how insanely not in the open kernel dev is, how much is private conversations that a few are privy to, how much is politics, etc.
I think people are realizing how insanely not in the open kernel dev is, how much is private conversations that a few are privy to, how much is politics, etc.
The Hellwig/Ojeda part of the thread is just frustrating to read because it almost feels like pleading. “We went over this in private” “we discussed this already, why are you bringing it up again?” “Linus said (in private so there’s no record)”, etc., etc.
Dragging discussions out in front of an audience is a pretty decent tactic for dealing with obstinate maintainers. They don’t like to explain their shoddy reasoning in front of people, and would prefer it remain hidden. It isn’t the first tool in the toolbelt but at a certain point there is no convincing people directly.
Dragging discussions out in front of an audience is a pretty decent tactic for dealing with
With quite a few things actually. A friend of mine is contributing to a non-profit, which until recently had this very toxic member (they’ve even attempted felony). They were driven out of the non-profit very soon after members talked in a thread that was accessible to all members. Obscurity is often one key component of abuse, be it mere stubbornness or criminal behaviour. Shine light, and it often goes away.
IIRC Hintjens noted this quite explicitly as a tactic of bad actors in his works.
It’s amazing how quickly people are to recognize folks trying to subvert an org piecemeal via one-off private conversations once everybody can compare notes. It’s equally amazing to see how much the same people beforehand will swear up and down oh no that’s a conspiracy theory such things can’t happen here until they’ve been burned at least once.
This is an active, unpatched attack vector in most communities.
I’ve found the lowest example of this is even meetings minutes at work. I’ve observed that people tend to act more collaboratively and seek the common good if there are public minutes, as opposed to trying to “privately” win people over to their desires.
I think people are realizing how low quality the Linux kernel code is, how haphazard development is, how much burnout and misery is involved, etc.
Something I’ve noticed is true in virtually everything I’ve looked deeply at is the majority of work is poor to mediocre and most people are not especially great at their jobs. So it wouldn’t surprise me if Linux is the same. (…and also wouldn’t surprise me if the wonderful Rust rewrite also ends up poor to mediocre.)
yet at the same time, another thing that astonishes me is how much stuff actually does get done and how well things manage to work anyway. And Linux also does a lot and works pretty well. Mediocre over the years can end up pretty good.
After tangentially following the kernel news, I think a lot of churning and death spiraling is happening. I would much rather have a rust-first kernel that isn’t crippled by the old guard of C developers reluctant to adopt new tech.
Take all of this energy into RedoxOS and let Linux stay in antiquity.
I’ve seen some of the R4L people talk on Mastodon, and they all seem to hate this argument.
They want to contribute to Linux because they use it, want to use it, and want to improve the lives of everyone who uses it. The fact that it’s out there and deployed and not a toy is a huge part of the reason why they want to improve it.
Hopping off into their own little projects which may or may not be useful to someone in 5-10 years’ time is not interesting to them. If it was, they’d already be working on Redox.
The most effective thing that could happen is for the Linux foundation, and Linus himself, to formally endorse and run a Rust-based kernel. They can adopt an existing one or make a concerted effort to replace large chunks of Linux’s C with Rust.
IMO the Linux project needs to figure out something pretty quickly because it seems to be bleeding maintainers and Linus isn’t getting any younger.
They may be misunderstanding the idea that others are not necessarily incentivized to do things just because it’s interesting for them (the Mastodon posters).
Redox does have the chains of trying to do new OS things. An ABI-compatible Rust rewrite of the Linux kernel might get further along than expected (even if it only runs in virtual contexts, without hardware support (that would come later.))
Linux developers want to work on Linux, they don’t want to make a new OS. Linux is incredibly important, and companies already have Rust-only drivers for their hardware.
Basically, sure, a new OS project would be neat, but it’s really just completely off topic in the sense that it’s not a solution for Rust for Linux. Because the “Linux” part in that matters.
I read a 25+ year old article [1] from a former Netscape developer that I think applies in part
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?
Adopting a “rust-first” kernel is throwing the baby out with the bathwater. Linux has been beaten into submission for over 30 years for a reason. It’s the largest collaborative project in human history and over 30 million lines of code. Throwing it out and starting new would be an absolutely herculean effort that would likely take years, if it ever got off the ground.
The idea that old code is better than new code is patently absurd. Old code has stagnated. It was built using substandard, out of date methodologies. No one remembers what’s a bug and what’s a feature, and everyone is too scared to fix anything because of it. It doesn’t acquire new bugs because no one is willing to work on that weird ass bespoke shit you did with your C preprocessor. Au contraire, baby! Is software supposed to never learn? Are we never to adopt new tools? Can we never look at something we’ve built in an old way and wonder if new methodologies would produce something better?
This is what it looks like to say nothing, to beg the question. Numerous empirical claims, where is the justification?
It’s also self defeating on its face. I take an old codebase, I fix a bug, the codebase is now new. Which one is better?
Like most things in life the truth is somewhere in the middle. There is a reason there is the concept of a “mature node” in the semiconductor industry. They accept that new is needed for each node, but also that the new thing takes time to iron out the kinks and bugs. This is the primary reason why you see apple take new nodes on first before Nvidia for example, as Nvidia require much larger die sizes, and so less defects per square mm.
You can see this sometimes in software for example X11 vs Wayland, where adoption is slow, but most definetly progressing and now-days most people can see that Wayland is now, or is going to become the dominant tech in the space.
I don’t think this would qualify as dialectic, it lacks any internal debate and it leans heavily on appeals by analogy and intuition/ emotion. The post itself makes a ton of empirical claims without justification even beyond the quoted bit.
That means we can probably keep a lot of the old trusty Linux code around while making more of the new code safe by writing it in Rust in the first place.
I don’t think that’s a fair assessment of Spolsky’s argument or of CursedSilicon’s application of it to the Linux kernel.
Firstly, someone has already pointed out the research that suggests that existing code has fewer bugs in than new code (and that the older code is, the less likely it is to be buggy).
Secondly, this discussion is mainly around entire codebases, not just existing code. Codebases usually have an entire infrastructure around them for verifying that the behaviour of the codebase has not changed. This is often made up of tests, but it’s also made up of the users who try out a release of a codebase and determine whether it’s working for them. The difference between making a change to an existing codebase and releasing a new project largely comes down to whether this verification (both in terms of automated tests and in terms of users’ ability to use the new release) works for the new code.
Given this difference, if I want to (say) write a new OS completely in Rust, I need to choose: Do I want to make it completely compatible with Linux, and therefore take on the significant challenge of making sure everything behaves truly the same? Or do I make significant breaking changes, write my own OS, and therefore force potential adopters to rebuild their entire Linux workflows in my new OS?
The point is not that either of these options are bad, it is that they represent significant risks to a project. Added to the general risk that is writing new code, this produces a total level of risk that might be considered the baseline risk of doing a rewrite. Now risk is not bad per se! If the benefits of being able to write an OS in a language like Rust outweigh the potential risks, then it still makes sense to perform the rewrite. Or maybe the existing Linux kernel is so difficult to maintain that a new codebase really would be the better option. But the point that CursedSilicon was making by linking the Spolsky piece was, I believe, that the risks for a project like the Linux kernel are very high. There is a lot of existing, old code. And there is a very large ecosystem where either breaking or maintaining compatibility would each come with significant challenges.
Unfortunately, it’s very difficult to measure the risks and benefits here in a quantitative, comparable way, so I think where you fall on the “rewrite vs continuity” spectrum will depend mostly on what sort of examples you’ve seen, and how close you think this case is to those examples. I don’t think there’s any objective way to say whether it makes more sense to have something like R4L, or something like RedoxOS.
Firstly, someone has already pointed out the research that suggests that existing code has fewer bugs in than new code (and that the older code is, the less likely it is to be buggy).
I haven’t read it yet, but I haven’t made an argument about that, I just created a parody of the argument as presented. I’ll be candid, i doubt that the research is going to compel me to believe that newer code is inherently buggier, it may compel me to confirm my existing belief that testing software in the field is one good method to find some classes of bugs.
Secondly, this discussion is mainly around entire codebases, not just existing code.
I guess so, it’s a bit dependent on where we say the discussion starts - three things are relevant; RFL, which is not a wholesale rewrite, a wholesale rewrite of the Linux kernel, and Netscape. RFL is not about replacing the entire Linux kernel, although perhaps “codebase” here refers to some sort of unit, like a driver. Netscape wanted a wholesale rewrite, based on the linked post, so perhaps that’s what’s really “the single worst strategic mistake that any software company can make”, but I wonder what the boundary here is? Also, the article immediately mentions that Microsoft tried to do this with Word but it failed, but that Word didn’t suffer from this because it was still actively developed - I wonder if it really “failed” just because pyramid didn’t become the new Word? Did Microsoft have some lessons learned, or incorporate some of that code? Dunno.
I think I’m really entirely justified when I say that the post is entirely emotional/ intuitive appeals, rhetoric, and that it makes empirical claims without justification.
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
This is rhetoric. These are unsubstantiated empirical claims. The article is all of this. It’s fine as an interesting, thought provoking read that gets to the root of our intuitions, but I think anyone can dismiss it pretty easily since it doesn’t really provide much in the form of an argument.
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
Again, totally unsubstantiated. I have MANY reasons to believe that, it is simply question begging to say otherwise.
That’s all this post is. Over and over again making empirical claims with no evidence and question beggign.
We can discuss the risks and benefits, I’d advocate for that. This article posted doesn’t advocate for that. It’s rhetoric.
existing code has fewer bugs in than new code (and that the older code is, the less likely it is to be buggy).
This is a truism. It is survival bias. If the code was buggy, it would eventually be found and fixed. So all things being equal newer code is riskier than old code. But it’s also been impirically shown that using Rust for new code is not “all things being equal”. Google showed that new code in Rust is as reliable as old code in C. Which is good news: you can use old C code from new Rust projects without the risk that comes from new C code.
But it’s also been impirically shown that using Rust for new code is not “all things being equal”.
Yeah, this is what I’ve been saying (not sure if you’d meant to respond to me or the parent, since we agree) - the issue isn’t “new” vs “old” it’s things like “reviewed vs unreviewed” or “released vs unreleased” or “tested well vs not tested well” or “class of bugs is trivial to express vs class of bugs is difficult to express” etc.
I don’t disagree that the rewards can outweigh the risks, and in this case I think there’s a lot of evidence that suggests that memory safety as a default is really important for all sorts of reasons. Let alone the many other PL developments that make Rust a much more suitable language to develop in than C.
It’s a Ship of Theseus—at no point can you call it a “new” codebase, but after a period of time, it could be completely different code. I have a C program I’ve been using and modifying for 25 years. At any given point, it would have been hard to say “this is now a new codebase,
yet not one line of code in the project is the same as when I started (even though it does the same thing at it always has).
I don’t see the point in your question. It’s going to depend on the codebase, and on the nature of the changes; it’s going to be nuanced, and subjective at least to some degree. But the fact that it’s prone to subjectivity doesn’t mean that you get to call an old codebase with a single fixed bug a new codebase, without some heavy qualification which was lacking.
What’s old and new is poorly defined and yet there’s an argument being made that “old” and “new” are good indicators of something. If they’re so poorly defined that we have to bring in all sorts of additional context like the nature of the changes, not just when they happened or the number of lines changed, etc, then it seems to me that we would be just as well served to throw away the “old” and “new” and focus on that context.
I feel like enough people would agree more-or-less on what was an “old” or “new” codebase (i.e. they would agree given particular context) that they remain useful terms in a discussion. The general context used here is apparent (at least to me) given by the discussion so far: an older codebase has been around for a while, has been maintained, has had kinks ironed out.
There’s a really important distinction here though. The point is to argue that new projects will be less stable than old ones, but you’re intuitively (and correctly) bringing in far more important context - maintenance, testing, battle testing, etc. If a new implementation has a higher degree of those properties then it being “new” stops being relevant.
It’s also self defeating on its face. I take an old codebase, I fix a bug, the codebase is now new. Which one is better?
My point was that this statement requires a definition of “new codebase” that nobody would agree with, at least in the context of the discussion we’re in. Maybe you are attacking the base proposition without applying the surrounding context, which might be valid if this were a formal argument and not a free-for-all discussion.
If a new implementation has a higher degree of those properties
I think that it would be considered no longer new if it had had significant battle-testing, for example.
FWIW the important thing in my view is that every new codebase is a potential old codebase (given time and care), and a rewrite necessarily involves a step backwards. The question should probably not be, which is immediately better?, but, which is better in the longer term (and by how much)? However your point that “new codebase” is not automatically worse is certainly valid. There are other factors than age and “time in the field” that determine quality.
Methodologies don’t matter for quality of code. They could be useful for estimates, cost control, figuring out whom you shall fire etc. But not for the quality of code.
I’ve never observed a programmer become better or worse by switching methodology. Dijkstra would’ve not became better if you made him do daily standups or go through code reviews.
There are ways to improve your programming by choosing different approach but these are very individual. Methodology is mostly a beancounting tool.
When I say “methodology” I’m speaking very broadly - simply “the approach one takes”. This isn’t necessarily saying that any methodology is better than any other. The way I approach a task today is better, I think, then the way that I would have approached that task a decade ago - my methodology has changed, the way I think has changed. Perhaps that might mean I write more tests, or I test earlier, but it may mean exactly the opposite, and my methods may only work best for me.
I’m not advocating for “process” or ubiquity, only that the approach one tasks may improve over time, which I suspect we would agree on.
It’s the largest collaborative project in human history and over 30 million lines of code.
How many of those lines are part of the core? My understanding was that the overwhelming majority was driver code. There may not be that much core subsystem code to rewrite.
For a previous project, we included a minimal Linux build. It was around 300 KLoC, which included networking and the storage stack, along with virtio drivers.
That’s around the size a single person could manage and quite easy with a motivated team.
If you started with DPDK and SPDK then you’d already have filesystems and a copy of the FreeBSD network stack to run in isolated environments.
Once many drivers share common rust wrappers over core subsystems, you could flip it and write the subsystem in Rust. Then expose C interface for the rest.
I see that Drew proposes a new OS in that linked article, but I think a better proposal in the same vein is a fork. You get to keep Linux, but you can start porting logic to Rust unimpeded, and it’s a manageable amount of work to keep porting upstream changes.
Remember when libav forked from ffmpeg? Michael Niedermayer single-handedly ported every single libav commit back into ffmpeg, and eventually, ffmpeg won.
At first there will be extremely high C percentage, low Rust percentage, so porting is trivial, just git merge and there will be no conflicts. As the fork ports more and more C code to Rust, however, you start to have to do porting work by inspecting the C code and determining whether the fixes apply to the corresponding Rust code. However, at that point, it means you should start seeing productivity gains, community gains, and feature gains from using a better language than C. At this point the community growth should be able to keep up with the extra porting work required. And this is when distros will start sniffing around, at first offering variants of the distro that uses the forked kernel, and if they like what they taste, they might even drop the original.
I genuinely think it’s a strong idea, given the momentum and potential amount of labor Rust community has at its disposal.
I think the competition would be great, especially in the domain of making it more contributor friendly to improve the kernel(s) that we use daily.
I certainly don’t think this is impossible, for sure. But the point ultimately still stands: Linux kernel devs don’t want a fork. They want Linux. These folks aren’t interested in competing, they’re interested in making the project they work on better. We’ll see if some others choose the fork route, but it’s still ultimately not the point of this project.
Linux developers want to work on Linux, they don’t want to make a new OS.
While I don’t personally want to make a new OS, I’m not sure I actually want to work on Linux. Most of the time I strive for portability, and so abstract myself from the OS whenever I can get away with it. And when I can’t, I have to say Linux’s API isn’t always that great, compared to what the BSDs have to offer (epoll vs kqueue comes to mind). Most annoying though is the lack of documentation for the less used APIs: I’ve recently worked with Netlink sockets, and for the proc stuff so far the best documentation I found was the freaking source code of a third party monitoring program.
I was shocked. Complete documentation of the public API is the minimum bar for a project as serious of the Linux kernel. I can live with an API I don’t like, but lack of documentation is a deal breaker.
While I don’t personally want to make a new OS, I’m not sure I actually want to work on Linux.
I think they mean that Linux kernel devs want to work on the Linux kernel. Most (all?) R4L devs are long time Linux kernel devs. Though, maybe some of the people resigning over LKML toxicity will go work on Redox or something…
Re-Implementing the kernel ABI would be a ton of work for little gain if all they wanted was to upstream all the work on new hardware drivers that is already done - and then eventually start re-implementing bits that need to be revised anyway.
If the singular required Rust toolchain didn’t feel like such a ridiculous to bootstrap 500 ton LLVM clown car I would agree with this statement without reservation.
Zig is easier to implement (and I personally like it as a language) but doesn’t have the same safety guarantees and strong type system that Rust does. It’s a give and take. I actually really like Rust and would like to see a proliferation of toolchain options, such as what’s in progress in GCC land. Overall, it would just be really nice to have an easily bootstrapped toolchain that a normal person can compile from scratch locally, although I don’t think it necessarily needs to be the default, or that using LLVM generally is an issue. However, it might be possible that no matter how you architect it, Rust might just be complicated enough that any sufficiently useful toolchain for the language could just end up being a 500 ton clown car of some kind anyways.
Depends on which parts of GP’s statement you care about: LLVM or bootstrap. Zig is still depending on LLVM (for now), but it is no longer bootstrappable in a limited number of steps (because they switched from a bootstrap C++ implementation of the compiler to keeping a compressed WASM build of the compiler as a blob.
Yep, although I would also add it’s unfair to judge Zig in any case on this matter now given it’s such a young project that clearly is going to evolve a lot before the dust begins to settle (Rust is also young, but not nearly as young as Zig). In ten to twenty years, so long as we’re all still typing away on our keyboards, we might have a dozen Zig 1.0 and a half dozen Zig 2.0 implementations!
Yeah, the absurdly low code quality and toxic environment make me think that Linux is ripe for disruption. Not like anyone can produce a production kernel overnight, but maybe a few years of sustained work might see a functional, production-ready Rust kernel for some niche applications and from there it could be expanded gradually. While it would have a lot of catching up to do with respect to Linux, I would expect it to mature much faster because of Rust, because of a lack of cruft/backwards-compatibility promises, and most importantly because it could avoid the pointless drama and toxicity that burn people out and prevent people from contributing in the first place.
From the thread in OP, if you expand the messages, there is wide agreement among the maintainers that all sorts of really badly designed and almost impossible to use (safely) APIs ended up in the kernel over the years because the developers were inexperienced and kind of learning kernel development as they went. In retrospect they would have designed many of the APIs very differently.
It’s based on my forays into the Linux kernel source code. I don’t doubt there’s some quality code lurking around somewhere, but the stuff I’ve come across (largely filesystem and filesystem adjacent) is baffling.
Seeing how many people are confidently incorrect about Linux maintainers only caring about their job security and keeping code bad to make it a barrier to entry, if nothing else taught me how online discussions are a huge game of Chinese whispers where most participants don’t have a clue of what they are talking about.
I doubt that maintainers are “only caring about their job security and keeping back code” but with all due respect: You’re also just taking arguments out of thin air right now. What I do believe is what we have seen: Pretty toxic responses from some people and a whole lot of issues trying to move forward.
Seeing how many people are confidently incorrect about Linux maintainers only caring about their job security and keeping code bad to make it a barrier to entry
Huh, I’m not seeing any claim to this end from the GP, or did I not look hard enough? At face value, saying that something has an “absurdly low code quality” does not imply anything about nefarious motives.
Still, in GP’s case the Chinese whispers have reduced “the safety of this API is hard to formalize and you pretty much have to use it the way everybody does it” to “absurdly low quality”. To which I ask, what is more likely. 1) That 30-million lines of code contain various levels of technical debt of which maintainers are aware; and that said maintainers are worried even of code where the technical debt is real but not causing substantial issue in practice? Or 2) that a piece of software gets to run on literally billions of devices of all sizes and prices just because it’s free and in spite of its “absurdly low quality”?
Linux is not perfect, neither technically nor socially. But it sure takes a lot of entitlement and self-righteousness to declare it “of absurdly low quality” with a straight face.
GP here: I probably should have said “shockingly” rather than “absurdly”. I didn’t really expect to get lawyered over that one word, but yeah, the idea was that for a software that runs on billions of devices, the code quality is shockingly low.
Of course, this is plainly subjective. If your code quality standards are a lot lower than mine then you might disagree with my assessment.
That said, I suspect adoption is a poor proxy for code quality. Internet Explorer was widely adopted and yet it’s broadly understood to have been poorly written.
But it sure takes a lot of entitlement and self-righteousness to declare it “of absurdly low quality” with a straight face
I’m sure self-righteousness could get you to the same place, but in my case I arrived by way of experience. You can relax, I wasn’t attacking Linux—I like Linux—it just has a lot of opportunity for improvement.
I guess I’ve seen the internals of too much proprietary software now to be shocked by anything about Linux per se. I might even argue that the quality of Linux is surprisingly good, considering its origins and development model.
I think I’d lawyer you a tiny bit differently: some of the bugs in the kernel shock me when I consider how many devices run that code and fulfill their purposes despite those bugs.
FWIW, I was not making a dig at open source software, and yes plenty of corporate software is worse. I guess my expectations for Linux are higher because of how often it is touted as exemplary in some form or another. I don’t even dislike Linux, I think it’s the best thing out there for a huge swath of use cases—I just see some pretty big opportunities for improvement.
But it sure takes a lot of entitlement and self-righteousness to declare it “of absurdly low quality” with a straight face.
Or actual benchmarks: the performance the Linux kernel leaves on the table in some cases is absurd. And sure it’s just one example, but I wouldn’t be surprised if it was representative of a good portion of the kernel.
Well not quite but still “considered broken beyond repair by many people related to life time management” - which is definitely worse than “hard to formalize” when “the way ever[y]body does it” seems to vary between each user.
I love Rust but still, we’re talking of a language which (for good reasons!) considers doubly linked lists unsafe. Take an API that gets a 4 on Rusty Russell’s API design scale (“Follow common convention and you’ll get it right”), but which was designed for a completely different programming language if not paradigm, and it’s not surprising that it can’t easily be transformed into a 9 (“The compiler/linker won’t let you get it wrong”). But at the same time there are a dozen ways in which, according to the same scale, things could actually be worse!
What I dislike is that people are seeing “awareness of complexity” and the message they spread is “absurdly low quality”.
Note that doubly linked lists are not a special case at all in Rust. All the other common data structures like Vec, HashMap etc. also need unsafe code in their implementation.
Implementing these datastructures in Rust, and writing unsafe code in general, is indeed roughly a 4. But these are all already implemented in the standard library, with an API that actually is at a 9. And std::collections::LinkedList is constructive proof that you can have a safe Rust abstraction for doubly linked lists.
Yes, the implementation could have bugs, thus making the abstraction leaky. But that’s the case for literally everything, down to the hardware that your code runs on.
You’re absolutely right that you can build abstractions with enough effort.
My point is that if a doubly linked list is (again, for good reasons) hard to make into a 9, a 20-year-old API may very well be even harder. In fact, std::collections::LinkedList is safe but still not great (for example the cursor API is still unstable); and being in std, it was designed/reviewed by some of the most knowledgeable Rust developers, sort of by definition. That’s the conundrum that maintainers face and, if they realize that, it’s a good thing. I would be scared if maintainers handwaved that away.
Yes, the implementation could have bugs, thus making the abstraction leaky.
Bugs happen, but if the abstraction is downright wrong then that’s something I wouldn’t underestimate. A lot of the appeal of Rust in Linux lies exactly in documenting/formalizing these unwritten rules, and wrong documentation can be worse than no documentation (cue the negative parts of the API design scale!); even more so if your documentation is a formal model like a set of Rust types and functions.
That said, the same thing can happen in a Rust-first kernel, which will also have a lot of unsafe code. And it would be much harder to fix it in a Rust-first kernel, than in Linux at a time when it’s just feeling the waters.
In fact, std::collections::LinkedList is safe but still not great (for example the cursor API is still unstable); and being in std, it was designed/reviewed by some of the most knowledgeable Rust developers, sort of by definition.
At the same time, it was included almost as like, half a joke, and nobody uses it, so there’s not a lot of pressure to actually finish off the cursor API.
It’s also not the kind of linked list the kernel would use, as they’d want an intrusive one.
And yet, safe to use doubly linked lists written in Rust exist. That the implementation needs unsafe is not a real problem. That’s how we should look at wrapping C code in safe Rust abstractions.
The whole comment you replied to, after the one sentence about linked lists, is about abstractions. And abstractions are rarely going to be easy, and sometimes could be hardly possible.
That’s just a fact. Confusing this fact for something as hyperbolic as “absurdly low quality” is stunning example of the Dunning Kruger effect, and frankly insulting as well.
I personally would call Linux low quality because many parts of it are buggy as sin. My GPU stops working properly literally every other time I upgrade Linux.
No one is saying that Linux is low quality because it’s hard or impossible to abstract some subsystems in Rust, they’re saying it’s low quality because a lot of it barely works! I would say that your “Chinese whispers” misrepresents the situation and what people here are actually saying. “the safety of this API is hard to formalize and you pretty much have to use it the way everybody does it” doesn’t apply if no one can tell you how to use an API, and everyone does it differently.
Actually, the NT kernel of all things seems to have a pretty good reputation, and I wouldn’t dismiss the BSD kernels out of hand. I don’t know which kernel is better, but it seems you do. If you could explain how you came to this conclusion that would be most helpful.
*nod* I haven’t been a Windows person since shortly after the release of Windows XP (i.e. the first online activation DRM’d Windows) but, whenever I see glimpses of what’s going on inside the NT kernel in places like Project Zero: The Definitive Guide on Win32 to NT Path Conversion, it really makes me want to know more.
So one of our tunnel evacuation system deliveries had started reporting fires every morning at one of the tunnel’s exits. Turned out that technically it is a huge one but is safely away at 1AU. Hence coding a mitigation for it this week.
We use adjacent sensors in the network to filter out false positives. Which generally works quite well but there, during few weeks in the winter the sun hits two sensors in a short sequence.
Are there a lot of common lisp and Java code bases that need integration? I figured any big Java shop that wanted to dip their toe in lisp used Clojure.
The first thing I’d remark is that while one can buy old testgear from Fluke, HP, Tektronix et al. relatively cheaply, it is basically top-of-the-line stuff which is in no way comparable with no-brand imports. If it doesn’t perform well, that’s likely to be because components are failing after many years service: in most (but not all) cases that’s fixable.
The second thing is that devices like TinySA are in a league of their own: not as capable as classic gear from HP et al., but by no means junk particularly if one buys from the designer rather than falling for a knockoff.
You can do a great deal with cheap (predominantly Chinese) testgear, but have to be aware of its limitations. For example, I’ve got a “pretty but cheap” bench power supply that has an enormous amount of noise on its output (see https://github.com/MarkMLl/dsocat/raw/main/DSO-Cat_2021-01-29T09_35_07.png) which would make any attempt to debug a noisy circuit powered by it futile. I’ve also got a cheap multimeter (which after limited use is showing symptoms of a dodgy range selector), a cheap ’scope (good for a few kHz before sampling artifacts intrude), a PC-based logic analyser and so on.
But I’ve also got a vintage ’scope for the rare occasions where hefting its bulk is really essential, and a vintage logic analyser. And the latter in particular- 65 channels, withstanding 48V per channel, and good for 10 nSec resolution- will put most modern stuff to shame.
Please don’t get me wrong: I’m not trying to boast about picking up some good deals there. The important thing is that you can get marginally-usable modern gear for a pittance, and it will work up to a point. But you have to understand where that point is and how it affects whatever you’re trying to do, and to do that it’s useful to have- or at least have access to- more expensive older gear even if you don’t use it every day.
As an aside, TinySA had found an unexpected application in the modern trench warfare in Ukraine. At this point its military use probably outstrips the civilian.
And I concur old top brands are still generally a better value. Especially the odd unique niche pieces (looking at my HP53310A) which don’t have large enough market for cheap new substitutes.
Perhaps the most public example of “ploughshares into swords” is the heavy use of civilian drones to harass the aggressor.
I was of course thinking about HP when I equivocated about repairing older kit: they fairly regularly used custom chips, and finding a writeup in the HP Journal is no substitute for finding a working spare.
Wouldn’t the total energy draw be the area under the curve here? If that’s the case, the graphs show that serving TLS actually uses about 40% more energy (eyeballing it), that regular http requests. Am I missing something?
The point of TLS everywhere is clear from the security and labor-economic perspectives. However it was bewildering to read some people believe it is also zero energy overhead.
The author now appears to stress how ISP content injection could nullify the difference but it doesn’t sound credible. Such bottom feeder providers were niche even in their heyday and petered out long before letsencrypt movement picked up. Also a significant portion of worldwide HTTPS traffic is intra-app/services.
No, the difference in the total area under the curve is mainly made up from the SoC clocking down. The actual difference in power usage due to “additional silicon” being active is the difference when both curves are in the period in which they do work.
I have also encountered people (online) who didn’t know that you could render web pages on the server.
React was their default; I saw some static websites that were just static JSX in React. Like if you wanted to put up some photos of your apartment or vacation on your own domain, you would create a React app for that.
People learn by imitation, and that’s 100% necessary in software, so it’s not too surprising. But yeah this is not a good way to do it.
The web is objectively worse that way, i.e. if you have ever seen an non-technical older person trying to navigate the little pop-out hamburger menus and so forth. Or a person without a fast mobile connection.
If I look back a couple decades, when I used Windows, I definitely remember that shell and FTP were barriers to web publishing. It was hard to figure out where to put stuff, and how to look at it.
And just synchronizing it was a problem
PHP was also something I never understood until I learned shell :-) I can see how JavaScript is more natural than PHP for some, even though PHP lets you render on the server.
That’s not completely true, one beautiful JSX thing is that any JSX HTML node is a value, you can use all your language at your disposal to create that HTML. Most backend server frameworks use templating instead. For most cases both are equivalent, but sometimes being able to put HTML values in lists and dictionaries and have the full power of the language do come in handy.
Well, that’s exactly what your OP said. Here is an example in Scala. It’s the same style. It’s not like this was invented by react or even by frontend libraries.
In fact, Scalatags for example is even better than JSX because it is really just values and doesn’t even need any special syntax preprocessor. It is pure, plain Scala code.
Most backend server frameworks use templating instead.
Maybe, but then just pick a better one? OP said “many” and not “most”.
Fine, I misread many as most as I had just woken up. But I’m a bit baffled that a post saying “pick a better one” for any engineering topic has been upvoted like this. Let me go to my team and let them know that we should migrate all our Ruby app to Scala so we can get ScalaTags. JSX was the first such exposure of a values-based HTML builder for mainstream use, you and your brother comment talk about Scala and Lisp as examples, two very niche languages.
When did I say that this was invented by React? I’m just saying that you can use JSX both on front and back which makes it useful for generating HTML. Your post, your sibling and the OP just sound slightly butthurt at Javascript for some reason, and it’s not my favourite language by any stretch of the imagination, but when someone says “JSX is a good way to generate HTML” and the response is “well, other languages have similar things as well”, I just find that as arguing in bad faith and not trying to bring anything constructive to the conversation, same as the rest of the thread.
Let me go to my team and let them know that we should migrate all our Ruby app to Scala so we can get ScalaTags.
But the point is that you wouldn’t have to - you could use a Ruby workalike, or implement one yourself. Something like Markaby is exactly that. Just take these good ideas from other languages and use it in yours.
Anyway, it sounds like we are in agreement that this would be better than just adopting JavaScript just because it is one of the few non-niche languages which happens to have such a language-oriented support for tags-as-objects like JSX.
I found that after all I prefer to write what is going to end up as HTML in something that looks as much as HTML as possible. I have tried the it’s-just-pure-data-and-functions approach (mostly with elm-ui, which replaces both HTML and CSS), but in the end I don’t like context switching it forces on my brain. HTML templates with as much strong checks as possible is my current preference. (Of course, it’s excellent if you can also hook into the HTML as a data structure to do manipulations at some stage.)
For doing JSX (along with other frameworks) on the backend, Astro is excellent.
That’s fair. There’s advantages and disadvantages when it comes to emulating the syntax of a target language in the host language. I also find JSX not too bad - however, one has to learn it first which definitely is a lot of overhead, we just tend to forget that once we have learned and used it for a long time.
In the Lisp world, it is super common to represent HTML/XML elements as lists. There’s nothing more natural than performing list operations in Lisp (after all, Lisp stands for LISt Processing). I don’t know how old this is, but it certainly predates React and JSX (Scheme’s SXML has been around since at least the early naughts).
Yeah, JSX is just a weird specialized language for quasiquotation of one specific kind of data that requires an additional compilation step. At least it’s not string templating, I guess…
Every mainstream as well as many niche languages have libraries that build HTML as pure values in your language itself, allowing the full power of the language to be used–defining functions, using control flow syntax, and so on. I predict this approach will become even more popular over time as server-driven apps have a resurgence.
I am not a web developer at all, and do not keep up with web trends, so the first time I heard the term “server-side rendering” I was fascinated and mildly horrified. How were servers rendering a web page? Were they rendering to a PNG and sending that to the browser to display?
I must say I was rather disappointed to learn that server-side rendering just means that the server sends HTML, which is rather anticlimactic, though much more sane than sending a PNG. (I still don’t understand why HTML is considered “rendering” given that the browser very much still needs to render it to a visual form, but that’s neither here nor there.)
(I still don’t understand why HTML is considered “rendering” given that the browser very much still needs to render it to a visual form, but that’s neither here nor there.)
The Bible says “Render unto Caesar the things that are Caesar’s, and unto God the things that are God’s”. Adapting that to today’s question: “Render unto the Screen the things that are the Screen’s, and unto the Browser the things that are the Browser’s”. The screen works in images, the browser works in html. Therefore, you render unto the Browser the HTML. Thus saith the Blasphemy.
(so personally I also think it is an overused word and it sounds silly to me, but the dictionary definition of the word “render” is to extract, convert, deliver, submit, etc. So this use is perfectly inline with the definition and with centuries of usage irl so i can’t complain too much really.)
I don’t think it would be a particularly useful distinction to make; as others said you generally “render” HTML when you turn a templated file into valid HTML, or when you generate HTML from another arbitrary format. You could also use “materialize” if you’re writing it to a file, or you could make the argument that it’s compilers all the way down, but IMO that would be splitting hairs.
I’m reminded of the “transpiler vs compiler” ‘debate’, which is also all a bit academic (or rather, the total opposite; vibe-y and whatever/who cares!).
Technically true, but in the context of websites, “render” is almost always used in a certain way. Using it in a different way renders the optimizations my brain is doing useless.
React was their default; I saw some static websites that were just static JSX in React. Like if you wanted to put up some photos of your apartment or vacation on your own domain, you would create a React app for that.
Unless it was being rendered on the client, I don’t see what’s wrong with that. JSX and React were basically the templating language they were using. There’s no reason that setup cannot be fully server-generated and served as static HTML, and they could use any of the thousands of react components out there.
Yeah if you’re using it as a static site generator, it could be perfectly fine
I don’t have a link handy, but the site I was thinking about had a big janky template with pop-out hamburger menus, so it was definitely being rendered client side. It was slow and big.
React was their default; I saw some static websites that were just static JSX in React. Like if you wanted to put up some photos of your apartment or vacation on your own domain, you would create a React app for that.
I’m hoping tools like Astro (and other JS frameworks w/ SSR) can shed this baggage. Astro will render your React components to static HTML by default, with normal clientside loading being done on a per-component basis (at least within the initial Astro component you’re calling the React component from).
I’m not sure I would call a custom file type .astro that renders TS, JSX, and MD/X split by a frontmatter “shedding baggage”. In fact, I think we could argue that astro is a symptom of the exact same problem you are illustrating from that quote.
That framework is going to die the same way that Next.JS will: death by a thousand features.
huh couldn’t disagree more. Astro is specifically fixing the issue quoted: now you can just make a React app and your baseline perf for your static bits is now the same as any other framework. The baggage I’m referring to would be the awful SSG frameworks I’ve used that are more difficult to hold correctly than Astro, and of course require plenty of other file types to do what .astro does (.rb, .py, .yml, etc.). The State of JS survey seems to indicate that people are sharing my sentiments (Astro has a retention rate of 94%, the highest of the “metaframeworks”).
I don’t know if I could nail what dictates the whims of devs, but I know it isn’t feature count. If Next dies, it will be because some framework with SSG, SSR, ISR, PPR, RSC, and a dozen more acronym’d features replaced it. (And because OpenNext still isn’t finished.)
Astro’s design is quite nice. It’s flexing into SSR web apps pretty nicely I’d say. The way they organize things isn’t always my favorite, but if it means I can avoid ever touching NextJS I’m happy.
Assembling and setting up a pre-production/pre-cert prototype for a new product.
Otherwise twiddling my thumbs waiting for IANA reaction to our newly proposed CBOR tags.
On the other hand, the end state is often: Dear friend, you have built a LAMP server, using k8s (and Helm, and operators, and cert-manager, and Prometheus, and…).
I hope that this doesn’t come across as too snarky but I’ve just suffered the pain of getting a single-node Ansible AWX server running. Their only supported architecture is k8s and their operator. It took days! I remember back in the old days we used to say “simple should be easy and complicated should be possible.” Now it’s “everyone needs Google scale so that’s all we’re going to do.”
As an example of doing it the right way, the Immich photo management app is comparable to AWX in run-time complexity but it comes with a Compose file that makes it trivial to run and manage on any machine with docker already installed.
FWIW you don’t need Helm for Kubernetes, and you’re going to want something like cert-manager regardless (and if you don’t want cert-manager, just don’t do anything—I wish k8s would include it by default, but it doesn’t).
Similarly, there’s a lot of middle ground between single node and Google scale, and you should have at least one replica running in production in most cases, which i means you’re going to need some sort of load balancer and some deployment automation. At this point you may as well start considering Kubernetes.
Not only does Kubernetes provide load balancing and deployment automation, but it also allows you to easily run cloudnativepg, an operator that makes it easy to run a Postgres cluster with replication, backups, and failover. Maybe you don’t need that for your production application, but if you do, it’s a lot easier to run k8s and that operator than it is to use other tools to manage Postgres IMHO.
which means you’re going to need some sort of load balancer and some deployment automation. At this point you may as well start considering Kubernetes.
That’s an astonishing jump. For a handful of machines, a few scripts with ssh and some pretty standard networking tricks would be what I think of long before k8s.
I’m not sure exactly what you’re thinking with your “few scripts and networking tricks”, but it sounds like you’re trying to refute the need for a load balancer by arguing that you can implement your own load balancer.
Moreover, while any given feature Kubernetes provides out of the box could be implemented easily enough by a sufficiently competent, experienced engineer, the point of the article is that the total effort is much greater and you still end up with a platform for which no documentation, or training, or experienced hiring pool exists and your expensive competent, experienced professional has spent his time building Kubernetes instead of doing more valuable tasks (or more likely, your professional only thinks he’s sufficiently competent and experienced, and you wind up with a very broken Kubernetes that causes endless frustration).
it sounds like you’re trying to refute the need for a load balancer by arguing that you can implement your own load balancer.
If you have two machines you don’t need a load balancer. You just need a way to fail over to the second machine. That’s just network configuration, which you have to do anyway, Kubernetes or no Kubernetes.
That’s the problem with this argument. You still have to deploy machines, configure operating systems and networking, install services (whether your services or Kubernetes’s services), etc. unless you’re using a 3rd party managed Kubernetes, which renders the comparison irrelevant anyway. So you can expose Kubernetes as a uniform target to a bunch of teams, but you still have a lot of stuff that is local deployment. If you don’t have a platform team providing a uniform target to lots of other teams, and you’re already doing all this configuration anyway, why do the configuration of Kubernetes as well?
If you have two machines you don’t need a load balancer. You just need a way to fail over to the second machine. That’s just network configuration, which you have to do anyway, Kubernetes or no Kubernetes.
Kubernetes generally takes care of the failover for you. You don’t really need to think about it.
That’s the problem with this argument. You still have to deploy machines, configure operating systems and networking, install services (whether your services or Kubernetes’s services), etc.
There’s much less operating system configuration if you’re using Kubernetes than if you’re rolling your own hosts, and the networking setup is “install MetalLB”. It’s extremely minimal. Similarly, certificate management is “install cert-manager”. DNS is “install external-dns”. Similarly there are standard, high-quality packages for logging, monitoring, alerting, volume management, etc. While I’m surprised there are Kubernetes distros that include this stuff out of the box, it’s still less work than doing it yourself and you get the benefits of standardization: abundant, high quality documentation, training resources, and an experienced hiring pool. And moreover, as your requirements scale, you can incrementally opt into additional automation (Kubernetes is a platform for infrastructure automation).
unless you’re using a 3rd party managed Kubernetes, which renders the comparison irrelevant anyway.
I’m not sure what you mean here. Why would managed Kubernetes render the comparison obsolete?
So you can expose Kubernetes as a uniform target to a bunch of teams, but you still have a lot of stuff that is local deployment. If you don’t have a platform team providing a uniform target to lots of other teams, and you’re already doing all this configuration anyway, why do the configuration of Kubernetes as well?
I’m not following you here. What do you mean by “uniform target” vs “local deployment”.
No, it’s not. You still have to set up the underlying network that the physical machines are on. That’s the key point. You can install all this stuff within Kubernetes…but it’s all dependent on nodes that are fully configured outside of Kubernetes.
I see what you mean. Yes, you need to have nodes that are on a network, but “fully configured” for running Kubernetes basically means “SSH is configured”, which is dramatically easier than any configuration I’ve seen for running production-grade applications directly on nodes (no need to haul out ansible or anything like it).
Kubernetes generally takes care of the failover for you. You don’t really need to think about it.
By design, sure. In practice though the biggest failures I’ve had with kubernetes have been nginx ingress pods just randomly losing their ability to connect to upstream and silently causing downtime that wouldn’t haven’t happened if the app was exposed directly, using an AWS ALB, etc. I’m not saying this is everyone’s experience. It might be due to noob misconfiguration mistakes. But that’s sorta the point the article misses. Kubernetes might offer repeatable solutions for these problems (and I appreciate it for that) but it really isn’t a solution on its own. Every team running a kubernetes cluster has their own collection of weird scripts with bespoke workarounds for kubermetes quirks.
Thank you! In this case I was told to stand up an AWX instance, and I didn’t know what I didn’t know, but I’ll take a look at your suggestion. If there’s a “next time” then I’ll be able to advocate for an alternative.
OMG this. At work I tried to fix a broken internal app that I had no role in getting set up. Everyone who had worked on it had departed. So started the slog of figuring out how it worked, where it was deployed, and getting access. Oh cool, this runs on the “internal dev platform”. What is that? Oh it’s a kunernetes cluster. Neat that they tried to think ahead spread some infra costa across projects. I wonder what else is running on this thing… nothing. It is a 2 node kubernetes deployment that runs one application pod. Not per node. Total.
It is a 2 node kubernetes deployment that runs one application pod. Not per node. Total.
I was working in an Oracle shop where devs would spin up an Oracle instance for a web application that had 4 data items. Not databases. Not tables. Items.
My production app ran completely without databases and was several orders of magnitude faster, smaller, and more reliable than its predecessor.
But think. How the devs could otherwise move on in their careers without “designed, built, deployed and maintained a scalable K8 solution” on their CVs?
Ding ding ding! You got it. On a lark I searched Google for large sections of the docs they “wrote” for it and sure enough it was all basically copy/pasted from guides on how to set up RBAC.
I like the idea of example-driven code generation, but there’s a limit to how much you can express using examples only. I think it’s necessary to allow including a description too. Also, coming from a “data-science” POV, I would provide the LLM only with 80% of the examples, and then test it on the remaining 20% to make sure it isn’t overfitting.
This too can be trivially handled by the compiler. E.g. require at least 6 examples, use 4 of those for gen and 2 for test. Issue a warning if the user had supplied fewer than that.
Agreed. Think about how board games rules are defined. They would never send you a booklet with 500 individual examples, they describe the rules generically.
In computer science, that’s called a specification. Many examples do not a specification make.
I wonder how much this is a case of chasing the metric rather than organic adoption.
Some large consultancies here really push the adoption of assistants onto programmers so that they can boast the customers they’re on the bleeding edge of development. The devs grumble, attend mandatory AI training and for the most part pretend they lean on their now indispensable Copilots. It is possible something like that is happening here. The VP of AI Adoption and their department that Google for sure has counts all the lines from AI enabled editors. This then communicated with a good part of wishful thinking all the way up to the CEO.
Or who knows, maybe Google has a secret model which is not an utter crap for anything non-trivial and just holding it back for competitive advantage. Hope googlers here would let us know!
If you read their report on it, it is definitely chasing for metrics. All their other “AI tool for devs” initiatives have abysmal numbers in term of adoption and results, and they are already saying that all their future growth are in other domains of development. Translation: We are out of things we can easily growth hack.
FWIW, if this is anything like Copilot (which I do use for personal projects because I’ll take anything that’ll fry my brain a little less after 8 PM) it’s not even a particularly difficult metric to chase. I guess about 25% of my code is written by AI, too, as in the default completion that Copilot offers is good enough to cover things like convenience methods in an API, most function prototypes of common classes (e.g. things like constructors/destructors), basic initialization code for common data structures, hardware-specific flags and bitmasks and so on.
It’s certainly useful in that it lets me spend more of my very limited supply of unfried neurons on the harder parts, but also hardly a game changer. That 25% of the code accounts for maybe 1% of my actual mental effort.
I will give it that, though, it’s the one thing that generative AI tools have nailed. I’m firmly in the AI should do the dishes and vacuum so I can write music and poetry, not write music and poetry so I can do the dishes and vacuum camp. This is basically the one application where LLM tools really are doing the dishes so I can do the poetry.
This feels like that time Paul Graham said over 25% of ViaWeb code was macros and it was intended to be a boast but everyone who saw it was just horrified.
I don’t see the problem. He made a dsl in lisp, so the actual code was smaller/denser describing the problem space well. In this particular case, the users would basically be creating configs, similar to knowledge bases or constraint lists describing what they wanted. The macro heavy code would then transform that into an end result. Isn’t that good?
Graham has been riding on his “we built an ecommerce site in Lisp and it was so awesome” for nearly 30 decades years now. Sadly the followup was Hackernews.
I’m not sure if you’ve ever had the chance to use Yahoo! Store (what Viaweb became)—it was terrible—but it was also extremely innovative for the time. It used an actual programming language RTML you edited with the browser. It was sandboxed, and built on continuations (for which Graham received a patent).
So, yeah. Maybe he’s been bragging about this for 30 years, but this success ultimately paved the way for YC which changed the world (I won’t make a value judgement on which way).
I’d posit that Graham, like a lot of other people, was lucky to be in the right place at the right time. Sure he and his team worked hard - creating a company isn’t easy - but lots of people made a lot of money in the first internet bubble, and the smarter ones kept the money and reinvested it. Running a VC firm was essentially a license to print money for a while. And YC itself “just” pics companies to invest in, they don’t run the companies themselves.
In other words, while PG attributes a lot of his success to the use of Lisp for Viaweb, it was probably not a game changer. The real product was making a web storefront, making it a success , and selling it to idiots investors with more money.
I think Graham himself attributes using Lisp as helping to get to the finish line first over the competitors. And it’s a fair point as it appears to have worked for him. But there is little doubt that user editable online stores would have appeared otherwise and I don’t think he was ever alluding to that.
While every exit has some luck involved and some “right place right time,” there likely weren’t other storefront builders in the same way Viaweb existed. That’s something.
Additionally, the choice of Lisp was definitely part familiarity, but also, he’s told stories as to why it was advantageous. He wasn’t skilled in running software, so their deployment, or bug fixes, or reporting were “run this thing in the repl.” You can’t do that outside of Lisp—maybe Erlang.
As for YC, it’s never been a traditional VC, and it’s only scaled up as a result of iteration on the model. The first group was like 6 companies. They all lived in Boaton. They all had dinner every Sunday (or whatever), they all got introduced to other investors, etc. YC built a community of like minded startup founders, and they lnow each other, and when possible, help each other. Does that happen in traditional VC? Probably to some degree. YC took it further, and it should be considered an innovation.
Note: I am not a Paul Graham Stan. I do think the man wasn’t “just lucky,” and actually created things that people wanted.
In terms of how the software works, hacker news is one of the best sites I’ve used … like ever
I mean lobst.ers was directly inspired by it, and judging by my logs hacker news drives 5x to 10x the traffic
So oddly enough the Lisp way of writing web apps actually did and does work. I think they had to do a bunch of work on the runtime too, but so did stack overflow, instagram, etc
Well, I think the point here is largely tongue in cheek, but there’s truth in it too, so I’ll focus on the truth; Yes, building layers is good, declarative code is good, interpreting specifications is good. But none of these things necessitate excessive amounts of metaprogramming.
My personal experience is that I dig myself into metaprogramming holes when I spend too little time thinking about simpler ways to achieve my goals, so I’ve developed a reflex of stopping myself and reflecting a little whenever the urge to metaprogram comes. So, naturally, when somebody says their codebase is 25% metaprogramming, the same reflex kicks in.
A good deal of standard Common Lisp language constructs are actually macros and nobody flinches using them. The language integration for that is really good. So I agree with u/veqq, it’s a nothingburger in general, although naturally a question of taste here applies just as much as to programming in general.
Metaprogramming is as normal as defining functions in lisp. In Common Lisp core things like when, and, loop, dotimes, let, defun, defvar, defmacro or cond are macros. Code is data is code. Perhaps you are thinking of metapogramming in other languages where it has its own strange system and syntax and complects the system.
Honestly, thinking about it, 25% must mean new macro definitions as typical code probably involves more macros (just from using control flow etc.).
There’s at least one decent way of handling errors and it’s how Common Lisp does it. It’s been sitting there since 1980s and I just can’t wait when it finally enters the mainstream discourse just like it was for the language’s other features.
Rust had conditions, if that’s what you’re referring to. It had some pretty serious usability issues and so it ended up being removed in favor of Result.
Also, maybe I am wrong, but I think conditions are more or less equivalent to passing down a callback that takes an error and either returns a default value, or unwinds.
This is a useful pattern in a pinch, but I don’t think it solves the rest 99% cases?
Or maybe I am misunderstanding conditions? Would love to read a blog post that discusses practical applications of the idea.
Conditions can have hierarchy, which allows for useful aggregation of failure handling. It can be as fine or as coarse as you want. Condition handlers, unlike return value handling don’t have to be call-local so one set of handlers can cover a lot of code. And unlike catch blocks conditions do not immediately unwind the stack which makes these handlers useful.
A sibling comment had mentioned restarts which are really handy when you want to recover computation without expensive reconstruction of the context.
Naturally all of that can be done in a multitude of ways and strictly speaking no language feature outside raw machine code is necessary. There is no magic to it except a bunch of smart people who sat and thought it through before implementing them. But as we talk of language design here the ergonomics are important.
A condition handler can also invoke a restart; AIUI when a function raises an error it can offer restarts to the condition handler that do things other than just calling the original function again with different arguments. Or you can view a restart like a catch block, and the condition handler can choose which catch block to unwind to.
It is at least close to that, yeah. I’m sure there’s some subtleties you and I are missing.
I probably should have linked to https://github.com/rust-lang/rust/pull/12039 in my first comment, which explained some of the trouble we ran into back then.
That’s just two possible restarts. A condition can provide any number of them, and they don’t have to be built-in (in fact I’m reasonably sure continue-with-value is not a standard restart, just a conventional one).
This was what my “noob” PL mind was telling me as well.
I have only matured to the point where I feel unions (options in rust I think) is good if we want a singluar value and then pattern match. As such errors are value really reasonates with me and not taking them as exceptions. (Have written lot of ruby where exceptions and errors were mixed and ran into all issues with exception handling)
Might be a Rust issue. Common Lisp and Dylan programmers generally love conditions, and I’m not aware of any serious usability issues.
It does not surprise me that different people value different things when it comes to error handling.
For the unenlightened, can you describe what this decent way is?
Edit: from reading sibling comments, it looks like https://en.wikibooks.org/wiki/Common_Lisp/Advanced_topics/Condition_System
https://lispcookbook.github.io/cl-cookbook/error_handling.html
Also Dylan.
The key is that you separate the process of finding the appropriate handler from unwinding the stack. Once found, the handler is called ON TOP OF the existing stack. It might then decide that unwinding is the correct response (and often does) but there is also the option of fixing things up and returning to the point of failure to retry and continue.
It’s like a page fault handler setting up an address mapping and putting either default or swapped-in data there and then retrying the instruction that trapped, instead of simply terminating the program. No one these days would dream of doing serious work on a machine that didn’t have that behaviour.
Using standard OOP features to help find the right handler is part of it, but whether you’re using C++/Java-style virtual functions or Lisp/Dylan/Julia generic functions for that is much less important.
Conditions are an improvement upon exceptions but suffer from the same issues: it’s an implicit untyped side-channel, which is trivially overbroad (although the strong expression orientation of CL and Smalltalk mitigate that somewhat).
I’m not sure what you mean by untyped here, conditions certainly have a class hierarchy.
Conditions are not part of function types. You do not statically know what conditions a function may signal and whether you have handled them.
That’s just another way to say “conditions are not return values” which I guess is fair but doesn’t add much.
No, it’s something different from that. Input arguments are part of the type of a function too, and by your reasoning “it’s just another way to say ‘conditions are not input arguments’. In Java, “checked exceptions” ARE part of a function’s signature and “unchecked exceptions” are NOT part of its signature. Being part of the function signature means (a) the property must be declared, and (b) the property is verified by the compiler. Perhaps you want those features, perhaps you don’t, but the fact that you do or don’t enforce those is an important property.
No.
Er… ok?
The problem everyone has with exceptions is, eventually, that they’re too powerful and too dynamic. While I appreciate that Lispers are on a higher plane of enlightenment and are more right about everything than I could possibly ever hope to be, I still can’t believe that the solution is to make them more powerful and more dynamic.
Conditions are not exceptions.
And honestly having spent a huge portion of my life checking my return values in C I feel entitled to make a comparison.
I get that they’re not the same as exceptions, but from what I’ve seen they appear to be a strict superset. They can do all the same nonlocal control flow that gives exceptions a bad name, and also some other even more nonlocal stuff, all while being impossible to reason about statically.
Some people (me, for example) complain about exceptions being a form of non-local control flow that is hard to reason about. That is one of the major problems new programming languages, like several of those listed in the article, have tried to address. I don’t know what you expect the mainstream discourse to take from Lisp here, given that they are trying to go in the opposite direction.
I’ve used C++ exceptions and Java exceptions. There is no comparison of those to the ergonomics of CL condition system. Some things are actually different.
For a long time things like automatic memory management, macros or lambdas had a lot of opponents too (and still have them), yet they were gradually adopted over the decades. It is often hard to explain why a certain feature is nice to someone who has very superficial understanding and no experience actually using them in a codebase, hence adoption is unavoidably slow.
I feel like I should create a bingo chart for Lobsters (or a certain orange site), since “Lisp solved this” (as well as “Haskell solved this”) are just classics that you see over and over again.
(Fwiw, I have no experience with continuations, but the fact that they sound a lot like exceptions makes me highly, highly skeptical. Maybe with enough static typing on top.)
Sure, people were skeptical for all other stuff eventually lifted from Lisp as well. Good luck in your bingo game!
Planned and enforced obsolescence via certificates.
This is the future the “HTTPS everywhere” crowd wants ;)
It will be interesting to see if Google fixes this. On the one hand, brand value. On the other, it’s a chance to force purchase of new hardware!
Not me. I want HTTPS Everywhere and I also don’t want this.
What’s your marketing budget? If you aren’t aligned with the marketing budget havers on this, how do you expect them to treat you when your goals diverge?
See also, fast expiring certificates making democratized CT logs infeasible, DNS over HTTPS consolidating formerly distributed systems on cloudflare. It’s not possible to set up a webpage in 2025 without interacting with a company that has enough money and accountability to untrustworthy governments to be a CA, and that sucks.
HTTPS is cool and all, but I wish there was a usable answer that wasn’t “just centralize the authority.”
Sigh. Lobsters won’t let me post. I must be getting rate limited? It seems a bit ridiculous, I’ve made one post in like… hours. And it just shows me “null” when I post. I need to bug report or something, this is quite a pain and this is going to need to be my last response as dealing with this bug is too frustrating.
Can you tell me more about these? I think “infeasible” is not accurate but maybe I’m wrong. I don’t see how DoH consolidates anything as anyone can set up a DoH server.
You can definitely set up a webpage in 2025 pretty with HTTPS, especially as you can just issue your own CA certs, which your users are welcome to trust. But if your concern is that a government can exert authority within its jurisdiction I have no idea how you think HTTP is helping you with that or how HTTPS is enabling that specifically. These don’t feel like HTTPS issues, they feel like regulatory issues.
There are numerous, globally distributed CAs, and you can set one up at any time.
Lobsters has been having some issues, I had the same trouble yesterday too.
The CT log thing is something i read on here iirc, basically that CT logs are already pretty enormous and difficult to maintain, if there are 5x as many cert transactions cause they expire in 1/5 the time the only people who will be able to keep them are people with big budgets
I suppose i could set up a DoH server, but the common wisdom is to use somebody else’s, usually cloudflare’s, the fact that something is technically possible doesnt matter in a world where nobody does it.
Are you joking? “please install my CA cert to browse my webpage” may technically count as setting up a web page but the barrier to entry is so high I might as well not. Can iphones even do that?
That’s a lot more centralized than “I can do it without involving a third party at all.”
I dunno, maybe I’m just romanticizing the past but I miss being able to publish stuff on the internet without a Big Company helping me.
Strange but I will have to learn more.
Sure, because that’s by far the easiest option and most people don’t really care about centralizing on Cloudflare, but nothing is stopping people from using another DoH.
iPhones being able to do that isn’t really relevant to HTTPS. If you want to say that users should be admins of their own devices, that’s cool too.
As for joking, no I am not. You can create a CA, anyone can. You don’t get to decide who trusts your CA, that would require work. Some companies do that work. Most individuals aren’t interested. That’s why CAs are companies. If you’re saying you want a CA without involving any company, including non-profits that run CAs, then there is in fact an “open” solution - host your own. No one can stop you.
You can run your own internet if you want to. HTTPS is only going to come up when you take on the responsibility of publishing content to the internet that everyone else has to use. No one can stop you from running your own internet.
As opposed to running an HTTP server without a third party at all? I guess technically you could go set up a server at your nearest Starbucks but I think “at all” is a bit hard to come by and always has been. Like I said, if you want to set up a server on your own local network no one is ever going to be able to stop you.
What did that look like?
I want the benefits of HTTPS without the drawbacks. I also want the benefits of DNS without the drawbacks.
On the one hand, I am completely sincere about this. On the other, I feel kind of foolish for wanting things without wanting their consequences.
Which drawbacks? I ask not because I believe there are none, but I’m curious which concern you the most. I’m sympathetic to wanting things and not wanting their consequences haha that’s the tricky thing with life.
HTTPS: I want the authentication properties of HTTPS without being beholden to a semi-centralized and not necessarily trustworthy CA system. All proposed alternatives are, as far as I know, bad.
DNS: I want the convenience of globally unique host names without it depending on a centralized registry. All proposed alternatives are, as far as I know, bad.
These kind of accusations are posts that make me want to spend less on lobsters. Who knows if it’s planned or accidental obsolescence? Many devices and services outlive their teams by much longer than anticipated. Everyone working in software for a long while has experienced situations like those. I also find the accusation that HTTPS is leading to broken devices rather wild…
I want to offer a different view: How cool is it that the devices was fixable despite Google’s failure to extend/exchange their certificate. Go, tell your folks that the Chromecast is fixable and help them :)
For me, it’s takes like yours that irritate me. Companies that are some of the largest on the planet don’t need people like you to defend them, to make excuses for them, to try to squelch the frustration directed towards them because they’re either evil or incompetent.
By the way, there is no third option - either they’re evil and intended to force obsolescence upon these devices, or they’re incompetent and didn’t know this was going to happen because of this incompetence.
The world where we’re thinking it’s cool that these devices are fixable tidily neglects the fact that 99% of the people out there will have zero clue how to fix them. That it’s fixable means practically nothing.
Who cares? No one is defending Google. People are defending deploying HTTPS as a strategy to improve security. Who cares if it’s Google or anyone else? The person you’re responding to never defends Google, none of this has to do with Google.
Who cares? Also, there is a very obvious 3rd option - that competent people can make a mistake.
Nothing you’ve said is relevant at all to the assertion that, quoting here:
Even though you’re quoting me, you must be mistaken - this post is about Google, and my response was about someone who is defending Google’s actions (“Who knows if it’s planned or accidental obsolescence?”).
I haven’t a clue how you can think that a whole post about Google breaking Google devices isn’t about Google…
To the last point, “https everywhere” means things like this can keep being used as an excuse to make fully functional products in to ewaste over and over, and we’re left wondering if the companies responsible are evil or dumb (or both). People pretending to not get the connection aren’t really making a good case for Google not being shit, or for how the “https everywhere” comment is somehow a tangent.
Nope, not mistaken. I think my points all stand as-is.
Take what you want from my employment by said company, but I would guess absolutely no-one in private and security has any wish/intention/pressure to not renew a certificate.
I have no insider knowledge about what has happened (nor could I share it if I did! But I really don’t). But I do know that the privacy and security people take their jobs extremely seriously.
Google has form in these matters, and the Chromecast as a brand even has an entry here:
https://killedbygoogle.com/
But in the future I’ll be more polite in criticizing one of the world’s biggest companies so that this place is more welcoming to you.
This isn’t about who you criticize, I would say the same if you picked the smallest company on earth. This is about the obvious negativity.
This is because the article isn’t “Chromecast isn’t working and the devices all need to go to the trash”. Someone actually found out why and people replied with instructions how to fix these devices, which is rather brilliant. And all of that despite google’s announcements that it would discontinue it..
I’m not exactly sure what you meant by that, and even the winky face doesn’t elide your intent and meaning much. I don’t think privacy and security advocates want this at all. I want usable and accessible privacy and security and investment in long term maintenance and usability of products. If that’s what you meant, it reads as a literal attack rather than sarcasm. Poe’s law and all.
Not all privacy and security advocates wanted ‘HTTPS everywhere’. Not all of the ‘HTTPS everywhere’ crowd wanted centralized control of privacy and encryption solutions. But the privacy and security discussion has been captured by corporate interests to an astonishing degree. And I think @gerikson is right to point that out.
Do you seriously think that a future law in the US forcing Let’s Encrypt (or any other CA) to revoke the certificates of any site the government finds objectionable is outside the realms of possibility?
HTTPS everywhere is handing a de facto publishing license to every site that can be revoked at will by those that control the levers of power.
I admit this is orthogonal to the issue at hand. It’s just an example I came up with when brewing some tea in the dinette.
In an https-less world the same people in power can just force ISPs to serve different content for a given domain, or force DNS providers to switch the NS to whatever they want, etc. Or worse, they can maliciously modify the content you want served, subtly.
Only being able to revoke a cert is an improvement.
Am I missing something?
Holding the threat of cutting off 99% of internet traffic over the head of media companies is a great way to enforce self-censorship. And the best part is that the victim does all the work themselves!
The original sin of HTTPS was wedding it to a centralized CA structure. But then, the drafters of the Weimar constitution also believed everything would turn out fine.
They’ve just explained to you that HTTPS changes nothing about what the government can do to enact censorship. Hostile governments can turn your internet off without any need for HTTPS. In fact, HTTPS directly attempts to mitigate what the government can do with things like CT logs, etc, and we have seen this work. And in the singular instance where HTTPS provides an attack (revoke cert) you can just trust the cert anyways.
edit: Lobsters is basically completely broken for me (anyone else just getting ‘null’ when posting?) so here is my response to the reply to this post. I’m unable to reply otherwise and I’m getting no errors to indicate why. Anyway…
This is getting ridiculous, frankly.
You’ve conveniently ignored everything I’ve said and focused instead of how a ridiculous attack scenario that has an obvious mitigation has 4 words that somehow you’re relating to SCOTUS and 1st amendment rights? Just glossing over that this attack makes almost no sense whatsoever, glossing over that the far easier attacks apply to HTTP at least as well (or often better) as HTTPS, glossing over the fact that even more attacks are viable against HTTP that aren’t viable against HTTPS, glossing over that we’ve seen CT logs actually demonstrate value against government attackers, etc etc etc. But uh, yeah, SCOTUS.
SCOTUS is going to somehow detect that I trusted a certificate? And… this is somehow worse under HTTPS? They can detect my device accepting a certificate but they can’t detect me accessing content over HTTP? Because somehow the government can’t attack HTTP but can attack HTTPS? This just does not make any sense and you’ve done nothing to justify your points. Users have been more than charitable in explaining this to you, even granting that an attack exists on HTTPS but helpfully explaining to you why it makes no sense.
Going along with your broken threading
My scenario was hypothetical.
In the near future, on the other side of an American Gleichschaltung, a law is passed requiring CAs to revoke specific certificates when ordered.
If the TLS cert for CNN.com is revoked, users will reach a scary warning page telling the user the site cannot be trusted. Depending on the status of “HTTPS Everywhere”, it might not be able to proceed past this page. But crucially, CNN.com remains up, it might be accessible via HTTP (depending on HSTS settings) and the government has done nothing to impede the publication.
But the end effect is that CNN.com is unreadable for the vast number of visitors. This will make the choice of CNN to tone down criticism of the government very easy to make.
The goal of a modern authoritarian regime is not to obsessively police speech to enforce a single worldview. It’s to make it uneconomical or inconvenient to publish content that will lead to opposition to the regime. Media will parrot government talking points or peddle harmless entertainment. There will be an opposition and it will be “protected” by free speech laws, but in practice accessing its speech online will be hard to impossible for the vast majority of people.
I feel like your entire argument hinges on this and it just isn’t true.
If the USA apparatus decides to censor CNN, revoking TLS cert wouldn’t be the way. It’ll be secret court orders (not unlike recent one British government has sent to Apple), and, should they not comply, apprehension of key staff.
And, even if such cert revocation happened, CNN would be able to get new one within seconds by contacting any other ACME CA, there are even some operating in EEA.
I think your whole argument is misguided, and not aimed at understanding failures of Google, but at lashing at only tangentially related problem space.
And my comment is not defence of Google or Cloudflare, I consider both to be malicious for plethora of reasons.
You’re still thinking like the USSR or China or any totalitarian government. The point isn’t to enforce a particular view. The point is to prevent CNN or any other media organization from publishing anything other than pablum, by threatening their ad revenue stream. They will cover government talking points, entertainment, even happily fake news. Like in Russia, “nothing is true and everything is possible”.
Nothing is preventing the US from only allowing certs from US based issuers. Effectively, if you’re using a mainstream browser, the hypothetical law I have sketched out will also affect root CAs.[1]
I proposed a semi-plausible failure mode of the current CA-based certification system and suddenly I’ve gotten more flags than ever before. I find it really interesting.
[1] note that each and every one of these attempts to block access will have quite easy and trivial workarounds. That’s fine, because as stated above, having 100% control of some sort of “truth” is not the point. If nerds and really motivated people can get around a block by installing their own root store or similar, it will just keep them happy to have “cheated the system”. The point is having an atomized audience, incapable of organizing a resistance.
The flags are me and they’re because your posts have been overwhelmingly low quality, consisting of cherry picking, trolling, rhetoric, and failing to engage with anyone’s points. You also never proposed any such attack, other users did you the favor of explaining what attack exists.
The closest thing you’ve come to defining an attack (before others stepped in to hand you one) is this:
It’s not that interesting why you’re getting flagged. IMO flags should be required to have a reason + should be open, but that’s just me, and that’s why I virtually always add a comment when I flag a post.
This is one of the only posts where you’ve almost come close to saying what you think the actual problem is, which if I very charitably interpret and steel-man on your behalf I can take as essentially “The US will exert power over CAs in order to make it hard for news sites to publish content”. This utterly fails, to be clear (as so many people have pointed out that there are far more attacks on HTTP that would work just as well or infinitely better, and as I have pointed out that we have seen HTTPS explicitly add this threat model and try to address it WITH SUCCESS using CT Logs), but at least with enough effort I can extract a coherent point.
I have around 30 flags right now in these threads (plus some from people who took time off their busy schedule to trawl through older comments for semi-plausible ones to flag). You’re not the only one I have pissed off.[1]
(I actually appreciate you replying to my comments but to be honest I find your replies quite rambling and incoherent. I guess I can take some blame for not fully cosplaying as a Project 2025 lawyer, instead relying on vibes.)
It’s fine, though. I’ve grown disillusioned by the EFF style of encryption boosting[2]. I expect them to fold like a cheap suit if and when the gloves come off.
[1] but I’m still net positive on scores, so there are people on the other side too.
[2] they’ve been hyperfocussed on the threat of government threats to free speech, while giving corporations a free pass. They never really considered corporations taking over the government.
Hm, I see. No, I certainly have not flagged all of your posts or anything, just 2 or 3 that I felt were egregious. I think lobsters should genuinely ban more people for flag abuse, tbh, but such is the way.
It’s interesting that my posts come off as rambly. I suppose I just dislike tree-style conversations and lobsters bugs have made following up extremely annoying as my posts just disappear and show as “null”.
I’ve been getting the “null” response too. There’s nothing in the bug tracker right now, and I don’t have IRC access. Hopefully it will be looked at soon.
As to the flags, people might legitimately feel I’m getting too political.
Genuine question, is this aimed at me?
Nope. Unless you are a lawyer for Project 2025.
Yeah, “trust the cert anyway” is going to be the fig leaf used to convince a compliant SCOTUS that revoking a certification is not a blatant violation of the 1st amendment. But at least the daily mandatory webcast from Dear Leader will be guaranteed not to be tampered with during transport!
Wouldn’t you agree that certificate transparency does a better job detecting this kind of thing than surreptitiously redirecting DNS would?
The point of this hypothetical scenario would be that the threat of certificate revocation would be out in the open, to enforce self-censorship to avoid losing traffic/audience. See my comment here:
https://lobste.rs/s/mxy0si/chromecast_2_s_device_authentication#c_lyenlf
Flagged as trolling. I’m also extremely critical of Google’s killing of various services.
I’m not sure any of those are good examples of planned obsolescence. As far as I can tell, they’re all services that didn’t perform very well that Google didn’t want to support, tools that got subsumed into other tools, or ongoing projects that were halted.
I think it’s reasonable to still wish that some of those things were still going, or that they’d been open-sourced in some way so that people could keep them going by themselves, or even that Google themselves had managed them better. But planned obsolescence is quite specifically the idea that you should create things with a limited lifespan so that you can make money by selling their replacements. As far as I can tell, that doesn’t apply to any of those examples.
Trust Google to not even manage to do planned obsolescence right either…
Please refrain from smirky, inflammatory comments.
I get that it’s a tongue in cheek comment, but this is what falls out of “we want our non-https authentication certificates to chain through public roots”.
There is no reason for device authentication to be tied to PKI - it is inherently a private (as in “only relevant to the vendor” , not secret) authentication mechanism so should not be trying to chain through PKI, or PKI-like, roots.
Hyperbole much? Sometimes an expired certificate is just an expired certificate
Why is this a hyperbole? It is clear that even an enterprise the size of Google, famous for it’s leetcode-topping talent is unable to manage certificates at scale. This makes it a pretty good point against uncritical deployment of cryptographic solutions.
Microsoft let microsoft.com lapse that one time. Should we give up on DNS?
When Microsoft did that I wasn’t standing embarrassed in front of my family failing to cast cartoons on the TV. So it was their problem, not my problem.
(It is still bricked today btw)
No one has ever argued for “uncritical deployment” of any solution, let alone cryptographic ones.
Maybe I’m reading too much into “HTTPS everywhere” then.
Maybe. I think there are two ways to interpret it - “HTTPS Everywhere” means “literally every place” or it means “everywhere that makes sense, which is the vast majority of places”. But, to me, neither of these implies “you should deploy in a way that isn’t considered and that will completely destroy a product in the future”, it just means that you should very likely be aiming for a reliable, well supported deployment of HTTPS.
I was replying more to the “planned and enforced obsolescence” conspiracy theorizing.
It is true that managing certificates at scale is something not a lot of large organizations seem to be able to pull off, and that’s a legitimate discussion to have… but I didn’t detect any good faith arguments here, just ranting
Regarding the last issue, it’s worth trying directly via SBCL own FFI (sb-alien) rather than CFFI layer.
We have that old Rockland FFT analyzer with failed supply to the EL backlight for some time now. Going in to see if it could be an easy fix.
Also working on integrating Modbus TCP interface to our product. For a long time we relied on middleware over our WebSocket API done by integrators to do the job. However it’s a bit of headache for everyone to have an extra party involved in every round of changes.
You’ve definitely piqued my interest… can you share what the product is? Modbus isn’t something that most software people have to
dealwork with.Sure, it’s this one. Our phone products have Modbus integration too as it’s very common requirement in the automation world. But Evacsound interface is quite a bit more elaborate.
Thanks! That’s really cool!
For the past 6 months we’ve been banging our heads against APFS running out of disk space on our CI while showing 60GB free space. And I mean, it runs out of disk space hard, can’t even save the
zshhistory.This started with Sonoma. Upgrading to the latest point release made no difference. The internet is littered with what looks like the same problem and the suggested fix is always to empty your trash (can’t you read, I still have tens, even hundreds of GB free, I shouldn’t need to clean my trash). My current theory is that APFS is not able to keep up with recycling some internal garbage and reports it as generic
ENOSPC. Mac OS, at least from the CI perspective, is worse than Windows.P.S. If anyone has any clue what’s going on with APFS space issue, I am all ears.
EDIT: Forgot to add, the bizarre thing is that once you login into such a machine, it’s no longer out of space and you can write as much as you need. This is the reason for my “cannot recycle garbage fast enough” theory.
I do a lot of low level filesystem development and I’ve hit this frequently. It’s like it’s caching globally some free count and it gets desynced and freaks out. Very annoying.
Does your system show any pending updates?
Maybe apfs snapshots?
Nope, looked into this: there are no snapshots besides the standard few and backup is disabled. We’ve even monitored if any transient snapshots are being created during the CI run but didn’t see anything suspicious.
I was going to suggest maybe the 10% buffer that many filesystems keep, but that wouldn’t explain a behavior change once you log in.
The only way I know of to run out of space when you have plenty of space is to run out of inodes. If logging in fixes the problem, that suggests some per-user process such as a LaunchAgent is doing something to fix the problem. And in fact there is a LaunchAgent that deletes caches (
/System/Library/LaunchAgents/com.apple.cache_delete.plist), so perhaps you’ve somehow accumulated so much cache that you’ve run out of inodes? I can’t imagine what might be making so many cache files though.Thanks for the information, much appreciated. I am not familiar with the cache files you are talking about (need to do some research) but I can tell you what we do: we compile (e.g., with Apple Clang) a large number of files and there are quite a few intermediate files being created and deleted in the process by the build system.
So we definitely don’t create any cache files ourselves but it’s possible Apple does automatically (maybe some kind of search indexing).
Another problem with the cache file theory is that we monitored disk space as the build progresses and there is always plenty of free space reported. But it’s possible APFS somehow does not count cache files towards usage.
You monitored disk space, but did you monitor inode count? If you have plenty of disk space but are getting
ENOSPCthen that suggests you’ve run out of inodes.Yes, we need to look into this, thanks. The strange thing is, as I mentioned, it’s temporary, so maybe it can’t recycle inodes fast enough?
Every time this topic comes up I post a similar comment about how hallucinations in code really don’t matter because they reveal themselves the second you try to run that code.
This time I’ve turned that into a blog post: https://simonwillison.net/2025/Mar/2/hallucinations-in-code/
As the person that saw 6 months of copilot kill so many systems due to the accumulation of latent hallucinations… Yeah. No.
That’s fascinating. I’d really enjoy hearing some more about that. Was this a team project? Were there tests? I feel like this would be really valuable as a sort of post mortem.
Lots of different teams and project. I am talking 30% of a 1k engineer department being feature frozen for months to try to dig out of the mess.
And yes there were tests. Tests do not even start to cut it. We are talking death through thousands deep cut.
This is btw not a single anecdote. My network of “we are here to fix shit” people are flooded with these cases. I expect the tech industry output to plummet starting soon.
Again, really interesting and I’ve love more details. I am at a company that has adopted code editors with AI and we have not seen anything like that at all.
That just sounds so extreme to me. Feature frozen for months is something I’ve personally never even heard of, I’ve never experienced anything like that. It feels kind of mind boggling that AI would have done that.
Did developers spend six months checking in code that they hadn’t tested? Because yeah, that’s going to suck. That’s the premise of my post.
Nope. They had tested it. But to test, you have to be able to understand the failure cases. Which you have heuristics for based on how humans write code
These things are trained exactly to avoid this detection. This is how they get good grade. Humans supervising them is not a viable strategy.
I’d like to understand this better. Can you give an example of something a human reviewer would miss because it’s the kind of error a human code author wouldn’t make but an LLM would?
I’m with @Diana here. You test code, but testing does not guarantee the absence of bugs. Testing guarantees the absence of a specific bug that is tested for. LLM-generated code has a habit of failing in surprising ways that humans fail to account for.
This isn’t really my experience unless you just say “write tests”. ex: https://insanitybit.github.io/2025/02/11/i-rolled-my-own-crypto
I used AI primarily for generating test cases, specifically prompting for property tests to check the various properties we expect the cryptography to uphold. A test case found a bug.
“Those are scary things, those gels. You know one suffocated a bunch of people in London a while back?”
Yes, Joel’s about to say, but Jarvis is back in spew mode. “No shit. It was running the subway system over there, perfect operational record, and then one day it just forgets to crank up the ventilators when it’s supposed to. Train slides into station fifteen meters underground, everybody gets out, no air, boom.”
Joel’s heard this before. The punchline’s got something to do with a broken clock, if he remembers it right.
“These things teach themselves from experience, right?,” Jarvis continues. “So everyone just assumed it had learned to cue the ventilators on something obvious. Body heat, motion, CO2 levels, you know. Turns out instead it was watching a clock on the wall. Train arrival correlated with a predictable subset of patterns on the digital display, so it started the fans whenever it saw one of those patterns.”
“Yeah. That’s right.” Joel shakes his head. “And vandals had smashed the clock, or something.”
You imply that because one kind of hallucination is obvious, all hallucinations are so obvious that (per your next 3 paragraphs) the programmer must have been 1. trying to dismiss the tool, 2. inexperienced, or 3. irresponsible.
You describe this as a failing of the programmer that has a clear correction (and elaborate a few more paragraphs):
It is, and I do. Even without LLMs, almost every bug I’ve ever committed to prod has made it past “run it yourself” and the test suite. The state space of programs is usually much larger than we intuit and LLM hallucinations, like my own bugs, don’t always throw exceptions on the first run or look wrong when read.
I think you missed the point of this post. It tells the story of figuring out where one hallucination comes from and claims LLMs are especially prone to producing hallucinations about niche topics. It’s about trying to understand in depth how the tool works and the failure mode that it produces hallucinations that looks plausible to inexperienced programmers; you’re responding with a moral dictum that the user is at fault for not looking at it harder. I’m strongly reminds me of @hwayne’s rebuttal of “discipline” advice (discussion).
What does “running” the code prove?
So LLMs leave the QA to me, while automating the parts that have a degree of freedom and creativity to them.
Can you at least understand why some people are not that excited about LLM code assistants?
In a typed system, it proves that your code conforms to the properties of its input and output types, which is nice. In a tested system it proves whatever properties you believe your tests uphold.
QA was always on you. If you don’t enjoy using one, don’t? If you feel that it takes your freedom and creativity away, don’t use it. I don’t use LLMs for a ton of my work, especially the creative stuff.
Which is at odds with the claim in the same sentence, that ‘comprehensive automated tests’ will not prove that code does the right thing. And yes, you can argue that the comprehensive tests might be correct, but do not evaluate the properties you expect the results to have, if you want to split hairs.
Evaluating code for correctness is the hard problem in programming. I don’t think anyone expected LLMs to make that better, but there’s a case to be made that LLMs will make it harder. Code-sharing platforms like Stack Overflow or Github at least provide some context about the fitness of the code, and facilitate feedback.
The article is supposed to disprove that, but all it does is make some vague claims about “running” the code (while simultaneously questioning the motives of people who distrust LLM-generated code). I don’t think it’s a great argument.
Ah, I see what you mean. Yes, I don’t think that “running” code is sufficient testing for hallucinations.
What did you think my article was trying to disprove?
It’s an article that’s mainly about all the ways LLMs can mislead you that aren’t as obvious as hallucinating a method that doesn’t exist. Even the title contains an implicit criticism of LLMs: “Hallucinations in code are the least dangerous form of LLM mistakes”.
If anything, this is a piece about why people should “distrust LLM-generated code” more!
Ah, if you restrict ‘hallucinations’ to specifically mean non-extant functions or variables, then I can see where you’re coming from.
Because they don’t enjoy QA.
I don’t enjoy manual QA myself, but I’ve had to teach each myself to get good at it - not because of LLMs, but because that’s what it takes to productively ship good software.
I actually disagree a little bit here. QA’ing every bit of functionality you use is never going to scale. At some level you have to trust the ability of your fellow human beings to fish out bugs and verify correctness. And yes, it’s easy for that trust to be abused, by supply chain attacks and even more complicated “Jia Tan”-like operations.
But just like LLMs can be said to do copyright laundering, they also launder trust, because it’s impossible for them to distinguish example code from working code, let alone vulnerable code from safe code.
That’s fair - if you’re working on a team with shared responsibility for a codebase you should be able to trust other team members to test their code.
You can’t trust an LLM to test its code.
What I meant was something slightly different. Almost every piece of software that’s not a bootloader runs on a distributed stack of trust. I might trust a particular open source library, I might trust the stdlib, or the operating system itself. Most likely written by strangers on the internet. It’s
curl | sudo bashall the way down.The action of importing code from github, or even copy-pasting it from stack overflow, is qualitatively different from that of trusting the output of an LLM, because an LLM gives you no indication as to whether the code has been verified.
I’d go so far as to say the fact that an LLM emitted the code gives you the sure indication it has not been verified and must be tested—the same as if I wrote quicksort on a whiteboard from memory.
I think this post is more than just another “LLMs bad” post, though I did enjoy your response post as a standalone piece. The author ‘s co-worker figured out it didn’t work pretty quickly. It’s more interesting to me that the author found the source of the hallucination, and that it was a hypothetical that the author themselves had posed.
That’s why I didn’t link to the “Making o1, o3, and Sonnet 3.7 Hallucinate for Everyone” post from mine - I wasn’t attempting a rebuttal of that, I was arguing against a common theme I see in discussions any time the theme of hallucinations in code is raised.
I turned it into a full post when I found myself about to make the exact same point once again.
And that’s fair enough - in context I read your comment as a direct reply. I appreciate all the work you’ve been doing on sharing your experience, Simon!
This is an extremely strong statement.
I think a few things are also interesting:
I think people are realizing how low quality the Linux kernel code is, how haphazard development is, how much burnout and misery is involved, etc.
I think people are realizing how insanely not in the open kernel dev is, how much is private conversations that a few are privy to, how much is politics, etc.
The Hellwig/Ojeda part of the thread is just frustrating to read because it almost feels like pleading. “We went over this in private” “we discussed this already, why are you bringing it up again?” “Linus said (in private so there’s no record)”, etc., etc.
Dragging discussions out in front of an audience is a pretty decent tactic for dealing with obstinate maintainers. They don’t like to explain their shoddy reasoning in front of people, and would prefer it remain hidden. It isn’t the first tool in the toolbelt but at a certain point there is no convincing people directly.
With quite a few things actually. A friend of mine is contributing to a non-profit, which until recently had this very toxic member (they’ve even attempted felony). They were driven out of the non-profit very soon after members talked in a thread that was accessible to all members. Obscurity is often one key component of abuse, be it mere stubbornness or criminal behaviour. Shine light, and it often goes away.
IIRC Hintjens noted this quite explicitly as a tactic of bad actors in his works.
It’s amazing how quickly people are to recognize folks trying to subvert an org piecemeal via one-off private conversations once everybody can compare notes. It’s equally amazing to see how much the same people beforehand will swear up and down oh no that’s a conspiracy theory such things can’t happen here until they’ve been burned at least once.
This is an active, unpatched attack vector in most communities.
I’ve found the lowest example of this is even meetings minutes at work. I’ve observed that people tend to act more collaboratively and seek the common good if there are public minutes, as opposed to trying to “privately” win people over to their desires.
There is something to be said for keeping things between people with skin in the game.
It’s flipped over here, though, because more people want to contribute. The question is whether it’ll be stabe long-term.
Something I’ve noticed is true in virtually everything I’ve looked deeply at is the majority of work is poor to mediocre and most people are not especially great at their jobs. So it wouldn’t surprise me if Linux is the same. (…and also wouldn’t surprise me if the wonderful Rust rewrite also ends up poor to mediocre.)
yet at the same time, another thing that astonishes me is how much stuff actually does get done and how well things manage to work anyway. And Linux also does a lot and works pretty well. Mediocre over the years can end up pretty good.
After tangentially following the kernel news, I think a lot of churning and death spiraling is happening. I would much rather have a rust-first kernel that isn’t crippled by the old guard of C developers reluctant to adopt new tech.
Take all of this energy into RedoxOS and let Linux stay in antiquity.
I’ve seen some of the R4L people talk on Mastodon, and they all seem to hate this argument.
They want to contribute to Linux because they use it, want to use it, and want to improve the lives of everyone who uses it. The fact that it’s out there and deployed and not a toy is a huge part of the reason why they want to improve it.
Hopping off into their own little projects which may or may not be useful to someone in 5-10 years’ time is not interesting to them. If it was, they’d already be working on Redox.
The most effective thing that could happen is for the Linux foundation, and Linus himself, to formally endorse and run a Rust-based kernel. They can adopt an existing one or make a concerted effort to replace large chunks of Linux’s C with Rust.
IMO the Linux project needs to figure out something pretty quickly because it seems to be bleeding maintainers and Linus isn’t getting any younger.
They may be misunderstanding the idea that others are not necessarily incentivized to do things just because it’s interesting for them (the Mastodon posters).
Yep, I made a similar remark upthread. A Rust-first kernel would have a lot of benefits over Linux, assuming a competent group of maintainers.
along similar lines: https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html
Redox does have the chains of trying to do new OS things. An ABI-compatible Rust rewrite of the Linux kernel might get further along than expected (even if it only runs in virtual contexts, without hardware support (that would come later.))
Linux developers want to work on Linux, they don’t want to make a new OS. Linux is incredibly important, and companies already have Rust-only drivers for their hardware.
Basically, sure, a new OS project would be neat, but it’s really just completely off topic in the sense that it’s not a solution for Rust for Linux. Because the “Linux” part in that matters.
I read a 25+ year old article [1] from a former Netscape developer that I think applies in part
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?Adopting a “rust-first” kernel is throwing the baby out with the bathwater. Linux has been beaten into submission for over 30 years for a reason. It’s the largest collaborative project in human history and over 30 million lines of code. Throwing it out and starting new would be an absolutely herculean effort that would likely take years, if it ever got off the ground.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
The idea that old code is better than new code is patently absurd. Old code has stagnated. It was built using substandard, out of date methodologies. No one remembers what’s a bug and what’s a feature, and everyone is too scared to fix anything because of it. It doesn’t acquire new bugs because no one is willing to work on that weird ass bespoke shit you did with your C preprocessor. Au contraire, baby! Is software supposed to never learn? Are we never to adopt new tools? Can we never look at something we’ve built in an old way and wonder if new methodologies would produce something better?
This is what it looks like to say nothing, to beg the question. Numerous empirical claims, where is the justification?
It’s also self defeating on its face. I take an old codebase, I fix a bug, the codebase is now new. Which one is better?
Like most things in life the truth is somewhere in the middle. There is a reason there is the concept of a “mature node” in the semiconductor industry. They accept that new is needed for each node, but also that the new thing takes time to iron out the kinks and bugs. This is the primary reason why you see apple take new nodes on first before Nvidia for example, as Nvidia require much larger die sizes, and so less defects per square mm.
You can see this sometimes in software for example X11 vs Wayland, where adoption is slow, but most definetly progressing and now-days most people can see that Wayland is now, or is going to become the dominant tech in the space.
The truth lies where it lies. Maybe the middle, maybe elsewhere. I just don’t think we’ll get to the truth with rhetoric.
Aren’t the arguments above more dialectic than rhetoric?
I don’t think this would qualify as dialectic, it lacks any internal debate and it leans heavily on appeals by analogy and intuition/ emotion. The post itself makes a ton of empirical claims without justification even beyond the quoted bit.
fair enough, I can see how one would make that argument.
“Good” is subjective, but there is real evidence that older code does contain fewer vulnerabilities: https://www.usenix.org/conference/usenixsecurity22/presentation/alexopoulos
That means we can probably keep a lot of the old trusty Linux code around while making more of the new code safe by writing it in Rust in the first place.
I don’t think that’s a fair assessment of Spolsky’s argument or of CursedSilicon’s application of it to the Linux kernel.
Firstly, someone has already pointed out the research that suggests that existing code has fewer bugs in than new code (and that the older code is, the less likely it is to be buggy).
Secondly, this discussion is mainly around entire codebases, not just existing code. Codebases usually have an entire infrastructure around them for verifying that the behaviour of the codebase has not changed. This is often made up of tests, but it’s also made up of the users who try out a release of a codebase and determine whether it’s working for them. The difference between making a change to an existing codebase and releasing a new project largely comes down to whether this verification (both in terms of automated tests and in terms of users’ ability to use the new release) works for the new code.
Given this difference, if I want to (say) write a new OS completely in Rust, I need to choose: Do I want to make it completely compatible with Linux, and therefore take on the significant challenge of making sure everything behaves truly the same? Or do I make significant breaking changes, write my own OS, and therefore force potential adopters to rebuild their entire Linux workflows in my new OS?
The point is not that either of these options are bad, it is that they represent significant risks to a project. Added to the general risk that is writing new code, this produces a total level of risk that might be considered the baseline risk of doing a rewrite. Now risk is not bad per se! If the benefits of being able to write an OS in a language like Rust outweigh the potential risks, then it still makes sense to perform the rewrite. Or maybe the existing Linux kernel is so difficult to maintain that a new codebase really would be the better option. But the point that CursedSilicon was making by linking the Spolsky piece was, I believe, that the risks for a project like the Linux kernel are very high. There is a lot of existing, old code. And there is a very large ecosystem where either breaking or maintaining compatibility would each come with significant challenges.
Unfortunately, it’s very difficult to measure the risks and benefits here in a quantitative, comparable way, so I think where you fall on the “rewrite vs continuity” spectrum will depend mostly on what sort of examples you’ve seen, and how close you think this case is to those examples. I don’t think there’s any objective way to say whether it makes more sense to have something like R4L, or something like RedoxOS.
I haven’t read it yet, but I haven’t made an argument about that, I just created a parody of the argument as presented. I’ll be candid, i doubt that the research is going to compel me to believe that newer code is inherently buggier, it may compel me to confirm my existing belief that testing software in the field is one good method to find some classes of bugs.
I guess so, it’s a bit dependent on where we say the discussion starts - three things are relevant; RFL, which is not a wholesale rewrite, a wholesale rewrite of the Linux kernel, and Netscape. RFL is not about replacing the entire Linux kernel, although perhaps “codebase” here refers to some sort of unit, like a driver. Netscape wanted a wholesale rewrite, based on the linked post, so perhaps that’s what’s really “the single worst strategic mistake that any software company can make”, but I wonder what the boundary here is? Also, the article immediately mentions that Microsoft tried to do this with Word but it failed, but that Word didn’t suffer from this because it was still actively developed - I wonder if it really “failed” just because pyramid didn’t become the new Word? Did Microsoft have some lessons learned, or incorporate some of that code? Dunno.
I think I’m really entirely justified when I say that the post is entirely emotional/ intuitive appeals, rhetoric, and that it makes empirical claims without justification.
This is rhetoric. These are unsubstantiated empirical claims. The article is all of this. It’s fine as an interesting, thought provoking read that gets to the root of our intuitions, but I think anyone can dismiss it pretty easily since it doesn’t really provide much in the form of an argument.
Again, totally unsubstantiated. I have MANY reasons to believe that, it is simply question begging to say otherwise.
That’s all this post is. Over and over again making empirical claims with no evidence and question beggign.
We can discuss the risks and benefits, I’d advocate for that. This article posted doesn’t advocate for that. It’s rhetoric.
This is a truism. It is survival bias. If the code was buggy, it would eventually be found and fixed. So all things being equal newer code is riskier than old code. But it’s also been impirically shown that using Rust for new code is not “all things being equal”. Google showed that new code in Rust is as reliable as old code in C. Which is good news: you can use old C code from new Rust projects without the risk that comes from new C code.
Yeah, this is what I’ve been saying (not sure if you’d meant to respond to me or the parent, since we agree) - the issue isn’t “new” vs “old” it’s things like “reviewed vs unreviewed” or “released vs unreleased” or “tested well vs not tested well” or “class of bugs is trivial to express vs class of bugs is difficult to express” etc.
Was restating your thesis in the hopes of making it clearer.
I don’t disagree that the rewards can outweigh the risks, and in this case I think there’s a lot of evidence that suggests that memory safety as a default is really important for all sorts of reasons. Let alone the many other PL developments that make Rust a much more suitable language to develop in than C.
That doesn’t mean the risks don’t exist, though.
Nobody would call an old codebase with a handful of fixes a new codebase, at least not in the contexts in which those terms have been used here.
How many lines then?
It’s a Ship of Theseus—at no point can you call it a “new” codebase, but after a period of time, it could be completely different code. I have a C program I’ve been using and modifying for 25 years. At any given point, it would have been hard to say “this is now a new codebase, yet not one line of code in the project is the same as when I started (even though it does the same thing at it always has).
I don’t see the point in your question. It’s going to depend on the codebase, and on the nature of the changes; it’s going to be nuanced, and subjective at least to some degree. But the fact that it’s prone to subjectivity doesn’t mean that you get to call an old codebase with a single fixed bug a new codebase, without some heavy qualification which was lacking.
If it requires all of that nuance and context maybe the issue isn’t what’s “old” and what’s “new”.
I don’t follow, to me that seems like a non-sequitur.
What’s old and new is poorly defined and yet there’s an argument being made that “old” and “new” are good indicators of something. If they’re so poorly defined that we have to bring in all sorts of additional context like the nature of the changes, not just when they happened or the number of lines changed, etc, then it seems to me that we would be just as well served to throw away the “old” and “new” and focus on that context.
I feel like enough people would agree more-or-less on what was an “old” or “new” codebase (i.e. they would agree given particular context) that they remain useful terms in a discussion. The general context used here is apparent (at least to me) given by the discussion so far: an older codebase has been around for a while, has been maintained, has had kinks ironed out.
There’s a really important distinction here though. The point is to argue that new projects will be less stable than old ones, but you’re intuitively (and correctly) bringing in far more important context - maintenance, testing, battle testing, etc. If a new implementation has a higher degree of those properties then it being “new” stops being relevant.
Ok, but:
My point was that this statement requires a definition of “new codebase” that nobody would agree with, at least in the context of the discussion we’re in. Maybe you are attacking the base proposition without applying the surrounding context, which might be valid if this were a formal argument and not a free-for-all discussion.
I think that it would be considered no longer new if it had had significant battle-testing, for example.
FWIW the important thing in my view is that every new codebase is a potential old codebase (given time and care), and a rewrite necessarily involves a step backwards. The question should probably not be, which is immediately better?, but, which is better in the longer term (and by how much)? However your point that “new codebase” is not automatically worse is certainly valid. There are other factors than age and “time in the field” that determine quality.
Methodologies don’t matter for quality of code. They could be useful for estimates, cost control, figuring out whom you shall fire etc. But not for the quality of code.
You’re suggesting that the way you approach programming has no bearing on the quality of the produced program?
I’ve never observed a programmer become better or worse by switching methodology. Dijkstra would’ve not became better if you made him do daily standups or go through code reviews.
There are ways to improve your programming by choosing different approach but these are very individual. Methodology is mostly a beancounting tool.
When I say “methodology” I’m speaking very broadly - simply “the approach one takes”. This isn’t necessarily saying that any methodology is better than any other. The way I approach a task today is better, I think, then the way that I would have approached that task a decade ago - my methodology has changed, the way I think has changed. Perhaps that might mean I write more tests, or I test earlier, but it may mean exactly the opposite, and my methods may only work best for me.
I’m not advocating for “process” or ubiquity, only that the approach one tasks may improve over time, which I suspect we would agree on.
If you take this logic to its end, you should never create new things.
At one point in time, Linux was also the new kid on the block.
The best time to plant a tree is 30 years ago. The second best time is now.
I don’t think Joel Spolsky was ever a Netscape developer. He was a Microsoft developer who worked on Excel.
My mistake! The article contained a bit about Netscape and I misremembered it
How many of those lines are part of the core? My understanding was that the overwhelming majority was driver code. There may not be that much core subsystem code to rewrite.
For a previous project, we included a minimal Linux build. It was around 300 KLoC, which included networking and the storage stack, along with virtio drivers.
That’s around the size a single person could manage and quite easy with a motivated team.
If you started with DPDK and SPDK then you’d already have filesystems and a copy of the FreeBSD network stack to run in isolated environments.
Once many drivers share common rust wrappers over core subsystems, you could flip it and write the subsystem in Rust. Then expose C interface for the rest.
Oh sure, that would be my plan as well. And I bet some subsystem maintainers see this coming, and resist it for reasons that aren’t entirely selfless.
That’s pretty far into the future, both from a maintainer acceptance PoV and from a rustc_codegen_gcc and/or gccrs maturity PoV.
Sure. But I doubt I’ll running a different kernel 10y from now.
And like us, those maintainers are not getting any younger and if they need a hand, I am confident I’ll get faster into it with a strict type checker.
I am also confident nobody in our office would be able to help out with C at all.
This cannot possibly be true.
It’s the largest collaborative open source os kernel project in human history
It’s been described as such based purely on the number of unique human contributions to it
I would expect Wikipedia should be bigger 🤔
I see that Drew proposes a new OS in that linked article, but I think a better proposal in the same vein is a fork. You get to keep Linux, but you can start porting logic to Rust unimpeded, and it’s a manageable amount of work to keep porting upstream changes.
Remember when libav forked from ffmpeg? Michael Niedermayer single-handedly ported every single libav commit back into ffmpeg, and eventually, ffmpeg won.
At first there will be extremely high C percentage, low Rust percentage, so porting is trivial, just git merge and there will be no conflicts. As the fork ports more and more C code to Rust, however, you start to have to do porting work by inspecting the C code and determining whether the fixes apply to the corresponding Rust code. However, at that point, it means you should start seeing productivity gains, community gains, and feature gains from using a better language than C. At this point the community growth should be able to keep up with the extra porting work required. And this is when distros will start sniffing around, at first offering variants of the distro that uses the forked kernel, and if they like what they taste, they might even drop the original.
I genuinely think it’s a strong idea, given the momentum and potential amount of labor Rust community has at its disposal.
I think the competition would be great, especially in the domain of making it more contributor friendly to improve the kernel(s) that we use daily.
I certainly don’t think this is impossible, for sure. But the point ultimately still stands: Linux kernel devs don’t want a fork. They want Linux. These folks aren’t interested in competing, they’re interested in making the project they work on better. We’ll see if some others choose the fork route, but it’s still ultimately not the point of this project.
While I don’t personally want to make a new OS, I’m not sure I actually want to work on Linux. Most of the time I strive for portability, and so abstract myself from the OS whenever I can get away with it. And when I can’t, I have to say Linux’s API isn’t always that great, compared to what the BSDs have to offer (epoll vs kqueue comes to mind). Most annoying though is the lack of documentation for the less used APIs: I’ve recently worked with Netlink sockets, and for the proc stuff so far the best documentation I found was the freaking source code of a third party monitoring program.
I was shocked. Complete documentation of the public API is the minimum bar for a project as serious of the Linux kernel. I can live with an API I don’t like, but lack of documentation is a deal breaker.
I think they mean that Linux kernel devs want to work on the Linux kernel. Most (all?) R4L devs are long time Linux kernel devs. Though, maybe some of the people resigning over LKML toxicity will go work on Redox or something…
That’s is what I was saying, yes.
I’m talking about the people who develop the Linux kernel, not people who write userland programs for Linux.
Re-Implementing the kernel ABI would be a ton of work for little gain if all they wanted was to upstream all the work on new hardware drivers that is already done - and then eventually start re-implementing bits that need to be revised anyway.
If the singular required Rust toolchain didn’t feel like such a ridiculous to bootstrap 500 ton LLVM clown car I would agree with this statement without reservation.
Would zig be a better starting place?
Zig is easier to implement (and I personally like it as a language) but doesn’t have the same safety guarantees and strong type system that Rust does. It’s a give and take. I actually really like Rust and would like to see a proliferation of toolchain options, such as what’s in progress in GCC land. Overall, it would just be really nice to have an easily bootstrapped toolchain that a normal person can compile from scratch locally, although I don’t think it necessarily needs to be the default, or that using LLVM generally is an issue. However, it might be possible that no matter how you architect it, Rust might just be complicated enough that any sufficiently useful toolchain for the language could just end up being a 500 ton clown car of some kind anyways.
Depends on which parts of GP’s statement you care about: LLVM or bootstrap. Zig is still depending on LLVM (for now), but it is no longer bootstrappable in a limited number of steps (because they switched from a bootstrap C++ implementation of the compiler to keeping a compressed WASM build of the compiler as a blob.
Yep, although I would also add it’s unfair to judge Zig in any case on this matter now given it’s such a young project that clearly is going to evolve a lot before the dust begins to settle (Rust is also young, but not nearly as young as Zig). In ten to twenty years, so long as we’re all still typing away on our keyboards, we might have a dozen Zig 1.0 and a half dozen Zig 2.0 implementations!
Yeah, the absurdly low code quality and toxic environment make me think that Linux is ripe for disruption. Not like anyone can produce a production kernel overnight, but maybe a few years of sustained work might see a functional, production-ready Rust kernel for some niche applications and from there it could be expanded gradually. While it would have a lot of catching up to do with respect to Linux, I would expect it to mature much faster because of Rust, because of a lack of cruft/backwards-compatibility promises, and most importantly because it could avoid the pointless drama and toxicity that burn people out and prevent people from contributing in the first place.
What is the, some kind of a new meme? Where did you hear it first?
From the thread in OP, if you expand the messages, there is wide agreement among the maintainers that all sorts of really badly designed and almost impossible to use (safely) APIs ended up in the kernel over the years because the developers were inexperienced and kind of learning kernel development as they went. In retrospect they would have designed many of the APIs very differently.
Someone should compile everything to help future OS developers avoid those traps! There are a lot of exieting non-posix experiments though.
It’s based on my forays into the Linux kernel source code. I don’t doubt there’s some quality code lurking around somewhere, but the stuff I’ve come across (largely filesystem and filesystem adjacent) is baffling.
Seeing how many people are confidently incorrect about Linux maintainers only caring about their job security and keeping code bad to make it a barrier to entry, if nothing else taught me how online discussions are a huge game of Chinese whispers where most participants don’t have a clue of what they are talking about.
I doubt that maintainers are “only caring about their job security and keeping back code” but with all due respect: You’re also just taking arguments out of thin air right now. What I do believe is what we have seen: Pretty toxic responses from some people and a whole lot of issues trying to move forward.
Huh, I’m not seeing any claim to this end from the GP, or did I not look hard enough? At face value, saying that something has an “absurdly low code quality” does not imply anything about nefarious motives.
I can personally attest to having never made that specific claim.
Indeed that remark wasn’t directly referring to GP’s comment, but rather to the range of confidently incorrect comments that I read in the previous episodes, and to the “gatekeeping greybeards” theme that can be seen elsewhere on this page. First occurrence, found just by searching for “old”: Linux is apparently “crippled by the old guard of C developers reluctant to adopt new tech”, to which GP replied in agreement in fact. Another one, maintainers don’t want to “do the hard work”.
Still, in GP’s case the Chinese whispers have reduced “the safety of this API is hard to formalize and you pretty much have to use it the way everybody does it” to “absurdly low quality”. To which I ask, what is more likely. 1) That 30-million lines of code contain various levels of technical debt of which maintainers are aware; and that said maintainers are worried even of code where the technical debt is real but not causing substantial issue in practice? Or 2) that a piece of software gets to run on literally billions of devices of all sizes and prices just because it’s free and in spite of its “absurdly low quality”?
Linux is not perfect, neither technically nor socially. But it sure takes a lot of entitlement and self-righteousness to declare it “of absurdly low quality” with a straight face.
GP here: I probably should have said “shockingly” rather than “absurdly”. I didn’t really expect to get lawyered over that one word, but yeah, the idea was that for a software that runs on billions of devices, the code quality is shockingly low.
Of course, this is plainly subjective. If your code quality standards are a lot lower than mine then you might disagree with my assessment.
That said, I suspect adoption is a poor proxy for code quality. Internet Explorer was widely adopted and yet it’s broadly understood to have been poorly written.
I’m sure self-righteousness could get you to the same place, but in my case I arrived by way of experience. You can relax, I wasn’t attacking Linux—I like Linux—it just has a lot of opportunity for improvement.
I guess I’ve seen the internals of too much proprietary software now to be shocked by anything about Linux per se. I might even argue that the quality of Linux is surprisingly good, considering its origins and development model.
I think I’d lawyer you a tiny bit differently: some of the bugs in the kernel shock me when I consider how many devices run that code and fulfill their purposes despite those bugs.
FWIW, I was not making a dig at open source software, and yes plenty of corporate software is worse. I guess my expectations for Linux are higher because of how often it is touted as exemplary in some form or another. I don’t even dislike Linux, I think it’s the best thing out there for a huge swath of use cases—I just see some pretty big opportunities for improvement.
Or actual benchmarks: the performance the Linux kernel leaves on the table in some cases is absurd. And sure it’s just one example, but I wouldn’t be surprised if it was representative of a good portion of the kernel.
Well not quite but still “considered broken beyond repair by many people related to life time management” - which is definitely worse than “hard to formalize” when “the way ever[y]body does it” seems to vary between each user.
I love Rust but still, we’re talking of a language which (for good reasons!) considers doubly linked lists unsafe. Take an API that gets a 4 on Rusty Russell’s API design scale (“Follow common convention and you’ll get it right”), but which was designed for a completely different programming language if not paradigm, and it’s not surprising that it can’t easily be transformed into a 9 (“The compiler/linker won’t let you get it wrong”). But at the same time there are a dozen ways in which, according to the same scale, things could actually be worse!
What I dislike is that people are seeing “awareness of complexity” and the message they spread is “absurdly low quality”.
Note that doubly linked lists are not a special case at all in Rust. All the other common data structures like
Vec,HashMapetc. also need unsafe code in their implementation.Implementing these datastructures in Rust, and writing unsafe code in general, is indeed roughly a 4. But these are all already implemented in the standard library, with an API that actually is at a 9. And
std::collections::LinkedListis constructive proof that you can have a safe Rust abstraction for doubly linked lists.Yes, the implementation could have bugs, thus making the abstraction leaky. But that’s the case for literally everything, down to the hardware that your code runs on.
You’re absolutely right that you can build abstractions with enough effort.
My point is that if a doubly linked list is (again, for good reasons) hard to make into a 9, a 20-year-old API may very well be even harder. In fact,
std::collections::LinkedListis safe but still not great (for example the cursor API is still unstable); and being in std, it was designed/reviewed by some of the most knowledgeable Rust developers, sort of by definition. That’s the conundrum that maintainers face and, if they realize that, it’s a good thing. I would be scared if maintainers handwaved that away.Bugs happen, but if the abstraction is downright wrong then that’s something I wouldn’t underestimate. A lot of the appeal of Rust in Linux lies exactly in documenting/formalizing these unwritten rules, and wrong documentation can be worse than no documentation (cue the negative parts of the API design scale!); even more so if your documentation is a formal model like a set of Rust types and functions.
That said, the same thing can happen in a Rust-first kernel, which will also have a lot of unsafe code. And it would be much harder to fix it in a Rust-first kernel, than in Linux at a time when it’s just feeling the waters.
At the same time, it was included almost as like, half a joke, and nobody uses it, so there’s not a lot of pressure to actually finish off the cursor API.
It’s also not the kind of linked list the kernel would use, as they’d want an intrusive one.
And yet, safe to use doubly linked lists written in Rust exist. That the implementation needs unsafe is not a real problem. That’s how we should look at wrapping C code in safe Rust abstractions.
The whole comment you replied to, after the one sentence about linked lists, is about abstractions. And abstractions are rarely going to be easy, and sometimes could be hardly possible.
That’s just a fact. Confusing this fact for something as hyperbolic as “absurdly low quality” is stunning example of the Dunning Kruger effect, and frankly insulting as well.
I personally would call Linux low quality because many parts of it are buggy as sin. My GPU stops working properly literally every other time I upgrade Linux.
No one is saying that Linux is low quality because it’s hard or impossible to abstract some subsystems in Rust, they’re saying it’s low quality because a lot of it barely works! I would say that your “Chinese whispers” misrepresents the situation and what people here are actually saying. “the safety of this API is hard to formalize and you pretty much have to use it the way everybody does it” doesn’t apply if no one can tell you how to use an API, and everyone does it differently.
I agree, Linux is the worst of all kernels.
Except for all the others.
Actually, the NT kernel of all things seems to have a pretty good reputation, and I wouldn’t dismiss the BSD kernels out of hand. I don’t know which kernel is better, but it seems you do. If you could explain how you came to this conclusion that would be most helpful.
NT gets a bad rap because of the OS on top of it, not because it’s actually bad. NT itself is a very well-designed kernel.
*nod* I haven’t been a Windows person since shortly after the release of Windows XP (i.e. the first online activation DRM’d Windows) but, whenever I see glimpses of what’s going on inside the NT kernel in places like Project Zero: The Definitive Guide on Win32 to NT Path Conversion, it really makes me want to know more.
More likely a fork that gets rusted from the inside out
Somewhere else it was mentioned that most developers in the kernel could just not be bothered with checking for basic things.
Nobody is forcing any of these people to do this.
So one of our tunnel evacuation system deliveries had started reporting fires every morning at one of the tunnel’s exits. Turned out that technically it is a huge one but is safely away at 1AU. Hence coding a mitigation for it this week.
Let me guess, sunlight shining on a sensor?
We use adjacent sensors in the network to filter out false positives. Which generally works quite well but there, during few weeks in the winter the sun hits two sensors in a short sequence.
D’oh missed the 1AU reference!
Are there a lot of common lisp and Java code bases that need integration? I figured any big Java shop that wanted to dip their toe in lisp used Clojure.
They do state that it’s intended for when you want to use SBCL, but need that one Java library.
I believe it’s a one person hobby project, not something intended to solve issues in corporate development.
Hey .. I’m the author. This project is just scratching a specific itch for me.
Or they’d use Armed Bear Common Lisp, which is a compliant CL implementation running on the JVM.
HiSoft C: a K&R based compiler from 1984 for Z-80 based micros. Not very commercially relevant but it was my first encounter with a C compiler.
The first thing I’d remark is that while one can buy old testgear from Fluke, HP, Tektronix et al. relatively cheaply, it is basically top-of-the-line stuff which is in no way comparable with no-brand imports. If it doesn’t perform well, that’s likely to be because components are failing after many years service: in most (but not all) cases that’s fixable.
The second thing is that devices like TinySA are in a league of their own: not as capable as classic gear from HP et al., but by no means junk particularly if one buys from the designer rather than falling for a knockoff.
You can do a great deal with cheap (predominantly Chinese) testgear, but have to be aware of its limitations. For example, I’ve got a “pretty but cheap” bench power supply that has an enormous amount of noise on its output (see https://github.com/MarkMLl/dsocat/raw/main/DSO-Cat_2021-01-29T09_35_07.png) which would make any attempt to debug a noisy circuit powered by it futile. I’ve also got a cheap multimeter (which after limited use is showing symptoms of a dodgy range selector), a cheap ’scope (good for a few kHz before sampling artifacts intrude), a PC-based logic analyser and so on.
But I’ve also got a vintage ’scope for the rare occasions where hefting its bulk is really essential, and a vintage logic analyser. And the latter in particular- 65 channels, withstanding 48V per channel, and good for 10 nSec resolution- will put most modern stuff to shame.
Please don’t get me wrong: I’m not trying to boast about picking up some good deals there. The important thing is that you can get marginally-usable modern gear for a pittance, and it will work up to a point. But you have to understand where that point is and how it affects whatever you’re trying to do, and to do that it’s useful to have- or at least have access to- more expensive older gear even if you don’t use it every day.
As an aside, TinySA had found an unexpected application in the modern trench warfare in Ukraine. At this point its military use probably outstrips the civilian.
And I concur old top brands are still generally a better value. Especially the odd unique niche pieces (looking at my HP53310A) which don’t have large enough market for cheap new substitutes.
Perhaps the most public example of “ploughshares into swords” is the heavy use of civilian drones to harass the aggressor.
I was of course thinking about HP when I equivocated about repairing older kit: they fairly regularly used custom chips, and finding a writeup in the HP Journal is no substitute for finding a working spare.
However, as with many things hacker-related, technology has moved on to the extent that sometimes it’s just about possible to fabricate a replacement component: see for example https://hackaday.com/2014/04/21/rebuilding-a-custom-ic-saves-hp-pulse-generator/
Wouldn’t the total energy draw be the area under the curve here? If that’s the case, the graphs show that serving TLS actually uses about 40% more energy (eyeballing it), that regular http requests. Am I missing something?
You really don’t.
The point of TLS everywhere is clear from the security and labor-economic perspectives. However it was bewildering to read some people believe it is also zero energy overhead.
The author now appears to stress how ISP content injection could nullify the difference but it doesn’t sound credible. Such bottom feeder providers were niche even in their heyday and petered out long before letsencrypt movement picked up. Also a significant portion of worldwide HTTPS traffic is intra-app/services.
No, the difference in the total area under the curve is mainly made up from the SoC clocking down. The actual difference in power usage due to “additional silicon” being active is the difference when both curves are in the period in which they do work.
Well well, that terrible oil loving guy (how else in Norway, right?) was me. For the record I am late Gen X. AMA I guess?
EDIT: for the context the blog post was since edited.
What did you have for breakfast and why was it a huge barrel of crude oil?
How’s the brown cheese?
It has never been better! Used my last pack on the sauce for xmas dinner.
I have also encountered people (online) who didn’t know that you could render web pages on the server.
React was their default; I saw some static websites that were just static JSX in React. Like if you wanted to put up some photos of your apartment or vacation on your own domain, you would create a React app for that.
People learn by imitation, and that’s 100% necessary in software, so it’s not too surprising. But yeah this is not a good way to do it.
The web is objectively worse that way, i.e. if you have ever seen an non-technical older person trying to navigate the little pop-out hamburger menus and so forth. Or a person without a fast mobile connection.
If I look back a couple decades, when I used Windows, I definitely remember that shell and FTP were barriers to web publishing. It was hard to figure out where to put stuff, and how to look at it.
And just synchronizing it was a problem
PHP was also something I never understood until I learned shell :-) I can see how JavaScript is more natural than PHP for some, even though PHP lets you render on the server.
To be fair, JSX is a pleasurable way to sling together HTML, regardless of if it’s on the frontend or backend.
Many backend server frameworks have things similar to JSX.
That’s not completely true, one beautiful JSX thing is that any JSX HTML node is a value, you can use all your language at your disposal to create that HTML. Most backend server frameworks use templating instead. For most cases both are equivalent, but sometimes being able to put HTML values in lists and dictionaries and have the full power of the language do come in handy.
Well, that’s exactly what your OP said. Here is an example in Scala. It’s the same style. It’s not like this was invented by react or even by frontend libraries. In fact, Scalatags for example is even better than JSX because it is really just values and doesn’t even need any special syntax preprocessor. It is pure, plain Scala code.
Maybe, but then just pick a better one? OP said “many” and not “most”.
Fine, I misread many as most as I had just woken up. But I’m a bit baffled that a post saying “pick a better one” for any engineering topic has been upvoted like this. Let me go to my team and let them know that we should migrate all our Ruby app to Scala so we can get ScalaTags. JSX was the first such exposure of a values-based HTML builder for mainstream use, you and your brother comment talk about Scala and Lisp as examples, two very niche languages.
When did I say that this was invented by React? I’m just saying that you can use JSX both on front and back which makes it useful for generating HTML. Your post, your sibling and the OP just sound slightly butthurt at Javascript for some reason, and it’s not my favourite language by any stretch of the imagination, but when someone says “JSX is a good way to generate HTML” and the response is “well, other languages have similar things as well”, I just find that as arguing in bad faith and not trying to bring anything constructive to the conversation, same as the rest of the thread.
But the point is that you wouldn’t have to - you could use a Ruby workalike, or implement one yourself. Something like Markaby is exactly that. Just take these good ideas from other languages and use it in yours.
Anyway, it sounds like we are in agreement that this would be better than just adopting JavaScript just because it is one of the few non-niche languages which happens to have such a language-oriented support for tags-as-objects like JSX.
I found that after all I prefer to write what is going to end up as HTML in something that looks as much as HTML as possible. I have tried the it’s-just-pure-data-and-functions approach (mostly with elm-ui, which replaces both HTML and CSS), but in the end I don’t like context switching it forces on my brain. HTML templates with as much strong checks as possible is my current preference. (Of course, it’s excellent if you can also hook into the HTML as a data structure to do manipulations at some stage.)
For doing JSX (along with other frameworks) on the backend, Astro is excellent.
That’s fair. There’s advantages and disadvantages when it comes to emulating the syntax of a target language in the host language. I also find JSX not too bad - however, one has to learn it first which definitely is a lot of overhead, we just tend to forget that once we have learned and used it for a long time.
In the Lisp world, it is super common to represent HTML/XML elements as lists. There’s nothing more natural than performing list operations in Lisp (after all, Lisp stands for LISt Processing). I don’t know how old this is, but it certainly predates React and JSX (Scheme’s SXML has been around since at least the early naughts).
Yeah, JSX is just a weird specialized language for quasiquotation of one specific kind of data that requires an additional compilation step. At least it’s not string templating, I guess…
I’m aware, I wrote such a lib for common lisp. I was talking that in most frameworks most people use they are still at the templating world.
It’s a shame other languages don’t really have this. I guess having SXSLT transformation is the closest most get.
Many languages have this, here’s a tiny sample: https://github.com/yawaramin/dream-html?tab=readme-ov-file#prior-artdesign-notes
Every mainstream as well as many niche languages have libraries that build HTML as pure values in your language itself, allowing the full power of the language to be used–defining functions, using control flow syntax, and so on. I predict this approach will become even more popular over time as server-driven apps have a resurgence.
JSX is one among many 😉
I am not a web developer at all, and do not keep up with web trends, so the first time I heard the term “server-side rendering” I was fascinated and mildly horrified. How were servers rendering a web page? Were they rendering to a PNG and sending that to the browser to display?
I must say I was rather disappointed to learn that server-side rendering just means that the server sends HTML, which is rather anticlimactic, though much more sane than sending a PNG. (I still don’t understand why HTML is considered “rendering” given that the browser very much still needs to render it to a visual form, but that’s neither here nor there.)
The Bible says “Render unto Caesar the things that are Caesar’s, and unto God the things that are God’s”. Adapting that to today’s question: “Render unto the Screen the things that are the Screen’s, and unto the Browser the things that are the Browser’s”. The screen works in images, the browser works in html. Therefore, you render unto the Browser the HTML. Thus saith the Blasphemy.
(so personally I also think it is an overused word and it sounds silly to me, but the dictionary definition of the word “render” is to extract, convert, deliver, submit, etc. So this use is perfectly inline with the definition and with centuries of usage irl so i can’t complain too much really.)
You can render a template (as in, plug in values for the placeholders in an HTML skeleton), and that’s the intended usage here I think.
I don’t think it would be a particularly useful distinction to make; as others said you generally “render” HTML when you turn a templated file into valid HTML, or when you generate HTML from another arbitrary format. You could also use “materialize” if you’re writing it to a file, or you could make the argument that it’s compilers all the way down, but IMO that would be splitting hairs.
I’m reminded of the “transpiler vs compiler” ‘debate’, which is also all a bit academic (or rather, the total opposite; vibe-y and whatever/who cares!).
It seems that was a phase? The term transpiler annoys me a bit, but I don’t remember seeing it for quite a while now.
Worked very well for Opera Mini for years. Made very low-end web clients far more usable. What amazed me was how well interactivity worked.
So now I want a server side rendering framework that produces a PNG that fits the width of my screen. This could be awesome!
There was a startup whose idea was to stream (as in video stream) web browsing similar to cloud gaming: https://www.theverge.com/2021/4/29/22408818/mighty-browser-chrome-cloud-streaming-web
It would probably be smaller than what is being shipped as a web page these days.
Exactly. The term is simply wrong…
ESL issue. “To render” is fairly broad term meaning something is to provide/concoct/actuate, has little to do with graphics in general.
Technically true, but in the context of websites, “render” is almost always used in a certain way. Using it in a different way renders the optimizations my brain is doing useless.
The way that seems ‘different’ to you is the way that is idiomatic in the context of websites 😉
Unless it was being rendered on the client, I don’t see what’s wrong with that. JSX and React were basically the templating language they were using. There’s no reason that setup cannot be fully server-generated and served as static HTML, and they could use any of the thousands of react components out there.
Yeah if you’re using it as a static site generator, it could be perfectly fine
I don’t have a link handy, but the site I was thinking about had a big janky template with pop-out hamburger menus, so it was definitely being rendered client side. It was slow and big.
I’m hoping tools like Astro (and other JS frameworks w/ SSR) can shed this baggage. Astro will render your React components to static HTML by default, with normal clientside loading being done on a per-component basis (at least within the initial Astro component you’re calling the React component from).
I’m not sure I would call a custom file type
.astrothat renders TS, JSX, and MD/X split by a frontmatter “shedding baggage”. In fact, I think we could argue that astro is a symptom of the exact same problem you are illustrating from that quote.That framework is going to die the same way that Next.JS will: death by a thousand features.
huh couldn’t disagree more. Astro is specifically fixing the issue quoted: now you can just make a React app and your baseline perf for your static bits is now the same as any other framework. The baggage I’m referring to would be the awful SSG frameworks I’ve used that are more difficult to hold correctly than Astro, and of course require plenty of other file types to do what
.astrodoes (.rb,.py,.yml, etc.). The State of JS survey seems to indicate that people are sharing my sentiments (Astro has a retention rate of 94%, the highest of the “metaframeworks”).I don’t know if I could nail what dictates the whims of devs, but I know it isn’t feature count. If Next dies, it will be because some framework with SSG, SSR, ISR, PPR, RSC, and a dozen more acronym’d features replaced it. (And because OpenNext still isn’t finished.)
Astro’s design is quite nice. It’s flexing into SSR web apps pretty nicely I’d say. The way they organize things isn’t always my favorite, but if it means I can avoid ever touching NextJS I’m happy.
Suggested to remove the satire flag!
Assembling and setting up a pre-production/pre-cert prototype for a new product. Otherwise twiddling my thumbs waiting for IANA reaction to our newly proposed CBOR tags.
On the other hand, the end state is often: Dear friend, you have built a LAMP server, using k8s (and Helm, and operators, and cert-manager, and Prometheus, and…).
I hope that this doesn’t come across as too snarky but I’ve just suffered the pain of getting a single-node Ansible AWX server running. Their only supported architecture is k8s and their operator. It took days! I remember back in the old days we used to say “simple should be easy and complicated should be possible.” Now it’s “everyone needs Google scale so that’s all we’re going to do.”
As an example of doing it the right way, the Immich photo management app is comparable to AWX in run-time complexity but it comes with a Compose file that makes it trivial to run and manage on any machine with docker already installed.
FWIW you don’t need Helm for Kubernetes, and you’re going to want something like cert-manager regardless (and if you don’t want cert-manager, just don’t do anything—I wish k8s would include it by default, but it doesn’t).
Similarly, there’s a lot of middle ground between single node and Google scale, and you should have at least one replica running in production in most cases, which i means you’re going to need some sort of load balancer and some deployment automation. At this point you may as well start considering Kubernetes.
Not only does Kubernetes provide load balancing and deployment automation, but it also allows you to easily run cloudnativepg, an operator that makes it easy to run a Postgres cluster with replication, backups, and failover. Maybe you don’t need that for your production application, but if you do, it’s a lot easier to run k8s and that operator than it is to use other tools to manage Postgres IMHO.
That’s an astonishing jump. For a handful of machines, a few scripts with ssh and some pretty standard networking tricks would be what I think of long before k8s.
I’m not sure exactly what you’re thinking with your “few scripts and networking tricks”, but it sounds like you’re trying to refute the need for a load balancer by arguing that you can implement your own load balancer.
Moreover, while any given feature Kubernetes provides out of the box could be implemented easily enough by a sufficiently competent, experienced engineer, the point of the article is that the total effort is much greater and you still end up with a platform for which no documentation, or training, or experienced hiring pool exists and your expensive competent, experienced professional has spent his time building Kubernetes instead of doing more valuable tasks (or more likely, your professional only thinks he’s sufficiently competent and experienced, and you wind up with a very broken Kubernetes that causes endless frustration).
If you have two machines you don’t need a load balancer. You just need a way to fail over to the second machine. That’s just network configuration, which you have to do anyway, Kubernetes or no Kubernetes.
That’s the problem with this argument. You still have to deploy machines, configure operating systems and networking, install services (whether your services or Kubernetes’s services), etc. unless you’re using a 3rd party managed Kubernetes, which renders the comparison irrelevant anyway. So you can expose Kubernetes as a uniform target to a bunch of teams, but you still have a lot of stuff that is local deployment. If you don’t have a platform team providing a uniform target to lots of other teams, and you’re already doing all this configuration anyway, why do the configuration of Kubernetes as well?
Kubernetes generally takes care of the failover for you. You don’t really need to think about it.
There’s much less operating system configuration if you’re using Kubernetes than if you’re rolling your own hosts, and the networking setup is “install MetalLB”. It’s extremely minimal. Similarly, certificate management is “install cert-manager”. DNS is “install external-dns”. Similarly there are standard, high-quality packages for logging, monitoring, alerting, volume management, etc. While I’m surprised there are Kubernetes distros that include this stuff out of the box, it’s still less work than doing it yourself and you get the benefits of standardization: abundant, high quality documentation, training resources, and an experienced hiring pool. And moreover, as your requirements scale, you can incrementally opt into additional automation (Kubernetes is a platform for infrastructure automation).
I’m not sure what you mean here. Why would managed Kubernetes render the comparison obsolete?
I’m not following you here. What do you mean by “uniform target” vs “local deployment”.
No, it’s not. You still have to set up the underlying network that the physical machines are on. That’s the key point. You can install all this stuff within Kubernetes…but it’s all dependent on nodes that are fully configured outside of Kubernetes.
I see what you mean. Yes, you need to have nodes that are on a network, but “fully configured” for running Kubernetes basically means “SSH is configured”, which is dramatically easier than any configuration I’ve seen for running production-grade applications directly on nodes (no need to haul out ansible or anything like it).
By design, sure. In practice though the biggest failures I’ve had with kubernetes have been nginx ingress pods just randomly losing their ability to connect to upstream and silently causing downtime that wouldn’t haven’t happened if the app was exposed directly, using an AWS ALB, etc. I’m not saying this is everyone’s experience. It might be due to noob misconfiguration mistakes. But that’s sorta the point the article misses. Kubernetes might offer repeatable solutions for these problems (and I appreciate it for that) but it really isn’t a solution on its own. Every team running a kubernetes cluster has their own collection of weird scripts with bespoke workarounds for kubermetes quirks.
/sympathize with random nginx Ingress failures leading to widespread 503 outages.
not sure if this is welcome here, but try https://semaphoreui.com/ instead
Thank you! In this case I was told to stand up an AWX instance, and I didn’t know what I didn’t know, but I’ll take a look at your suggestion. If there’s a “next time” then I’ll be able to advocate for an alternative.
OMG this. At work I tried to fix a broken internal app that I had no role in getting set up. Everyone who had worked on it had departed. So started the slog of figuring out how it worked, where it was deployed, and getting access. Oh cool, this runs on the “internal dev platform”. What is that? Oh it’s a kunernetes cluster. Neat that they tried to think ahead spread some infra costa across projects. I wonder what else is running on this thing… nothing. It is a 2 node kubernetes deployment that runs one application pod. Not per node. Total.
I was working in an Oracle shop where devs would spin up an Oracle instance for a web application that had 4 data items. Not databases. Not tables. Items.
My production app ran completely without databases and was several orders of magnitude faster, smaller, and more reliable than its predecessor.
But think. How the devs could otherwise move on in their careers without “designed, built, deployed and maintained a scalable K8 solution” on their CVs?
Ding ding ding! You got it. On a lark I searched Google for large sections of the docs they “wrote” for it and sure enough it was all basically copy/pasted from guides on how to set up RBAC.
I like the idea of example-driven code generation, but there’s a limit to how much you can express using examples only. I think it’s necessary to allow including a description too. Also, coming from a “data-science” POV, I would provide the LLM only with 80% of the examples, and then test it on the remaining 20% to make sure it isn’t overfitting.
This too can be trivially handled by the compiler. E.g. require at least 6 examples, use 4 of those for gen and 2 for test. Issue a warning if the user had supplied fewer than that.
Agreed. Think about how board games rules are defined. They would never send you a booklet with 500 individual examples, they describe the rules generically.
In computer science, that’s called a specification. Many examples do not a specification make.
I wonder how much this is a case of chasing the metric rather than organic adoption.
Some large consultancies here really push the adoption of assistants onto programmers so that they can boast the customers they’re on the bleeding edge of development. The devs grumble, attend mandatory AI training and for the most part pretend they lean on their now indispensable Copilots. It is possible something like that is happening here. The VP of AI Adoption and their department that Google for sure has counts all the lines from AI enabled editors. This then communicated with a good part of wishful thinking all the way up to the CEO.
Or who knows, maybe Google has a secret model which is not an utter crap for anything non-trivial and just holding it back for competitive advantage. Hope googlers here would let us know!
If you read their report on it, it is definitely chasing for metrics. All their other “AI tool for devs” initiatives have abysmal numbers in term of adoption and results, and they are already saying that all their future growth are in other domains of development. Translation: We are out of things we can easily growth hack.
FWIW, if this is anything like Copilot (which I do use for personal projects because I’ll take anything that’ll fry my brain a little less after 8 PM) it’s not even a particularly difficult metric to chase. I guess about 25% of my code is written by AI, too, as in the default completion that Copilot offers is good enough to cover things like convenience methods in an API, most function prototypes of common classes (e.g. things like constructors/destructors), basic initialization code for common data structures, hardware-specific flags and bitmasks and so on.
It’s certainly useful in that it lets me spend more of my very limited supply of unfried neurons on the harder parts, but also hardly a game changer. That 25% of the code accounts for maybe 1% of my actual mental effort.
I will give it that, though, it’s the one thing that generative AI tools have nailed. I’m firmly in the AI should do the dishes and vacuum so I can write music and poetry, not write music and poetry so I can do the dishes and vacuum camp. This is basically the one application where LLM tools really are doing the dishes so I can do the poetry.
This feels like that time Paul Graham said over 25% of ViaWeb code was macros and it was intended to be a boast but everyone who saw it was just horrified.
Found a source.
It was apparently Lisp macros, which is at least a little less cursed than pre-processor ones (AFAIU Lisp).
Eh, you can still do very cursed things with reader macros, which allow you to write non-sexp language features.
Why horrified?
I’ll let you read that again:
I don’t see the problem. He made a dsl in lisp, so the actual code was smaller/denser describing the problem space well. In this particular case, the users would basically be creating configs, similar to knowledge bases or constraint lists describing what they wanted. The macro heavy code would then transform that into an end result. Isn’t that good?
Graham has been riding on his “we built an ecommerce site in Lisp and it was so awesome” for nearly 30
decadesyears now. Sadly the followup was Hackernews.I’m not sure if you’ve ever had the chance to use Yahoo! Store (what Viaweb became)—it was terrible—but it was also extremely innovative for the time. It used an actual programming language RTML you edited with the browser. It was sandboxed, and built on continuations (for which Graham received a patent).
So, yeah. Maybe he’s been bragging about this for 30 years, but this success ultimately paved the way for YC which changed the world (I won’t make a value judgement on which way).
I’d posit that Graham, like a lot of other people, was lucky to be in the right place at the right time. Sure he and his team worked hard - creating a company isn’t easy - but lots of people made a lot of money in the first internet bubble, and the smarter ones kept the money and reinvested it. Running a VC firm was essentially a license to print money for a while. And YC itself “just” pics companies to invest in, they don’t run the companies themselves.
In other words, while PG attributes a lot of his success to the use of Lisp for Viaweb, it was probably not a game changer. The real product was making a web storefront, making it a success , and selling it to
idiotsinvestors with more money.I think Graham himself attributes using Lisp as helping to get to the finish line first over the competitors. And it’s a fair point as it appears to have worked for him. But there is little doubt that user editable online stores would have appeared otherwise and I don’t think he was ever alluding to that.
While every exit has some luck involved and some “right place right time,” there likely weren’t other storefront builders in the same way Viaweb existed. That’s something.
Additionally, the choice of Lisp was definitely part familiarity, but also, he’s told stories as to why it was advantageous. He wasn’t skilled in running software, so their deployment, or bug fixes, or reporting were “run this thing in the repl.” You can’t do that outside of Lisp—maybe Erlang.
As for YC, it’s never been a traditional VC, and it’s only scaled up as a result of iteration on the model. The first group was like 6 companies. They all lived in Boaton. They all had dinner every Sunday (or whatever), they all got introduced to other investors, etc. YC built a community of like minded startup founders, and they lnow each other, and when possible, help each other. Does that happen in traditional VC? Probably to some degree. YC took it further, and it should be considered an innovation.
Note: I am not a Paul Graham Stan. I do think the man wasn’t “just lucky,” and actually created things that people wanted.
Either 3 decades or 30 years, not 30 decades. 30 decades ago was 1724 ;)
You’re correct, it only feels like he’s been banging the drum for 300 years…
I can happily claim that I have never read any of is essays or whatever. I think I made the right choice.
In terms of how the software works, hacker news is one of the best sites I’ve used … like ever
I mean lobst.ers was directly inspired by it, and judging by my logs hacker news drives 5x to 10x the traffic
So oddly enough the Lisp way of writing web apps actually did and does work. I think they had to do a bunch of work on the runtime too, but so did stack overflow, instagram, etc
Well, I think the point here is largely tongue in cheek, but there’s truth in it too, so I’ll focus on the truth; Yes, building layers is good, declarative code is good, interpreting specifications is good. But none of these things necessitate excessive amounts of metaprogramming.
My personal experience is that I dig myself into metaprogramming holes when I spend too little time thinking about simpler ways to achieve my goals, so I’ve developed a reflex of stopping myself and reflecting a little whenever the urge to metaprogram comes. So, naturally, when somebody says their codebase is 25% metaprogramming, the same reflex kicks in.
A good deal of standard Common Lisp language constructs are actually macros and nobody flinches using them. The language integration for that is really good. So I agree with u/veqq, it’s a nothingburger in general, although naturally a question of taste here applies just as much as to programming in general.
Metaprogramming is as normal as defining functions in lisp. In Common Lisp core things like when, and, loop, dotimes, let, defun, defvar, defmacro or cond are macros. Code is data is code. Perhaps you are thinking of metapogramming in other languages where it has its own strange system and syntax and complects the system.
Honestly, thinking about it, 25% must mean new macro definitions as typical code probably involves more macros (just from using control flow etc.).