Maybe this will bring the idea of “TypeScript tooling should run the typechecker before doing anything else” (like linting, running tests, etc.). It feels very backwards that you can make a bundle with vite or whatever without the code being in a compilable state.
I mean, most bundlers or compilers don’t automatically run a linter or force all the tests to pass before compiling the code. It’s surprisingly convenient being able to separate type checking from whether the code runs or not. It makes it very easy to make a change locally and test it out, without having to update the entire codebase based on the change you’ve made. In most cases, you need to do compilation to get your code to run in the first place, but Typescript is lucky that type checking can be decoupled in this way.
Obviously everything needs to type check before ending up in production, but this is the same as tests, linting, and so on.
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
I disagree with this, only because it’s imperialism. I’m British, in British English I write marshalling (with two of the letter l), sanitising (-sing instead of -zing except for words ending in a z), and -ise instead of -ize, among other things. You wouldn’t demand an Arabic developer to write all his comments in English for your sake for the sake of being idiomatic, would you?
I’ve worked for a few companies in Germany now, about half of them with their operating language being in German. All of them had comments being written exclusively in English. I don’t know how that is in other countries, but I get the impression from Europeans that this is pretty standard.
That said, my own preference is for American English for code (i.e. variable names, class names, etc), but British English for comments, commit messages, pull requests, etc. That’s because the names are part of the shared codebase and therefore standardised, but the comments and commit messages are specifically from me. As long as everyone can understand my British English, then I don’t think there’s much of a problem.
EDIT: That said, most of these suggestions feel more on the pedantic end of the spectrum as far as advice goes, and I would take some of this with a pinch of salt. In particular, when style suggestions like “I tend to write xyz” become “do this”, then I start to raise eyebrows at the usefulness of a particular style guide.
All of them had comments being written exclusively in English. I don’t know how that is in other countries, but I get the impression from Europeans that this is pretty standard.
Developers in China seem to prefer Chinese to English. When ECharts was first open-sourced by Baidu most of the inline comments (and the entire README) were in Chinese:
In Japan I feel like the tech industry is associated with English, and corporate codebases seem to use mostly English in documentation. However, many people’s personal projects have all the comments/docs in Japanese.
If someone wants to force everyone to spell something the same within a language they should make sure it’s spelled wrong in all varieties, like with HTTP’s ‘referer’.
The Go core developers feel so strongly about their speling that they’re wiling to change the names of constants from other APIs.
The gRPC protocol contains a status code enum (https://grpc.io/docs/guides/status-codes/), one of which is CANCELLED. Every gRPC library uses that spelling except for go-grpc, which spells it Canceled.
Idiosyncratic positions and an absolute refusal to concede to common practice is part and parcel of working with certain kinds of people.
We’re drifting off-topic, but I have to ask: gRPC is a Google product; Go is a Google product; and Google is a US company. How did gRPC end up with CANCELLED in the first place?!
You wouldn’t demand an Arabic developer to write all his comments in English for your sake for the sake of being idiomatic, would you?
If this is something other than a private pet project of a person who has no ambition of ever working with people outside of his country? Yes, yes I would.
I believe the advice is still applicable to non-native speakers. In all companies I worked for in France, developers write code in English, including comments, sometimes even internal docs. There are a lot of inconsistencies (typically mixing US English and GB English, sometimes in the same sentence.)
In my experience (LatAm) the problem with that is people tend to have pretty poor English writing skills. You end up with badly written comments and commit messages, full of grammatical errors. People were aware of this so they avoided writing long texts in order to limit their mistakes, so we had one-line PR descriptions, very sparse commenting, no docs to speak of, etc.
Once I had the policy changed for the native language (Portuguese) in PRs and docs they were more comfortable with it and documentation quality improved.
In Europe people are much more likely to have a strong English proficiency even as a second or third language. You have to know your audience, basically.
While I like to write paragraphs of explanation in-between code, my actual comments are rather ungrammatical, with a bit of git style verb-first, removing all articles and other things. Proper English feels wrong in these contexts. Some examples from my currently opened file:
; Hide map’s slider when page opens first time
;; Giv textbox data now
;;Norm longitude within -180-180
; No add marker when click controls
;; Try redundant desperate ideas to not bleed new markers through button
;; Scroll across date line #ToDo Make no tear in marker view (scroll West from Hawaii)
Those comments would most likely look weird to a person unfamiliar with your particular dialect.
In a small comment it’s fine to cut some corners, similar to titles in newspapers, but we can’t go overboard: the point of these things is to communicate, we don’t want to make it even more difficult for whoever is reading them. Proper grammar helps.
For clarification, this is not my dialect/way of speaking. But I see so many short interline comments like this, that I started thinking they feel more appropriate and make them too, now. Strange!
Is “hat” a standard term regularly used in the golang ecosystem for a specific thing and on the list given in the article? If not, it is not relevant to the point in the article.
(And even generalized: if it happens to be an important term for your code base or ecosystem, it probably makes sense to standardize on how to spell it. in whatever language and spelling you prefer. I’ve worked on mixed-language codebases, and it’d been helpful if people consistently used the German domain-specific terms instead of mixing them with various translation attempts. Especially if some participants don’t speak the language (well) and have to treat terms as partially opaque)
I had to solve this once. I maintain a library that converts between HTML/CSS color formats, and one of the formats is a name (and optional spec to say which set of names to draw from). HTML4, CSS2, and CSS2 only had “gray”, but CSS3 added “grey” as another spelling for the same color value, and also added a bunch of other new color names which each have a “gray” and a “grey” variant.
Which raises the question: if I give the library a hex code for one of these and ask it to convert to name, which name should it convert to?
The solution I went with was to always return the “gray” variant since that was the “original” spelling in earlier HTML and CSS specs:
I don’t think it’s really “imperialism”—firstly, “marshaling” isn’t even the preferred spelling in the US. Secondly in countries all over the world job listings stipulate English language skills all the time (even Arabic candidates) and the practice is widely accepted because facilitating communication is generally considered to be important. Lastly, while empires certainly have pushed language standardization as a means to stamp out identities, I don’t think it follows that all language standards exist to stamp out identities (particularly when they are optional, as in the case of this post).
“marshaling” isn’t even the preferred spelling in the US
What makes you say that? (Cards on the table, my immediate thought was “Yes, it is.” I had no data for that, but the ngram below suggests that the single l spelling is the (currently) preferred US spelling.)
I like this idea! Do you think it’s extreme to try and implement dark/light mode using static HTML? I can’t seem to find a good workaround for a javascript-less solution to give people the option to choose to deviate from their system preference.
But it sure feels like overkill to generate a copy of each page just to avoid making someone enable JS to change the colors on their screen… which I don’t even do because I prefer everything in dark mode anyway.
I don’t understand why so many web sites implement a dark mode toggle anyway. If your page uses CSS conditionally on prefers-color-scheme to apply a light theme or dark theme depending on the user’s system preference, why isn’t that enough?
For example, if the user is looking at your page in light theme and suddenly they think their bright screen is hurting their eyes, wouldn’t they change their systempreference or their browser’spreference to dark? (If they don’t solve the problem by just lowering their screen brightness.) After they do so, not only your page but all their other apps would look dark, fixing their problem more thoroughly.
For apps (native or web) the user hangs around in for a long time, I can see some reasons to allow customizing the app’s theme to differ from the system’s. A user of an image editing app might want a light or dark mode depending on the brightness of the images they edit, or a user might want to theme an app’s windows so it’s easily recognizable in their window switcher. But for the average blog website, these reasons don’t apply.
I am curious about how many people use it as well. But it certainly is easier to change by clicking a button in your window than going into your system or browser settings, which makes me think that it would be nice to add. Again, for the imagined person who decides to deviate from their system preference.
Although you’ve made me realize that even thinking about this without putting work into other, known-to-be-used accessibility features is kind of ridiculous. There is lower hanging fruit.
Here’s a concrete example. I generally keep my browser set to dark mode. However, when using dark mode, the online training portal at work switches from black text on a white background to white text on a white background. If I wanted to read the training material, I would need to go into my browser settings and switch to light mode, which then ruins any other tab I would switch to.
If there was a toggle button at the training portal, I could switch off dark mode for that specific site, making the text readable but not breaking my other tabs. Or, if the training portal at work won’t add the button, I could at least re-enable dark mode in every tab whose site had added such a toggle.
Sure, but only on sites that provide a button. It seems a little silly that one bad site should mean that you change your settings on every other site / don’t have your preferred theme on those sites.
Given how widely different colour schemes can vary, even just within the broad realms of “light” and “dark”, I can imagine some users would prefer to see some sites in light mode, even if they want to see everything else in dark mode. It’s the same reason I’ve set my browser to increase the font size for certain websites, despite mostly liking the defaults.
It would be nicer if this could be done at the browser level, rather than individually for each site (i.e. if there was a toggle somewhere in the browser UI to switch toggle between light/dark mode, and if the browser could remember this preference). As it is, a lot of sites that do have this toggle need to either handle the preference server-side (not possible with static sites, unnecessary cookies), handle the preference client-side (FOUC, also unnecessary cookies), or don’t save the preference at all and have the user manually toggle with every visit. None of these options are really ideal.
That said, I still have a theme switcher on my own site, mostly because I wanted to show off that I made two different colour schemes for my website, and that I’m proud of both of them… ;)
I remember the days when you could do <link rel="alternate stylesheet" title="thing" href="..."> and the browser would provide its own nice little ui for switching. Actually, Firefox still does if you look down its menu (view -> page style), but it doesn’t remember your preference across loads or refreshes, so meh, not a good user experience. But hey, page transitions are an IE6 feature coming back again, so maybe alternate stylesheets will too someday.
The prefers dark mode css thing really also ought to be a trivial button on the browser UI too. I’m pretty sure it is somewhere in the F12 things but I can’t even find it so woe on the users lol.
But on the topic in general too, like I think static html is overrated. Remember you can always generate html on demand with a trivial program on the server with these changes and still use all the same browser features…
I’ve been preparing something like this. You can do it with css pseudo selectors and a checkbox: :root:has(#checkbox-id:checked) or so; then you use this to either ‘respect’ the system theme, or invert it.
The problems I’m having with this approach:
navigating away resets the checkbox state
svg and picture elements have support for dark/light system theme, but not for this solution
Yeah, I think I saw the checkbox trick before, but the problems you outline make the site/page/dark and site/page/light solution seem more enticing, since they can avoid especially the state reset issue. I like the idea of respecting/inverting the system theme as a way of preserving a good default, though!
Yeah, as an alternative, for the state issue I was thinking of using a cookie + choose the styles based on it, but that brings a whole host of other “issues”
This is highly dependent on culture of the team and style of development.
If you have an issue tracking system where you manage all bugs and change requests, then most information is here and discussions also happens here and then in commit message you can just link the number of the ticket (and maybe add some low-level comment for other developers, but it is optional, because everything important is already in the issue tracking system).
If the development is more spontaneous and informal and issue tracking system is missing or a lot of development work is done without assignments and formal change requests and bug reports, then commit messages are more important and deserve better description of what has been done and why.
If you have an issue tracking system where you manage all bugs and change requests, then most information is here and discussions also happens here and then in commit message you can just link the number of the ticket (and maybe add some low-level comment for other developers, but it is optional, because everything important is already in the issue tracking system).
And now you have an N+1 Select problem in your VCS. Now any time someone wants to understand the history of why a particular part of the code base changed in a certain way they have to do a mental manual join of each commit to each issue in the tracker. You’ve optimized for the current developers over the future ones.
I think the article should probably go deeper on why this is a problem, because it is one I’ve seen numerous times in legacy software maintenance.
An analogy for this is that an issue tracker is a plan for battle drawn up before any fighting starts, but a commit history is the journal of the what actually happened written by those who did the fighting. A history written for the survivors with just the first part is no real history at all.
I agree that the history is important and this is how I use the VCS – if I find some weird code and wonder why it was written this way and whether it was an intention or a weaker moment of the developer, I check the history and related tickets in the tracking system with comments from consultants or even customers and find the reasons behind it.
Whether these information should be duplicated in VCS is bit questionable – maybe as a backup case of issue tracking system loss… it probably will not harm anybody and will not take too much time to write such commit message. Important is that the details and motivation is documented somewhere.
I worked in a place where the issue tracker was full of really useful context, and I had the same process as you — always check the related tickets, because that would almost explain so much more of the context and reasoning for the change than any commit message could. The issue tracker had discussions with stakeholders, developers describing the issues they’d run into, all sorts of planning documents and diagrams, etc. So it had the plan of how changes would be made, the history of how they were made, and sometimes even retrospective/evaluation comments about what needed to be changed later.
Unfortunately, every other issue tracker I’ve used was anaemic in comparison, and so I’ve come to appreciate the power of a good commit message a lot more since working elsewhere.
I would write it in the commit message anyway. Yes, we have an issue tracking system, and branches are named after the ticket number, so you can definitely get some context just by looking at the merge commit, but bytes are cheap and having the information in-context is valuable. Also the commit messages can hold more developer-oriented technical information, while the issue tracker is more for the benefit of people who don’t actually care about most of that.
this is silly…CI isn’t having it run on the cloud via some rented server.
CI is making sure that env issues / local dev issues / whatever don’t break the build. Its the idea of dual-entry accounting, ie having a second path to check your work.
“signing off” work locally defeats that entire purpose
I don’t think it does here though, does it? The signing is just a unilateral declaration that everything has passed — it doesn’t require that the tests have been run at all, nor that they were run in an environment anything like that of CI, or indeed production.
This seems an important distinction to me because I know that I am very fallible, and often forget things, ranging from big things like just forgetting to run certain tests, through to much more subtle things like having an environment that diverges from CI/production in such a way that tests will succeed on my machine but not in production.
It’s not about trust so much as consistency. I trust myself and my coworkers to write good code and to do things correctly. I don’t necessarily think we’re so consistent, though. But what’s incredibly good at being consistent? A script that runs in exactly the same environment every time, runs exactly the same operations every time, and never changes… which sounds a lot like CI.
That said, I do like the idea of utilising dev machines for CI workers more. I just think there’s probably a better implementation of that than this.
The signing is just a unilateral declaration that everything has passed — it doesn’t require that the tests have been run at all
I imagine the intention is to enforce this by convention.
But what’s incredibly good at being consistent? A script that runs in exactly the same environment every time, runs exactly the same operations every time, and never changes.
And at the end of said script you’d include a step execute the signing.
I think the most convincing defence of text labels is a discussion trying to find the best icon to use for a feature. It’s a conversation I’ve had multiple times, and we usually end up picking something that vaguely feels related, having combed through the Font Awesome icon list and thrown at least half a dozen suggestions into the mix.
If it’s this hard to pick an icon knowing what the icon is meant to represent, then how hard must it be for the user trying to reverse engineer our logic?
I agree with the author that the right icon at the right time is brilliant, and can make something immediately understandable at a glance — far more than a textual representation can do. But defaulting to text-with-icon (or even just text!) is probably the best place to start.
There was a time when software companies and web studios had their own graphic designers and they created custom icons to suit their needs. Instead of „picking something that vaguely feels related“.
However I agree that icon itself is sometimes not much useful and icon+text combination or even just text is sometimes better option.
P.S. There used to be books on how to design icons. The Icon Book by William K. Horton is great. It is a 1994 book. Is there something more contemporary worth reading? I found some books about design in general or some web resources, but no other comprehensive writing on icons.
I was the tech lead of the internationalization effort for a popular website a number of years back. This was in the US. The site was English-only and we wanted to make it available in a wide variety of languages. We wanted to make it feel as native to each language as we could, rather than feeling like a translation of a foreign site.
My team and I came up with a bunch of internal tools and a flexible library we could use to make our code work in multiple languages. When I say “flexible” I mean it went way beyond simple token replacement; it could do things like look up different variants of sentences depending on whether a caller-supplied place name referred to a city or a country and whether that distinction mattered in the target language, could use different pluralization rules for different languages, took gender into account if a sentence mentioned a person whose gender was known, and so on. We had people with linguistics backgrounds making sure we didn’t fall into any obvious traps.
The code base was far too big for my little team to update on our own, so an early goal was to give the rest of the engineering team all the resources they needed to do a really good job of updating their own corners of the code. In addition to thoroughly documenting our tools and libraries, we wrote up a set of annotated examples of how to change existing English-only code to be translation-friendly, and we made sure it covered all the common patterns in the code base (including visual design things like assuming a button only needed to be exactly big enough to hold an English label) and included examples of what could go wrong in different languages if people decided to just do string concatenation instead.
Then we started rolling it out. My expectation going into it was like yours: that the monoglot American devs would struggle to embrace all the techniques because English-specific assumptions would be too deeply ingrained.
But once I started doing code reviews of people’s changes, the reality was different. It turned out there was no measurable relationship between how good someone was at making their part of the site translatable into a wide variety of languages and which language(s) they spoke. Americans who’d never spoken anything but English were just as good at it, on average, as trilingual Europeans or people whose native languages were very different from English.
The thing that floored me was seeing people from other countries repeatedly make mistakes that would have made it impossible to correctly translate part of the site into their own native languages. This happened a lot, and it happened across multiple native languages. It seemed to me like some people were able to put their brains in “human language is highly variable and the code needs to act accordingly” mode, and some people were stuck in “I am working in English right now, so everything is English” mode, and it barely mattered if they happened to speak some other language or not.
Maybe the situation would have been different if the site had been in more than one language from the get-go; I don’t know. But that experience really shattered some of my preconceptions about the advantages of speaking multiple languages. (For the record: I still think it’s worthwhile to be multilingual!)
The first job I had in Germany, having moved here as a fresh-faced monolingual foreigner, was kind of like this. We were building an internal tool that was used by warehouse workers in various European countries. We knew we had a lot of fairly monolingual users in a variety of different languages, so when we decided to redesign the tool, I pushed really hard for making sure that every part of the UI was fully translated into all the relevant languages. I was amazed by how much my German colleagues pushed back against this, saying it would be a lot of effort, and people could just learn what the different English-language messages meant over time.
There were things a decade ago that my non-American English native speaker coworkers (Romanian, Croatian, Indian [Hindi & Marathi]) learned alongside me who’d been doing localization for a while — back then, I spoke natively American English but had six school years of Latin, 10+ years of self-driven Esperanto, and smattering of (Mexican) Spanish and (Canadian) French — when we did a big project targeting 10 languages on release days and 22 within four weeks in a patch release. I’ve picked up Dutch and some Korean since then and I’m constantly learning new things about language having gotten into linguist sector of Instagram, Threads, Bluesky, and the fediverse.
Unless you’re a linguist, you’re always learning surprising new things about language, discovering new tools in the toolbox, per se. If you’re a linguist, you’re learning which has/does what because you’re more familiar with what’s in the toolbox.
Cool you’ve learned so many languages. I’m currently trying to learn a new language and struggling a bit so maybe you can help. What are your preferred ways to learn a new language and make it stick?
Consistent practice. Try to experience all modes - reading, writing, listening, speaking, and conversing.
Find media you like. You don’t have to be even at 50% comprehension to listen to some audio, but obviously you’re only going to get little bits.
Adverts are much simpler than anything except children’s media.
Experiencing the language is generally the best way to internalize the rules, but reading up on complex rules to help you practice them is also important.
Regular practice. Duolingo is fine if all you can put into it is 10-15 minutes per day. That’s better than 0 and 5 minutes isn’t doing much. Most of my focus is on reading and writing until I started learning Dutch in 2023. You have to read a ton and listen a lot. I don’t listen as much as I should, but there are plenty of Dutch teachers and comedians on social media that I’ve come to enjoy.
I think it’s important to remember your purpose. I like learning languages because I like linguistics and language, not because I have an acute need to interact in another language. Honestly, some trips to Belgium and The Netherlands in the last few years have been the most immersive foreign language environment I’ve been in… and any Belgian or Dutch can tell you that you can get along just fine in most both of those countries speaking just English. I was able to use nothing but Dutch to get lunch in my great grandmother’s small hometown, though!
Absolutely not, I’ve seen a couple of these with German software, with English/French just an afterthought. And that’s already two languages where half of the stuff doesn’t even apply because they are both LTR languages in latin script. I will admit that it’s of course more likely to be a US/UK dev team.
We would still be limited by the patch order mattering in a snapshot-based VCS which hurts the ability to reasonably work conflict-free in a decentralized manner.
Let’s say you’ve got a function f() in a file that is called in multiple places. Patch A adds a new place where f() is called. Patch B renames f() to g() and updates all call sites.
We cannot commute these patches, can we? If patch B comes first, then when patch A lands, it will be using the old name in a codebase that has been updated to use the new name. The resulting code is therefore only valid if A comes before B.
Not all patches commute, such as when they depend on one another, but many patches do commute—tautologically, in the way that 1 + 2 = 2 + 1 so order doesn’t matter in these cases. You deal with these conflict issues if/when they come up rather than every pull if your patch order is out of sync (rerere is not foolproof, merge commits are incredible noisy & even they cause merge conflict issues sometimes). This does mean Alice can pull in patches from Bob then Carol, while Carol can pull from Alice then Bob & if it commutes, no conflict.
Is there a way to make the native dialog boxes (typically an OK / Cancel sort of thing) keyboardable? That’s always what drove me nuts about MacOS. Just give me tab select and enter to trigger! I don’t understand why they’ve never adopted that.
There is an accessibility toggle somewhere that makes them (mostly) keyboard accessible. I can’t remember where it is exactly, but knowing that it exists is half the battle! ;)
I was excited to try this out, but discovered that it prevents the space bar from working in kitty. I’m sure there is a way to fix that, but I wanted to leave a note here in case anyone else might try this out and then a hour later wonder why their space bar isn’t working in their terminal.
You can click the little ( i ) icon in the top right and change some of the bindings. I switched “activate” from space bar to what Apple’s always called “Return” (although I thought The Mac is not a Typewriter).
But I ended up turning it all off anyway, because the UX was so terrible and got in the way of everything. I only wanted keys for standard buttons on standard dialog boxes! I wish you better luck than I.
Oh. So the scope of change_id is just “active changes”, not “all changes”. I kind of assumed that a combination of base32 having larger … base, and maybe matching on the first (depth wise) was used, which is kind of similar, but I now understand that JJ is calculating actually unique prefix, just in a subset of changes. In my idea, I guess saying which of changes is actually “earlier” and which “later” might be a problem.
^ This is also a key point. Change IDs are rendered in “reverse hex” notation, which is normal hex notation using the alphabet z..k instead of 0..9a..f. This makes it easier to differentiate the two types of ID.
All changes get a change ID, and JJ does calculate the unique prefixes for all those IDs when they get rendered (using the main indexes as described in the “Indexes in Jujutsu” section). It can do this efficiently because it stores all the IDs as a sorted list and can therefore see which IDs neighbour any given ID.
But it then also has a separate index for the active changes, that’s much smaller. So any change gets looked up first in the “active changes” index, then in the main indexes if it’s not found.
It may hit a bit close to home, but the folks too lazy/sloppy/unskilled to properly handle good commit messages probably are the ones most easily replaced by LLMs.
Well, let’s consider the cases. If the commit message that one would have put was “try” “lol” “ugh try again”, then what did we gain by having a more verbose commit message written by the LLM? Conversely, if the commit message is actually very important, should we really use an LLM to write it for us?
Arguably those provide more context about the “why” than an LLM-provided summary of the change: they convey that the committer is in a hurry, and that this is likely an (attempted) fix to a recent commit by the same author, probably as part of the same merge.
I’m ambivalent tbh. I know amazing devs who write those silly little intermediary commits. I try to organize my commits because I assume someone, one day, might want to review a commit log to figure stuff out, but I don’t have strong feels because I rarely do that myself.
Most of the people I know who write those sorts of commits tend to be basically using them as fixup commits, except that they tend not to be aware of --fixup and probably find their flow more convenient anyway. When their change eventually appears in the main branch, it’s almost always squashed down to a single commit with a single well-written description (usually done via PRs in some git forge or other).
Or in other words, I suspect the people writing those intermediary commits usually see them as temporary, and I don’t think they’d get much out of an LLM describing their changes.
Perhaps, yeah. I tend to clean up my commit history to remove those intermediary ones as well fwiw, but I know a lot of people who don’t. I suppose the answer isn’t “use an LLM” (I know I won’t) but to just learn how to rewrite your history properly.
Or even use tools that make managing your history easier. I do think Git makes it excessively hard to rewrite commits and maintain a history of the rewrites that you’re doing, which leads to people taking the “squash everything in a PR” approach, which is typically a lot easier. But better tooling in this regard can improve things a lot.
That said, this is perhaps getting a bit off-topic from the core idea of LLM-based commit messages.
Sometimes there’s no bigger meaning behind some changes. It’s either obvious why it’s done or it becomes obvious in context of other changes. Writing commit messages for that is just going through the motions which means sometimes it becomes “refactor” or a similar message. In those cases it could be nice to have an automatic summary instead of nothing.
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.
The Newton folks claimed that GUIs needed two kinds of OOP. They argued that the class-based OO was good for models, where you would have a lot of the same kind of thing. For example, paragraphs of text in a word processor, people in an address book, and so on. In the traditional MVC model, they argued that the controllers exist because you really want a slightly different version of a view. For example, a one-off GUI widget for entering a phone number, which has to validate that the input is a particular format and then update a model, is annoying to implement as a custom subclass of a text view. They proposed using prototype-based OO for these, because prototype-based OO naturally encourages creating objects that behave almost like others.
I’ve yet to find any evidence that they were wrong. Even if you move to a model-view-update style GUI, I think their points still stand.
Some (possibly circumstantial) evidence against this theory: in Javascript, which is heavily used for building GUIs, and which has prototypal inheritance, most tooling is moving strongly away from OO-style code and towards more closure-oriented patterns. React hooks are the quintessential example here, but the same patterns now show up in Vue, SolidJS, Svelte, Preact etc. The only mainstream framework sticking to the more traditional OO-esque syntax is Angular.
Like I said, this isn’t definitive proof that OO doesn’t work for UI (and the fact that the DOM API is still defined in a largely OO manner with plenty of inheritance is a good counterexample). But I also find it significantly easier to compose behaviours and maintain codebases using the closure-style syntax (regardless of framework), and I think there’s a good reason why so much of the frontend world switched over to this style in a relatively short amount of time.
Cocoa + ObjC is an interesting example, because ObjC pretends to be a class-based OOP language, but the ObjC runtime is much more flexible, and almost a prototype-based OO, with full reflection support.
Cocoa makes great use of that for attaching bindings to objects by replacing implementations of their setters and getters dynamically (per instance, not per class!), as well as translating events to calling methods by name on whatever object in the hierarchy happens to implement one.
This made it possible to have Interface Builder be a GUI for making GUIs, with drag’n’drop declarative connections between models and their views, while using the language runtime for it, and being compatible with programmatically-created objects too, without too much GUI-specific layer in between. That was a pretty neat way to build GUIs back when computers were single-threaded.
but the ObjC runtime is much more flexible, and almost a prototype-based OO,
I’m not sure what you mean by this, but you can’t add methods or ivars to an individual object. Since OS X 10.7, the Apple runtime has a notion of ‘associated objects’, which are kind-of like adding ivars, though with a very different implementation.
In the GNUstep runtime, we have a slightly more prototype-like model. We half-borrow an idea from V8, which does a hidden class transform to use classes to implement a prototype-based model where each object has a class and objects with the same ivar layout and methods share the same class. In the runtime, we provide the building block for this in the form of hidden classes, which don’t show up when you use most of the reflection APIs. We use this to implement the locks for @synchronized and associated objects and have used it for a simple JavaScript-like language that uses the same methods.
None of this is really how you’d design a runtime for a prototype-based language though. It isn’t differential inheritance, there’s no way to clone an object as a copy-on-write view of another object. In Self, for example, you create a new object by cloning an existing one and then properties and methods that you assign to that object are unique to it, properties and methods that you don’t assign come from the prototype (or, rather, one of the prototypes: Self supported multiple prototype chains, which was all sorts of fun to implement efficiently).
Cocoa makes great use of that for attaching bindings to objects by replacing implementations of their setters and getters dynamically (per instance, not per class!),
I’m not sure about the most recent implementations. This is how we implemented KVO on WinObjC, by building on the GNUstep runtime’s hidden class support, but Apple’s implementation at least used to pivot the methods on the class and then to a set lookup to see whether it should trigger the hooks. They may have replaced this with one that added a new subclass for KVO, but that is visible in reflection.
I think 10.7 also introduced the imp_methodFromBlock call, which let you generate a trampoline that wrapped a block as a method (moving the receiver over the _cmd argument, the block over the self argument and then calling the block’s invoke function). This is useful because it allows the block to own the set that contains weak references to objects that have the hook installed, rather than needing two lookups to find it.
This made it possible to have Interface Builder be a GUI for making GUIs, with drag’n’drop declarative connections between models and their views, while using the language runtime for it, and being compatible with programmatically-created objects too, without too much GUI-specific layer in between. That was a pretty neat way to build GUIs back when computers were single-threaded.
Interface Builder went all of the way back to NeXT and predated KVO by over a decade. I always felt it was a bad name because building interfaces was not really what it did. It creates serialised object graphs. Some of those objects are views.
Nothing it did was related to prototype-based OO though. It was purely a class-based tool.
My memory of this is hazy. I remember looking at ObjC runtime’s API and being surprised it allows a lot of stuff that the language syntax doesn’t hint at.
ObjC2 made .field call setters and getters, and with bindings that worked as an illusion of it being directly bound to the UI.
Yes, that was a mess. Objective-C had the philosophy that new semantics always came with new syntax. The property accessor notation broke this, and it was just syntactic sugar. a.foo and [a foo] were equivalent, but if you did a.foo += 2 that was equivalent to [a setFoo: [a foo] + 2] and the fact that it was two message sends was hidden. The same for the array access things.
Bindings didn’t use that at all. They used key-value coding (KVC) and key-value observing (KVO). KVO was fairly complex to implement but KVC was quite simple. The -setValue:forKey: method in NSObject would look for a method with the name matching the key and call it if it existed, look for an ivar if you had opted into this, or call a fallback method that let you dynamically implement arbitrary keys (for example, in NSMutableDictionary, every key could be set as a dictionary key via this mechanism). This was a totally different mechanism that gave a consistent interface to things exposed via accessors, ivars, or other alternative storage. The key-path variants just split the string using dot as a separator and did the same lookup on each component in the chain.
Cocoa Bindings were a set of generic controller objects that were configured by transforming delegate methods into accesses to key paths. They were never implemented in UIKit because, while they were very nice when they worked, they were incredibly painful to debug. If you got a key path wrong, there was nothing to stick a breakpoint on to find out what was going wrong, you just got views not updating. It was usually less effort to write the delegate and data source yourself than debug the one using bindings.
Interface Builder didn’t rely on bindings, it just connected ivars with IBOutlet in their declaration and methods with IBAction together. The nib files contained the instructions for these and the nib loader used the runtime’s APIs to set the ivars when it created the object graph.
I’ve long felt the same and this is why I have experimented with javascript on widget systems so much, and tend to use virtual methods and delegate properties (aka function pointers) a lot to simulate that prototype inheritance in D sometimes.
Glad to hear I’m not the only one. It’d always feel silly to go through the whole subclass dance when i just want something ever so slightly different for this one specific case.
I have been semi seriously using jj for a couple months (i tried it earlier last year and bounced off pretty hard, so this is my second attempt). I think where I’ve come to with it is that I like it in theory a lot, and the git integration is basically required if I’m collaborating with anybody else, but in practice I find it very difficult to use and often have to drop back into git in order to get something done.
I also recognize that it’s still an early project and I haven’t had as much time to put into learning it as would be ideal, so this shouldn’t be read as a critique of the project in any way. I really hope it continues to grow and gain popularity!
not knowing how to do something in jj and not being able to (or not having the time to) figure out from the docs - I forget the exact exact details but there was some change I made recently where I couldn’t get jj to do what I wanted so I ended up just recloning the repo in a separate directory and making the change with git
i only have jj installed and set up in a handful of repos so I’m constantly context switching which repo I’m in and how to make it work.
The second problem is hypothetically solvable by just switching everywhere but the fact that I don’t understand it and have run into situations like (1) make me nervous.
Edit: Oh actually I remember now–somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
If you’re willing to use discord, the discord is very friendly to questions, even beginner ones.
The docs do need work. It’ll get there.
somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
I’ve been having similar feelings, while git feels a bit like a bloated mess, as a Magit (/gitu) user I have not really seen where it solves a significant problem.
I also like the same workflow of making a bunch of changes, then coalescing them into commits. I actually think the “decide on a change, then implement it” flow is nicer, almost Pomodoro-esque, but it’s not how I work in practice.
Otherwise I have years of accumulated git fixing experience that doesn’t help me, and commit signing is painfully slow which isn’t great for jj’s constant committing.
I do hope we get some progress in the space, Pijul seemed promising, I just don’t see the value for me personally at this point.
Otherwise I have years of accumulated git fixing experience that doesn’t help me, and commit signing is painfully slow which isn’t great for jj’s constant committing.
I’ve been using git practically since it was initially released, I have 4 digit github user id. I’m on my 3rd or 4th attempt to switch to JJ. Breaking habits that are so old is really painful. Also there’s bunch of nice things that JJ could have but still doesn’t, and one can tell right away that the project is still early. Still, I hope it will be worth it…
In git managing a lot of commits is just too inconvenient, and despite all the deficiencies a lot of people (me included) can immediately see the potential of the whole philosophy.
commit signing is painfully slow
With git I use gpg on yubikey, so I need to touch the yubikey for every signature (paranoia hurts), and I had to just disable it in JJ, because it’s unworkable.
I hope eventually JJ will have ability to sign only when switching away from a change and/or when pushing changes. Similarly, I’m missing git pre-commit hooks. I hope soon JJ will have a hook system optimized for that flow.
I also really, really miss the git rebase -i.
Pijul seemed promising
Pijul seems great in theory, but JJ wins by being (at least initially) fully compatible with Git. One can’t ignore network effects as strong as Git has at this point.
Same here, but with a single unlock. I’ve been experimenting with signing through SSH on Yubikey instead, which seems to be somewhat faster. I guess GPG is also just waiting to get replaced by something that isn’t as user-hostile. I get a pit in my stomach every time I have to fix anything related to it.
One can’t ignore network effects as strong as Git has at this point.
This actually reminds me, I really like the fact that branches aren’t named, but in reality we’re all pushing to GitHub, which means you need to name your branches after all, and JJ even adds the extra step of moving your branch/bookmark before every push, which I thought was a bit of a drag.
JJ even adds the extra step of moving your branch/bookmark before every push, which I thought was a bit of a drag.
People are discussion big ideas with “topics” that would bring some of the auto-forwarding functionality of branches back. In the meantime, I found making a few aliases is perfectly fine. This one in particular is great:
It finds the closest ancestor with a bookmark and moves it to the parent of your working-copy commit. For me, pushing a single branch is usually jj tug ; jj p
I also have a more advanced alias that creates a new commit and places it at the tip of an arbitrary bookmark in a single step. This is great in combination with the megamerge workflow and stacked PRs:
cob = ["util", "exec", "--", "bash", "-c", """
#!/usr/bin/env bash
set -euo pipefail
# usage: jj cob BOOKMARK_NAME [COMMIT_ARGS...]
if test -z ${1+x}
then
echo "You need to specify a bookmark onto which to place the commit!"
exit 1
fi
target_bookmark="$1" ; shift
jj commit "$@"
change_id="$(jj --ignore-working-copy log --revisions @- --no-graph --template change_id)"
jj --ignore-working-copy rebase --revisions "$change_id" --insert-after "$target_bookmark"
jj --ignore-working-copy bookmark move "$target_bookmark" --to "$change_id"
""", ""]
I’ve been experimenting with signing through SSH on Yubikey instead
I have not looked into it. Does it work? I would definitely consider. Just not having to touch gpg is always a plus.
It generally does, and seems well enough supported (mainly GitHub). It does require registering the key as an allowed signing key in a separate file in ~/.ssh, but I can live with that I guess.
Note that you can still use git rebase -i in a colocated repo. Make sure to add the --colocated flag to jj git clone and jj git init. All my repos are always colocated, it makes all the git tooling work out-of-the-box.
The next time you run jj after a git rebase, it will import those changes from the git repo, so everything just works. With one big exception: jj will not be able to correlate the old commit hashes with the new ones, so you lose the evolog of every commit that changed its hash. But then again, git doesn’t have an evolog in the first place, so you’re not losing anything compared to the baseline.
It could be a fun side-project to add the git-like rebase UI to jj. A standalone binary that opens your editor with the same git rebase todo list, parses its content and submits equivalent jj rebase commands instead of letting git do it.
It could be a fun side-project to add the git-like rebase UI to jj. A standalone binary that opens your editor with the same git rebase todo list, parses its content and submits equivalent jj rebase commands instead of letting git do it.
Any particular reason you suggest a separate tool, rather than something to contribute to jj upstream? I also wouldn’t mind a convenient tool to reorder changes, and I would rather have it integrated in jj rebase directly. (This could also be a TUI instead, whatever.)
There are other interactive modes that git support, for example the usual -p workflows with a basic TUI to approve/reject patches in the terminal (as an alternative to jj’s split interface relying on a 2-diff tool), which I wouldn’t mind seeing supported in jj as well. (I don’t think it’s a matter of keeping the builtin feature set minimalistic, given that the tool already embeds a builtin pager, etc.)
Any particular reason you suggest a separate tool, rather than something to contribute to jj upstream? I also wouldn’t mind a convenient tool to reorder changes, and I would rather have it integrated in jj rebase directly. (This could also be a TUI instead, whatever.)
I think nobody has yet invented a text-based interface for general graph editing:
For example: It’s not obvious how to intuitively represent divergent branches in the git rebase -i interface.
Ideally, there would be a simple text-oriented way to express the topology (via indentation, maybe?), rather than relying on label/reset commands in git rebase -i.
(I don’t think git rebase -i can currently initiate edits which would affect multiple branches (with no common descendant), so you incidentally don’t encounter this situation that often in practice.)
For example: The “mega-merge” workflow, which involves continually rewriting a set of commits and re-merging them, seems particularly painful in the git rebase -i interface.
A non-text-based TUI might work (perhaps based on GitUp’s control scheme?), but nobody has implemented that, either.
There are other interactive modes that git support, for example the usual -p workflows with a basic TUI to approve/reject patches in the terminal (as an alternative to jj’s split interface relying on a 2-diff tool), which I wouldn’t mind seeing supported in jj as well.
A naive idea for a TUI would be to reuse the current terminal-intended visualization approach of jj log, or git log --oneline --graph: they show one change per line, with an ascii-art rendering of the commit placement on the left to visualize the position in the commit graph. In the TUI we could move the cursor to any commit and use simple commands to move them “up” or “down” in their own linear history (the default case), and other commands to move them to another branch that is displayed in parallel to the current branch (or maybe to another parent or child of the current node). Of course, this visualization allows other operations than commit displacement, arbitrary interactive-rebase style operations could be performed, or maybe just prepared, on this view.
You should already be able to do this with jj’s :builtin TUI
Woah, thanks! Turns out I read the doc before trying jj split, and I dutifully followed the recommendation to go with meld from the start, so I never got to try this.
Replying to myself: it looks like jjui offers a workflow similar to the text-based graph editing I described above, see their demonstration video for Rebase.
(I don’t think it’s a matter of keeping the builtin feature set minimalistic, given that the tool already embeds a builtin pager, etc.)
I do think it would bloat the UI. And I have a hunch that the maintainers would see it the same way, but do feel free to open a feature request! It’s always good to talk these things through.
My opinion is that the rebase todo list workflow is not very good and doesn’t fit with the way jj does things. When you edit the todo file, you are still making several distinct operations (reorder, squash, drop, reword etc.). In jj those map to a single command each. By just using the CLI, you can always confirm that what happens is what you expected. If it isn’t you can easily jj undo that single step. With the todo file, you just hope for the best and have to start all over if something didn’t go well. The todo file also is not a great graphical representation of your commit tree. In git, it’s realy optimized for a single branch. You can configure git so interactive rebase can be used in the context of a mega-merge-like situation… but the todo file will become very ugly and difficult to manage. On the other hand, the output of jj log is great! So I think offering the todo-file approach in jj would be inconsistent UI in the sense that it discourages workflows that other parts of the UI intentionally encourage.
Regarding the comparison with the pager, I don’t think the maintainers are too concerned about binary size or number of dependencies, but rather having a consistent UI. A pager doesn’t really intrude on that.
When you edit the todo file, you are still making several distinct operations (reorder, squash, drop, reword etc.). In jj those map to a single command each. By just using the CLI, you can always confirm that what happens is what you expected. If it isn’t you can easily jj undo that single step.
I find this argument very unconvincing. When I operate on a patchset that I am preparing for external review, I have a global view of the patchset, and it is common to think of changes that affect several changes in the set at once. Reordering a line of commits, for example (let’s forget about squash,drop,reword for this discussion), is best viewed as a global operation: instead of A-B-C-D I want to have C-B-A-D. The cli forces me to sequentialize this multi-change operation into a sequence of operations on individual changes, and doing this (1) is unnatural, and (2) introduces needless choices. Exercise time: can you easily describe a series of jj rebase command to do this transformation on commits in that order?
The todo file also is not a great graphical representation of your commit tree.
I agree! But the command-line is even worse as it is no graphical representation at all. It would be nice to have a TUI or a keyboard-driven GUI that is good at displaying trees when we do more complex things, but the linear view of an edit buffer is still better than the no-view-at-all of the CLI when I want to operate on groups of changes as a whole.
Exercise time: can you easily describe a series of jj rebase command to do this transformation on commits in that order?
Yeah, that’s not hard with jj.
jj rebase -r C -B A # insert C between A and its parent(s)
jj rebase -r B -B A # insert B between A and its parent, which is now C
And I would still insist that in a realistic scenario, these commits have semantic meaning so there are naturally going to be thoughts like “X should be before Y” which trivially translates to jj rebase -r X -B Y.
To make it clear though, I’m not saying your perspective is wrong. Just that I don’t think this workflow would be a good addition upstream. I’d be very happy if there was an external tool that implemented this workflow for you and I don’t think the experience would be any worse than as a built-in option (apart from the on-time install step I guess.)
But the command-line is even worse as it is no graphical representation at all.
What do you mean it’s not graphical? Have you seen the output of jj log? For example:
The cli forces me to sequentialize this multi-change operation into a sequence of operations on individual changes, and doing this (1) is unnatural, and (2) introduces needless choices.
I hear what you’re saying, and I think it’s kinda funny: from a different perspective, git rebase forces you into a serial sequence of operations, whereas jj rebase never does. Doesn’t mean you’re wrong, of course, it just took me a moment to grok what you meant, given that I usually view it as the opposite!
(Another pain point with the CBAD thing is that last time i had to do this, it introduced a lot of conflicts thanks to the intermediate state being, well, not what i wanted, and so seeing all that red was stressful. they disappeared after moving another commit around, but in the moment, i was not psyched about it)
Note that you can still use git rebase -i in a colocated repo. Make sure to add the –colocated flag to jj git clone and jj git init. All my repos are always colocated, it makes all the git tooling work out-of-the-box.
Oh, that’s good know. Generally, I am afraid to do anything with git directly after enabling jj in a given repo. I’m afraid of confusing myself, and I’m afraid of confusing the tooling.
It could be a fun side-project to add the git-like rebase UI to jj. A standalone binary that opens your editor with the same git rebase todo list, parses its content and submits equivalent jj rebase commands instead of letting git do it.
I’m looking forward for it to be built-in, at least eventually. git has it. And jj already opens commit message editor on jj desc, so it’s not some new type of UI.
Can you describe what you’re doing with interactive rebases that you can’t do (or can’t do as efficiently) with JJ? Is it specifically this interface to rebasing commits that you’re missing, or a particular feature that only works with git rebase -i?
Just the interface. Editing lines in a text editor is a perfect blend of (T)UI and CLI. Just being able to reorder commits would be great. With squash/fixup, that’s 99.9% of my usage of git rebase -i.
I have not really seen where it solves a significant problem.
The main problem I encounter that it could solve is when I talk to someone who doesn’t already know git and have to kinda sheepishly say “welllll, yeah you can get the code you want with this one tool, but it suuuuuuucks; it’s so bad, I must apologize on behalf of all programmers everywhere except Richard Hipp”
I’m fully aware that I’m just Stockholm-syndromed to git. Having tried to explain how to use git to someone myself, I completely agree that it’s incredibly opaque and inconsistent. I do think that a lot of that only surfaces once you use git in non-trivial ways, clone-edit-stage-commit-push might not be optimal, but it’s fine.
For casual users I feel like the biggest overall usability win would be if GitHub could find a way to let you contribute to a repository without having to fork it.
For casual users I feel like the biggest overall usability win would be if GitHub could find a way to let you contribute to a repository without having to fork it.
This is one of the reasons that as a serial drive-by contributor, I much prefer projects hosted on Codeberg (or random Forgejo instances, perhaps even SourceHut, though I’m not a fan of the email based workflow): I can submit PRs without forking.
After your comment I actually went back and signed into Codeberg, but I’m not finding how you’re supposed to PR without forking. Even their documentation talks about the fork-based workflow. Am I missing something?
It is the AGit workflow that lets you do this. It’s not advertised, because there’s no UI built around it (yet?), and is less familiar than the fork+PR model. But it’s there, even if slightly hidden.
While I’m in general not a big fan of it, that’s one useful thing about Githubs gh commandline tool: a simple gh repo fork in a clone of the upstream will create a fork and register it as a remote. Now if they only added a way to automatically garbage-collect forks that have no open branches anymore…
That’s still 1-2 commands more, and an additional tool, compared to a well crafted git push.
Of course, I could build a small cron job that iterates over my GH repos, and finds forks that have no open PRs, and are older than a day or so, and nukes them. It can be automated. But with Codeberg, I don’t have to automate anything.
I’m assuming “being screwed” means it was hard to fix the conflict, that sucks, I’m sorry to hear that.
What “first class” means in this conflict is that jj stores the information that the conflict exists as part of the metadata of the commit itself. Git doesn’t really let you keep a conflict around, it detects conflicts and then has you resolve them immediately. jj will happily let a change sit there conflicted for as long as you’d like. Rather than “good at making conflicts not happen in the first place,” which is a separate thing that seems like hasn’t been true for you. I don’t know if and what differences jj has with git in that regard.
I had it again today and managed to work my way through it but not because there’s a good “first aid in case of conflict” documentation or anything. That’s the major issue: the tricks and skills we collectively built up to work with and around git aren’t there for jj yet.
But then while resolving the conflict, gg showed my bookmark to have split into 3 which was mildly surprising to say the least.
OpenAI will collapse, the hype around LLMs will subside. There will be societal swing against LLMs to the point that even using them where they are useful will be difficult.
FOSS will completely die out as a culture, but most software will continue to be FOSS purely for pragmatic reasons. That said, it will become impossible to exclusively use FOSS.
“Hacking” culture (in whatever incarnation) will become incompatible with society as large. Yes, there will be holdouts, but you won’t be able to participate in society without proprietary devices and services that track you.
Vi/emacs will become impractical to use. Any new tool will come with VSCode integration and an expectation that VSCode is the only way to use the tool.
Software will become slower and software engineering will become even more byzantine and complicated. New wrappers over the existing wrappers will be developed.
Strong encryption will be made unlawful. Backdoors will be mandated in all software you have to use day to day. Anonymity will be illegal.
Europe will fall even more behind the rest of the world when it comes to technology. Europeans will continue to feel smug about it.
Civil rights will continue to be eroded in Europe. The European Union will become more authoritarian, all in the name of protecting democracy.
Wow, I feel strongly that the opposite will happen for almost all of those, except possibly 5 and 6, possibly 7.
Only really seems to be happening in certain bubbles, and even in those bubbles, I’m not sure how strong the momentum against LLMs is. Meanwhile, I’m seeing a lot of things like shitty AI generated images replacing shitty clipart images in signs, posters, and slides, I’m hearing more and more non-tech people talk about using ChatGPT. I suspect it’ll probably become ubiquitous, but in such a way that it will be seen as being the cheap and easy solution - much like clipart and stock Windows fonts.
I think this is going to depend a lot on what you mean exactly by FOSS, but the impression I get is that FOSS is growing, rather than dying, but that different groups are taking up the mantle. A lot of tooling that used to be built as sellable subscriptions is now being built out in the open. I think FOSS will change, and I think as many of the older generation will feel like their version of FOSS doesn’t exist any more, but I don’t think that’s the same as FOSS dying.
This feels much the same. Modern hacker culture feels very alive, just in more ways and more spaces. I think there will always be compromises, but there always were compromises before - RMS used to get his websites emailed to him to avoid non-FOSS software (and may well still do that).
Right now more and more tools seem to be embracing LSP, and I don’t think that’s likely to change. That simplifies integrating with VS Code and other more mainstream editors, but Vi and Emacs come along for the ride. Even ignoring those tools, I think VS Code is only popular in certain circles (admittedly very popular circles), and you still see a strong focus on IntelliJ and Visual Studio in the Java and C# worlds respectively.
This might be true, but I suspect it will have the corollary that software will become significantly more secure, and significantly more cross-platform. We’re already seeing this with browsers, where users are broadly safe running completely untrusted scripts on their machines due to strong sandboxing, and also with the Steam Proton work, which adds layers of abstraction between the underlying Linux machine and the games begin run, but allows Linux gaming to be a viable option.
I think this will happen, but I think it will fairly quickly end up going away again. The laws may end up on the books for years, but they struggle to be seriously enforced, and the whole thing will probably get brushed under the table.
I suspect this will happen or not happen on a case-by-case basis. Some industries will be stronger in Europe than in the rest of the world, other industries will stay behind their US and Chinese peers.
This feels like a throwback to ten or fifteen years ago rather than a prediction of the future. Data protection is an increasingly growing lobby in the EU, and I suspect it will increasingly be used against governments as much as against corporations. (In part, I suspect this is why backdoored encryption will fail - there is no force as strong as a German with the DSGVO in his hand.) I suspect there are some changes that will be seen as being authoritarian - increased digitalisation being a big one - but that the end result will largely be better levels of privacy and independence for most citizens.
I really wish I didn’t but I find myself agreeing with #2 and #3, at least as far as the next 15-20 years are concerned. I think that “personal computers” as we understood them in the 1990s will be slowly relegated to their Homebrew Computer Club roots – hobbyists tinkering with interesting, but ultimately significantly less capable platforms. Computing at large will increasingly move back to a “mainframe”-like model, via portable terminals which we’ll keep referring to as “phones” out of inertia, tablets, and so on. The incentives aren’t (primarily) technical in nature but economical. It’s hard to argue with the bottom line of a subscription model.
That may not be the worst thing in the long run. All the nominally useful bits of modern computing make it a little difficult to have fun with computers these days. Liberated from the bottom line constraints, personal computing platforms may ultimately become sufficiently “free” to be disruptive again. But I think we’ll see at least a generation or two of programmers before the tide begins to shift again. I’m not sure you and me will be alive to see it swing back that hard :-).
I’m cautiously optimistic about something else though: just like minicomputers and their software were, in part, a response to the enshitification of mainframe platforms, I wouldn’t put it past our generation to come up with a productive alternative to the enshitification of cloud- and subscription-based platforms. I’m not sure what that response would be; it won’t come by looking back on the good old days, that’s for sure.
With a new Cold War looming over us, I also fear the way #6 is going to unfold. I don’t know if strong encryption will be directly made unlawful; the rich and powerful who wield power by proxy (through lobbying, donations and the like) won’t be easily convinced to shove the cat back in the bag. What I suspect is more likely to happen is that stronger encryption schemes won’t be made public anymore, and existing ones will gradually get broken.
Feeble (and crumbling) privacy laws will mean we won’t learn about the latter right away. And, via the former, we’ll end up more or less in the situation we’ve been in the ’80s and early ’90s, where economic incentives (via commercial telecom, TV and so on) tugged at strong, publicly available encryption, but under tight technical lockdown. Basically, the only strong forms of encryption available to the wider public will be DRM schemes.
I get the joke, but I’d definitely say that Emacs is more practical to use today than it was in, say, 2005 to 2010. I was trying to write Java in it, then, and the tooling for things like completion was just completely unusable - hard to set up, and unreliable and slow once you did get it set up. I’m not doing Java anymore, but with comparable things like C#, LSP makes Emacs a first-class citizen.
No css does not change the semantic meaning. You, the author of a document, can change the layout and rendering of an element so the semantics are no longer matched. CSS does not do that, you do.
If you put “display: none” on an element are you really going to claim css is responsible for the semantic change?
If you put “display: none” on an element are you really going to claim css is responsible for the semantic change?
I mean, kind of, yeah. The semantic meaning of the content is going to change if portions of the content suddenly don’t exist any more. Not even screen readers will treat it as present. display: none is often used for toggles and things like that because it essentially removes any ability to see if interact with the hidden elements. That feels like a pretty semantic change to me.
I used screen readers as an example here because they directly interact with the semantic markup of a page than rendering the page visually would. A good way of getting an intuition for the semantics of a document is asking how a screen reader or the “simplified reader view” in a would see the page.
But that isn’t the key part of my argument, which is that if nothing indicates to the user that some content is there, then is it really semantically there? For example, if I build an accordion-like structure using display: none vs removing the DOM elements entirely, both versions will produce the same semantics when processed by any compliant user agent. So what’s the difference? Why is one a semantic change and the other only a visual change?
So much of this is missing the original claim, which was that the “semantic meaning of HTML” was changed by CSS. Which is utter nonsense! The semantics of HTML do not change. The way a human interprets what’s presented to them can easily change, but that’s not the same thing as the semantics of HTML.
I could make a bunch of empty divs and spans and use CSS to style them in a way that renders as lines or shapes or even things that look like letters which form words. But they would still, at the HTML level, be divs and spans with no text in them.
This is why I jumped to the example of using margins and padding to squash words together visually (or, if you prefer, to spread text out and create visual “whitespace”). Sure, a human reading the text might interpret it differently, but that doesn’t affect the semantic meaning of the HTML in the slightest.
I understand that you can render whatever you want at the presentational level, and that humans cannot really distinguish, say, semantic text and presentational text. I would argue that this is itself a sign that the “semantics vs presentation vs behaviour” model has significant flaws, but let’s stick with it for now.
This was the reason why I picked up on screen readers, because these provide a presentation of document that is typically much closer to the genuine semantics of a document than most browsers. You cannot just style a bunch of divs/spans/etc and expect the result to be read by a screen reader, because screen readers use a semantic interpretation of the DOM to decide what to present to the user, and those styled divs have no semantic content. Yet because of these whitespace rules (and, in fairness, a number of other rules), screen readers still need to use CSS in order to correctly interpret the
I used the example in another thread of a word like “nowhere”, where it is semantically important where you split it. Consider the HTML <span>now</span><span>here</span>. The semantics of this HTML is very explicitly to treat it like the single word nowhere. A screen reader should read the word “nowhere” as opposed to splitting it into two words. If you double-click on any part of this word in a browser, the entire word “nowhere” will be selected. This is the semantics of the HTML as written.
Except these semantics do change if we apply a CSS rule that forces either (or both) spans to be rendered as blocks and not as spans. In this case, the semantic meaning of this HTML is two words: “now” and “here”. The screen reader should read this as two words, the browser should treat it in all interactions as two words, and so on.
Note: when rereading your comment, I could also interpret it as saying that the semantic meaning of HTML is nothing more than the parsed AST representation of the HTML document. In a sense this is true, but I don’t think it’s a useful definition of semantics, and it doesn’t match how the term is usually used in this context. Typically, when talking about semantics in HTML, we’re treating the source code as a document containing text with different meanings — such as “text that is a header” or “text that is an abbreviation” or “text that is a link to a different document”. In that regard, I think it’s very clear that the correct semantic interpretation of that document relies on knowing whether, for example, the author intended to write the word “nowhere” or the words “now” and “here”.
I think you’re both right to point to screen readers and suspect some of the friction in discussions around this follow from trying to discuss the semantics of HTML when I think there’s conflict between “semantic HTML” and “the semantics of HTML”.
Poking at the screen reader is ~good because at least from the frame of “semantic HTML”, the “semantics” are mainly about the humans that write the HTML and the user agents that leverage it both using the tags in a way that squares with what the specs say they’re for (i.e., authors are not abusing these tags for some other purpose just because they like how user agents display/pronounce/print the contents). The perspective from which to evaluate whether it’s semantic in the sense of “semantic HTML” is the user agent.
Since it’s hard to keep that elephant out of the room, I think it’s very tricky to try and talk about “the semantics of HTML” in any other way… :)
[edit: I think I just replied to another of your comments as well - it was unintentional, just happened to be unread comments and I didn’t realise same author :) ]
Correct, but how is a browser (or more generally any layout mechanism in which semantic meaning and display are separate concerns) meant to identify that an author has created display rules that do not match the semantics of the elements involved? You can change style rules in latex such that the presentation no longer matches the semantics just as easily (YMMV :) ).
Fundamentally it is the job of an author to ensure that their document has the correct semantics, and if they are relying on the default semantics of elements (rather than things like ARIA), then they need to ensure that their presentation rules match those semantics. This isn’t even the standard CS “any problem that is too hard for me to be bothered solving is Turing complete” argument - it’s not possible for anyone other than the content author to know the actual semantics of their content vs the presentation of said content, let alone a computer.
The problem is authors that don’t consider that the way they interpret the world is not universal. This is not specific to anyone or group - while designers are notorious for creating content where the visual layout diverges wildly from the semantic layout, but even the original article is assuming universality of semantic meaning from the presence or absence of white space, which isn’t universal (this is not a dig at the author, this is just to illustrate the ease with which anyone can assume that their own interpretation of something is universal)
The whitespace behavior that people keep getting hung up on doesn’t change the “semantics” of HTML, either; as the original article noted, the exact same DOM parses out regardless. What changes is the presentation, because it turns out that when you instruct a user-agent to render something as block instead of inline, or vice-versa, it affects… the rendering.
I could, if I wanted to, style span in a way that renders identically to a header element (either header itself or one of the numbered ones), and then use a bunch of those in my web page. But an outlining tool would not know or care that spans are being rendered to look like headers; it would only notice actual headers. That is the “semantics of HTML”. And that is not changed in the slightest by how a document author chooses to style things with CSS, which is the point I keep trying over and over and over to get through to people.
Ah, so you were specifically talking about the DOM/AST representation. Fair enough, I think if you see that as the semantics, then of course they don’t change.
I (and I suspect the original comment you replied to, although I can’t be sure) was talking more in terms of the traditional content/presentation/behaviour model, where the contents is the semantics of the text. I guess @abathur is correct that semantics is a very overloaded term! In that sense, though, it’s quite clear that the meaning of the content of a document cannot be determined without applying the presentational rules. Or, more specifically, when acting as a standards-compliant user-agent, you cannot know whether I wrote the word “nowhere” or the words “now here” in my document until you’ve checked the CSS rules to determine whether I was using a block or an inline element.
Even more perverse, perhaps, the HTML specs and authoring guides generally say something like:
The span element doesn’t mean anything on its own,
I haven’t pondered it too deeply, but I’m not terribly sure how to apply it here. Some incomplete thoughts:
Since the tag means nothing, using style sheets to turn <span>now</span><span>here</span> into anything butnowhere is semantic abuse? (Many user agents ~enable us to do this, but it’s not like they stop us from misusing any other tag for its presentational effects.)
Since it doesn’t mean anything on its own, the guidelines give authors permission to attach arbitrary semantics to this element. (I.e., it isn’t fair of me to call it semantic abuse)
At least from a “semantic-html” perspective, the fact that the specs don’t define any semantics for the tag mean it’s nonsensical to evaluate/debate the semantics of markup containing them; they have Undefined Semantics?)
Ah, so you were specifically talking about the DOM/AST representation.
Not just the DOM. Going back to my example of spans styled to look like headings: there’s standardization for this stuff. The old complex HTML outlining algorithm is gone (and was never that great), but the spec still says how to generate an outline: The outline is all headings in a document, in tree order.
This is the sort of thing that HTML’s semantics are about. Could styling change how someone interprets the rendered result? Yes, but HTML’s semantics are not the same as the DOM and HTML’s semantics are unaffacted by this.
Consider another example: I could style a span to have the same color, text-decoration and cursor style as a, and even use things like :hover to make it pop a tooltip when you mouse over it. With a little JS I could even catch a click event and trigger navigation to a new URL. But no tool should announce that span as a link, because no amount of fiddling with it will make it an a or give it the semantics of an a.
it’s quite clear that the meaning of the content of a document cannot be determined without applying the presentational rules
This has been known for decades. I remember the original “CSS Zen Garden” project, for example, which showed how vastly differently you could style the same underlying markup. It’s not a new or noteworthy observation at this point.
The old complex HTML outlining algorithm is gone (and was never that great), but the spec still says how to generate an outline: The outline is all headings in a document, in tree order.
Sure, but you do not know the correct text to put in each heading unless you also evaluate the styling rules. Or rather, a user agent that supports CSS will (and should) produce very different results from a user agent that does not support CSS, and depending on the CSS in question, two user agents can produce very different results from each other. And this is just fetching the literal text of the heading nodes - this is not rendering, this is part of the specification for the innerText property, as defined in the HTML standard.
And this is just fetching the literal text of the heading nodes - this is not rendering, this is part of the specification for the innerText property, as defined in the HTML standard.
Quotes in the original. innerText results can change if a node is attached or floating from the dom tree too.
Think of innerText not really as a dom operation, but rather what that section would look like in a text-mode browser. It comes from IE’s old clipboard support - highlight this node and hit copy, then paste into notepad. What is there? That’s innerText.
How their contents look when rendered might change, but that’s expected – as the other reply points out to you, and as I’ve said over and over. Confusing “how it looks” with “the semantics of HTML” is the root error of basically this entire long thread.
That’s literally the point of separating concerns: one controls display of information, one conveys semantics.
More to the point: if your control of style is separated from the semantics then by definition it cannot inhibit display rules that violate those semantics because the display system by definition has no awareness of those semantics.
That said, let’s consider a hypothetical world in which we do not have separation of style and semantics, which is what is required to achieve the behavior the comment I replied to seems to want.
How would that work? How can you permit any styling/control of the presentation of a that has semantic meaning without permitting the author of said styling to undermine the semantic meaning of the element?
Seriously: consider emph - what style rules can you allow that do not permit undermining the semantic meaning of the element during display?
So to support “separation of semantic information and style” as the commenter seems to want the style system has to be aware of the semantics, has to at minimum introduce limitation on what style changes can be applied to elements with semantic meaning (ignoring the question of what those limitations could possibly be), which means if you do want consistent styling across your content you can no longer use any elements that have semantic meaning.
That’s the entire reason we separate the style and semantics in the first place.
Once you do that you have to recognize that it becomes possible for an author to make the visual representation incongruent with the semantic meaning of an element.
You cannot have separation of display and semantics without that possibility.
I don’t quite understand all of your comment, but I do agree that we should accept that CSS can change how the document is understood and perceived. I don’t think that’s a bad thing, either: the medium is the message, as they say! I don’t think it’s possible to separate how a document is marked up semantically from the way that document is styled. If I change one, the other will almost certainly have to change, except in very rare cases (and usually with a significant amount of effort).
In this case, CSS changes how the document gets perceived in a somewhat unexpected way, at least when you break down into the details, but it helps to demonstrate that we can’t separate these concerns fully.
Ok, I’ll try to be more clear. The options for your presentation model are that it is either aware of semantic meaning of the content, or it is not.
If it is not aware of the semantic meaning of the content, you cannot prevent someone from designing a presentation style that does not match the semantic meaning of the underlying content.
If the requirement is that the presentation cannot undermine the semantic meaning of the underlying content then the presentation system is obviously no longer separated from the semantics - eg no separation of display and content - and the only way you can actually prevent the display system from undermining the semantics is to drastically curtail what the style system can do, essentially to the extent that you prohibit per element style at all.
For example: what style rules can you apply to a div, emph, etc that would not allow the semantic meaning to change? Position, colour, font, … all of these impact the semantics for someone reading the content visually.
This is not a hypothetical question: how would you permit any kind of style rules that do not apply document-wide without the presentation being able to undermine the semantic meaning of the document?
This is not a hypothetical question: how would you permit any kind of style rules that do not apply document-wide without the presentation being able to undermine the semantic meaning of the document?
I wouldn’t! I don’t think it’s possible to have a presentational layer that cannot alter the meaning of the document. The meaning of a document should — and can only — be interpreted in the context of its presentation. This is why the content/presentation/behaviour model has never made much sense to me, and I suspect why it typically is a poor model for structuring a website’s codebase.
Suppose I have two HTML elements, each containing a single word of text, such that default browser rendering will place some amount of visible space between them, producing a “Hello World”. But then I use CSS to apply negative margin and/or padding to shift one of those elements visually closer and closer to the other, producing a visual “HelloWorld” with no visible space.
Have I changed the “semantic meaning” of the HTML elements and their contents by doing so?
What if, hypothetically, CSS gained finer-grained kerning control in the future and I used that to shift two words to run together?
I personally don’t think so, and I have a feeling you won’t think so. But it’s conceptually no different than the example in the article. The semantics of the HTML elements have not changed. All that’s happened is CSS has been applied to produce a different rendering which, to humans, gives the appearance of different semantics.
The article also doesn’t seem to grasp what’s going on in its own examples. When the author claims “whitespace handling is not done by the HTML parser”, that’s a not-even-wrong type of statement. The previous paragraph points out that the same DOM was produced regardless of the CSS display property, which clearly shows that the parsing is done identically either way. What changes is how user-agents render that HTML, and it should be no surprise whatsoever that applying CSS, or applying different CSS, can change the rendering. It also is not “damning” that CSS… does what CSS is intended to do, which is affect rendering.
It is not just a change of rendering, the textContent itself changes, as well as how the content is interpreted by screenreaders. If you want to shift the goalposts and say “foo\nbar” and “foobar” are identical content, then I won’t argue with that except agreeing to disagree, but I do not think those are identical text content, they have entirely different semantics and aren’t just a change in the rendering of the same content
textContent is not changed, it is innerText that changes, and this is expected with different visual stylings.
textContent is a representation of what is in the DOM. innerText is a plain text representation of what is displayed, so of course it changes with different renderings (it comes from IE’s clipboard support; innerText is what you would copy if you selected the text on screen, it also inserts tab characters between table cells and other things like that too). Screenreaders are also basically reading what’s on the screen, so no surprise they also interpret the styling in their own way when it is applied.
The case of <pre> and textContent the article points out is strange though, I don’t know the justification for that, but that’s a different example.
innerText would not change for the purely visual changes described in the previous post, nor would a screen reader read anything differently. I’d argue there’s a fairly large semantic difference between, say, “nowhere” and “now here”, but I can toggle between these two different semantics as purely CSS.
Now you could argue that even if innerText or the screen reader representation hadn’t changed, if we’d have removed the gap on a purely visual level, we’d still have changed the semantics of the text for anyone reading the text visually. Well, yes, and that’s one of the reasons that I think trying to treat semantics vs presentation vs behaviour as a kind of holy grail of web development is a bit of a lie we tell ourselves as web developers. In practice, all three are always locked together and typically cannot easily be separated.
But then I use CSS to apply negative margin and/or padding to shift one of those elements visually closer and closer to the other, producing a visual “HelloWorld” with no visible space.
But at least, the screen reader would speak those words separately, and other tools would look at those words as separate. You’ve tricked most of your users for sure but Lynx and Links would still display those words separately, screen readers would still speak them separately, and text extraction tool would still keep whitespace between the two words.
With that inline vs block however, the difference is felt more than on your regular GUI browser. Pretty much all tools can see a difference. That is, whatever semantic those tools are trying to extract and use, is changed by CSS. You could try and argue that it’s not actual semantics that’s being change, but here’s the thing: semantics is not out there in the world, it needs a cognition engine to act on it — most of the time that would be humans, though when you speak of formal systems the engine is often a program running on a computer.
So even your example does change the semantic for sighted users of a GUI browser. For for everyone and everything else however it did not, so you may see a disagreement on what’s the “actual” semantics there. What’s remarkable with inline vs block, is that pretty much everyone (except those who read the HTML directly) perceives a semantic change.
The article claimed the parsing of HTML changed based on CSS. The comment was replying to claimed the semantics of HTML elements changed based on CSS.
No such thing happened.
Nothing I do in the rendering/presentation layer changes the way HTML is parsed, or the semantics of HTML elements. All it can do is change what is presented to a user. Perhaps that’s a visual change for a graphical browser. Perhaps it’s a change in pronunciation for a screen reader. Perhaps it’s nothing at all in a browser that doesn’t implement enough rendering features to be affected. But changing the presentation, even if it changes how humans choose to interpret the presented text, does not change the parse and does not change HTML’s own semantics.
It very well can be. But this whole series of comments from you is a non-sequitur because you’re arguing about how a human interprets text while the original nonsensical claim I was rebutting was that the semantics of HTML had somehow been altered by a presentational change.
CSS already has that finer grain kerning control (well not kerning as I don’t recall this impacting actual kerning - ligatures and such): there are word- and letter-spacing styles that can be used to modify the spacing between words and letters (an exercise to the reader for which controls which :) ).
Fun fact: apparently my work on supporting that correctly in webkit was a contributing factor to me originally being hired by Apple originally something like two decades ago :)
I’m not sure how you’re using the word semantic here. The meaning of the HTML is not changed by the CSS at that link, only the layout. The inferred meaning taken from the English seen may be changed by the layout change but it is still a layout change…
I’m writing a blog post at the moment about the difference between SOLID’s “Open/Closed Principle” and the “shredding” concept discussed by Thorsten Ball on his blog. That difference feels very similar to the differences in approach described here: one wants to make smaller, additive changes, but struggles when faced with problems in underlying data models or abstractions; the other requires more work throughout the process, but makes it much easier to course-correct when something isn’t working.
I agree that the original choices had a lot to do with the existing experiences of the developers, but I wonder if Jeffries’ incremental design approach also comes from his background. The larger the project you’re working on, and the more developers are involved, the harder large-scale change becomes, and the more effective this incremental design approach becomes. You can’t rewrite large chunks of the code because (a) you probably don’t understand it in enough detail to handle all the edge cases, and (b) it’s very likely that other people will be working on that code as you make your changes, and they don’t want to have to work around you.
I’m not sure if the logical conclusion to that last paragraph is “incremental design works best for large projects with lots of developers” or “large projects with lots of developers are very difficult”, or some combination of the two…
The conclusion I take from this is that “genre programmers” struggle outside their genre, although we don’t have an example of Peter Norvig struggling to build a CRUD-style webapp for a perfect comparison.
Maybe this will bring the idea of “TypeScript tooling should run the typechecker before doing anything else” (like linting, running tests, etc.). It feels very backwards that you can make a bundle with vite or whatever without the code being in a compilable state.
I mean, most bundlers or compilers don’t automatically run a linter or force all the tests to pass before compiling the code. It’s surprisingly convenient being able to separate type checking from whether the code runs or not. It makes it very easy to make a change locally and test it out, without having to update the entire codebase based on the change you’ve made. In most cases, you need to do compilation to get your code to run in the first place, but Typescript is lucky that type checking can be decoupled in this way.
Obviously everything needs to type check before ending up in production, but this is the same as tests, linting, and so on.
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
I disagree with this, only because it’s imperialism. I’m British, in British English I write marshalling (with two of the letter l), sanitising (-sing instead of -zing except for words ending in a z), and -ise instead of -ize, among other things. You wouldn’t demand an Arabic developer to write all his comments in English for your sake for the sake of being idiomatic, would you?
I’ve worked for a few companies in Germany now, about half of them with their operating language being in German. All of them had comments being written exclusively in English. I don’t know how that is in other countries, but I get the impression from Europeans that this is pretty standard.
That said, my own preference is for American English for code (i.e. variable names, class names, etc), but British English for comments, commit messages, pull requests, etc. That’s because the names are part of the shared codebase and therefore standardised, but the comments and commit messages are specifically from me. As long as everyone can understand my British English, then I don’t think there’s much of a problem.
EDIT: That said, most of these suggestions feel more on the pedantic end of the spectrum as far as advice goes, and I would take some of this with a pinch of salt. In particular, when style suggestions like “I tend to write xyz” become “do this”, then I start to raise eyebrows at the usefulness of a particular style guide.
Developers in China seem to prefer Chinese to English. When ECharts was first open-sourced by Baidu most of the inline comments (and the entire README) were in Chinese:
In Japan I feel like the tech industry is associated with English, and corporate codebases seem to use mostly English in documentation. However, many people’s personal projects have all the comments/docs in Japanese.
If someone wants to force everyone to spell something the same within a language they should make sure it’s spelled wrong in all varieties, like with HTTP’s ‘referer’.
The Go core developers feel so strongly about their speling that they’re wiling to change the names of constants from other APIs.
The gRPC protocol contains a status code enum (https://grpc.io/docs/guides/status-codes/), one of which is
CANCELLED. Every gRPC library uses that spelling except for go-grpc, which spells itCanceled.Idiosyncratic positions and an absolute refusal to concede to common practice is part and parcel of working with certain kinds of people.
We’re drifting off-topic, but I have to ask: gRPC is a Google product; Go is a Google product; and Google is a US company. How did gRPC end up with
CANCELLEDin the first place?!When you use a lot of staff on H-1B and E-3 visas, you get a lot of people who write in English rather than American!
Wait until you hear about the HTTP ‘Referer’ header. The HTTP folks have been refusing to conform to common practice for more than 30 years!
If this is something other than a private pet project of a person who has no ambition of ever working with people outside of his country? Yes, yes I would.
I believe the advice is still applicable to non-native speakers. In all companies I worked for in France, developers write code in English, including comments, sometimes even internal docs. There are a lot of inconsistencies (typically mixing US English and GB English, sometimes in the same sentence.)
In my experience (LatAm) the problem with that is people tend to have pretty poor English writing skills. You end up with badly written comments and commit messages, full of grammatical errors. People were aware of this so they avoided writing long texts in order to limit their mistakes, so we had one-line PR descriptions, very sparse commenting, no docs to speak of, etc.
Once I had the policy changed for the native language (Portuguese) in PRs and docs they were more comfortable with it and documentation quality improved.
In Europe people are much more likely to have a strong English proficiency even as a second or third language. You have to know your audience, basically.
While I like to write paragraphs of explanation in-between code, my actual comments are rather ungrammatical, with a bit of git style verb-first, removing all articles and other things. Proper English feels wrong in these contexts. Some examples from my currently opened file:
Those comments would most likely look weird to a person unfamiliar with your particular dialect.
In a small comment it’s fine to cut some corners, similar to titles in newspapers, but we can’t go overboard: the point of these things is to communicate, we don’t want to make it even more difficult for whoever is reading them. Proper grammar helps.
For clarification, this is not my dialect/way of speaking. But I see so many short interline comments like this, that I started thinking they feel more appropriate and make them too, now. Strange!
“If you use standard terms, spell them in a standard way” is not the same as “use only one language ever”.
Is “chapéu” or “hat” the standard way of spelling hat in Golang? If it’s “hat”, your standard is “only use American English ever”.
Is “hat” a standard term regularly used in the golang ecosystem for a specific thing and on the list given in the article? If not, it is not relevant to the point in the article.
(And even generalized: if it happens to be an important term for your code base or ecosystem, it probably makes sense to standardize on how to spell it. in whatever language and spelling you prefer. I’ve worked on mixed-language codebases, and it’d been helpful if people consistently used the German domain-specific terms instead of mixing them with various translation attempts. Especially if some participants don’t speak the language (well) and have to treat terms as partially opaque)
What? England had the word “hat” long before the USA existed.
I had to solve this once. I maintain a library that converts between HTML/CSS color formats, and one of the formats is a name (and optional spec to say which set of names to draw from). HTML4, CSS2, and CSS2 only had “gray”, but CSS3 added “grey” as another spelling for the same color value, and also added a bunch of other new color names which each have a “gray” and a “grey” variant.
Which raises the question: if I give the library a hex code for one of these and ask it to convert to name, which name should it convert to?
The solution I went with was to always return the “gray” variant since that was the “original” spelling in earlier HTML and CSS specs:
https://webcolors.readthedocs.io/en/latest/faq.html#why-does-webcolors-prefer-american-spellings
I thought you guys loved imperialism?
Imperialism is like kids, you like your own brand.
I don’t think it’s really “imperialism”—firstly, “marshaling” isn’t even the preferred spelling in the US. Secondly in countries all over the world job listings stipulate English language skills all the time (even Arabic candidates) and the practice is widely accepted because facilitating communication is generally considered to be important. Lastly, while empires certainly have pushed language standardization as a means to stamp out identities, I don’t think it follows that all language standards exist to stamp out identities (particularly when they are optional, as in the case of this post).
What makes you say that? (Cards on the table, my immediate thought was “Yes, it is.” I had no data for that, but the ngram below suggests that the single l spelling is the (currently) preferred US spelling.)
https://books.google.com/ngrams/graph?content=marshaling%2Cmarshalling&year_start=1800&year_end=2022&corpus=en-US&smoothing=3&case_insensitive=true
It’s imperialist to use social and technical pressure to “encourage” people to use American English so their own codebases are “idiomatic”.
I disagree. I don’t see how it is imperialism in any meaningful sense. Also “pressure” is fairly absurd here.
I like this idea! Do you think it’s extreme to try and implement dark/light mode using static HTML? I can’t seem to find a good workaround for a javascript-less solution to give people the option to choose to deviate from their system preference.
But it sure feels like overkill to generate a copy of each page just to avoid making someone enable JS to change the colors on their screen… which I don’t even do because I prefer everything in dark mode anyway.
There’s a CSS-only way (using a heavily restyled checkbox) to toggle other CSS attributes:
Today I learned that
light-dark()is a thing! Thanks!I’m using a similar idea for my own dark mode checkbox: https://isuffix.com (website is still being built).
GP comment might enjoy more examples of CSS
:has()in this blog post: https://www.joshwcomeau.com/css/has/I don’t understand why so many web sites implement a dark mode toggle anyway. If your page uses CSS conditionally on
prefers-color-schemeto apply a light theme or dark theme depending on the user’s system preference, why isn’t that enough?For example, if the user is looking at your page in light theme and suddenly they think their bright screen is hurting their eyes, wouldn’t they change their system preference or their browser’s preference to dark? (If they don’t solve the problem by just lowering their screen brightness.) After they do so, not only your page but all their other apps would look dark, fixing their problem more thoroughly.
For apps (native or web) the user hangs around in for a long time, I can see some reasons to allow customizing the app’s theme to differ from the system’s. A user of an image editing app might want a light or dark mode depending on the brightness of the images they edit, or a user might want to theme an app’s windows so it’s easily recognizable in their window switcher. But for the average blog website, these reasons don’t apply.
I am curious about how many people use it as well. But it certainly is easier to change by clicking a button in your window than going into your system or browser settings, which makes me think that it would be nice to add. Again, for the imagined person who decides to deviate from their system preference.
Although you’ve made me realize that even thinking about this without putting work into other, known-to-be-used accessibility features is kind of ridiculous. There is lower hanging fruit.
Here’s a concrete example. I generally keep my browser set to dark mode. However, when using dark mode, the online training portal at work switches from black text on a white background to white text on a white background. If I wanted to read the training material, I would need to go into my browser settings and switch to light mode, which then ruins any other tab I would switch to.
If there was a toggle button at the training portal, I could switch off dark mode for that specific site, making the text readable but not breaking my other tabs. Or, if the training portal at work won’t add the button, I could at least re-enable dark mode in every tab whose site had added such a toggle.
Or, hear me out, instead of adding javascript to allow users to work around its broken css, the training portal developers could fix its css?
(Browsers should have an easy per-site dork mode toggle like the reader mode toggle.)
I feel like this is something to fix with stylus or a user script, maybe?
sounds like the button fixes it
Sure, but only on sites that provide a button. It seems a little silly that one bad site should mean that you change your settings on every other site / don’t have your preferred theme on those sites.
Or the DarkReader extension or similar.
Given how widely different colour schemes can vary, even just within the broad realms of “light” and “dark”, I can imagine some users would prefer to see some sites in light mode, even if they want to see everything else in dark mode. It’s the same reason I’ve set my browser to increase the font size for certain websites, despite mostly liking the defaults.
It would be nicer if this could be done at the browser level, rather than individually for each site (i.e. if there was a toggle somewhere in the browser UI to switch toggle between light/dark mode, and if the browser could remember this preference). As it is, a lot of sites that do have this toggle need to either handle the preference server-side (not possible with static sites, unnecessary cookies), handle the preference client-side (FOUC, also unnecessary cookies), or don’t save the preference at all and have the user manually toggle with every visit. None of these options are really ideal.
That said, I still have a theme switcher on my own site, mostly because I wanted to show off that I made two different colour schemes for my website, and that I’m proud of both of them… ;)
I remember the days when you could do
<link rel="alternate stylesheet" title="thing" href="...">and the browser would provide its own nice little ui for switching. Actually, Firefox still does if you look down its menu (view -> page style), but it doesn’t remember your preference across loads or refreshes, so meh, not a good user experience. But hey, page transitions are an IE6 feature coming back again, so maybe alternate stylesheets will too someday.The prefers dark mode css thing really also ought to be a trivial button on the browser UI too. I’m pretty sure it is somewhere in the F12 things but I can’t even find it so woe on the users lol.
But on the topic in general too, like I think static html is overrated. Remember you can always generate html on demand with a trivial program on the server with these changes and still use all the same browser features…
I’ve been preparing something like this. You can do it with css pseudo selectors and a checkbox:
:root:has(#checkbox-id:checked)or so; then you use this to either ‘respect’ the system theme, or invert it.The problems I’m having with this approach:
Yeah, I think I saw the checkbox trick before, but the problems you outline make the
site/page/darkandsite/page/lightsolution seem more enticing, since they can avoid especially the state reset issue. I like the idea of respecting/inverting the system theme as a way of preserving a good default, though!Yeah, as an alternative, for the state issue I was thinking of using a cookie + choose the styles based on it, but that brings a whole host of other “issues”
This is highly dependent on culture of the team and style of development.
If you have an issue tracking system where you manage all bugs and change requests, then most information is here and discussions also happens here and then in commit message you can just link the number of the ticket (and maybe add some low-level comment for other developers, but it is optional, because everything important is already in the issue tracking system).
If the development is more spontaneous and informal and issue tracking system is missing or a lot of development work is done without assignments and formal change requests and bug reports, then commit messages are more important and deserve better description of what has been done and why.
And now you have an N+1 Select problem in your VCS. Now any time someone wants to understand the history of why a particular part of the code base changed in a certain way they have to do a mental manual join of each commit to each issue in the tracker. You’ve optimized for the current developers over the future ones.
I think the article should probably go deeper on why this is a problem, because it is one I’ve seen numerous times in legacy software maintenance.
An analogy for this is that an issue tracker is a plan for battle drawn up before any fighting starts, but a commit history is the journal of the what actually happened written by those who did the fighting. A history written for the survivors with just the first part is no real history at all.
I agree that the history is important and this is how I use the VCS – if I find some weird code and wonder why it was written this way and whether it was an intention or a weaker moment of the developer, I check the history and related tickets in the tracking system with comments from consultants or even customers and find the reasons behind it.
Whether these information should be duplicated in VCS is bit questionable – maybe as a backup case of issue tracking system loss… it probably will not harm anybody and will not take too much time to write such commit message. Important is that the details and motivation is documented somewhere.
I worked in a place where the issue tracker was full of really useful context, and I had the same process as you — always check the related tickets, because that would almost explain so much more of the context and reasoning for the change than any commit message could. The issue tracker had discussions with stakeholders, developers describing the issues they’d run into, all sorts of planning documents and diagrams, etc. So it had the plan of how changes would be made, the history of how they were made, and sometimes even retrospective/evaluation comments about what needed to be changed later.
Unfortunately, every other issue tracker I’ve used was anaemic in comparison, and so I’ve come to appreciate the power of a good commit message a lot more since working elsewhere.
I would write it in the commit message anyway. Yes, we have an issue tracking system, and branches are named after the ticket number, so you can definitely get some context just by looking at the merge commit, but bytes are cheap and having the information in-context is valuable. Also the commit messages can hold more developer-oriented technical information, while the issue tracker is more for the benefit of people who don’t actually care about most of that.
this is silly…CI isn’t having it run on the cloud via some rented server.
CI is making sure that env issues / local dev issues / whatever don’t break the build. Its the idea of dual-entry accounting, ie having a second path to check your work.
“signing off” work locally defeats that entire purpose
If the signing runs the exact same thing as the CI (as a pre-requisite) I don’t see the issue here?
Is it the element of trust that people are scared of?
I don’t think it does here though, does it? The signing is just a unilateral declaration that everything has passed — it doesn’t require that the tests have been run at all, nor that they were run in an environment anything like that of CI, or indeed production.
This seems an important distinction to me because I know that I am very fallible, and often forget things, ranging from big things like just forgetting to run certain tests, through to much more subtle things like having an environment that diverges from CI/production in such a way that tests will succeed on my machine but not in production.
It’s not about trust so much as consistency. I trust myself and my coworkers to write good code and to do things correctly. I don’t necessarily think we’re so consistent, though. But what’s incredibly good at being consistent? A script that runs in exactly the same environment every time, runs exactly the same operations every time, and never changes… which sounds a lot like CI.
That said, I do like the idea of utilising dev machines for CI workers more. I just think there’s probably a better implementation of that than this.
I imagine the intention is to enforce this by convention.
And at the end of said script you’d include a step execute the signing.
Who said their build is breaking though?
You can run something like this: https://github.com/nektos/act
Assuming you still test it in isolation before the final deployment, local testing can speed up small changes.
I think the most convincing defence of text labels is a discussion trying to find the best icon to use for a feature. It’s a conversation I’ve had multiple times, and we usually end up picking something that vaguely feels related, having combed through the Font Awesome icon list and thrown at least half a dozen suggestions into the mix.
If it’s this hard to pick an icon knowing what the icon is meant to represent, then how hard must it be for the user trying to reverse engineer our logic?
I agree with the author that the right icon at the right time is brilliant, and can make something immediately understandable at a glance — far more than a textual representation can do. But defaulting to text-with-icon (or even just text!) is probably the best place to start.
There was a time when software companies and web studios had their own graphic designers and they created custom icons to suit their needs. Instead of „picking something that vaguely feels related“.
However I agree that icon itself is sometimes not much useful and icon+text combination or even just text is sometimes better option.
P.S. There used to be books on how to design icons. The Icon Book by William K. Horton is great. It is a 1994 book. Is there something more contemporary worth reading? I found some books about design in general or some web resources, but no other comprehensive writing on icons.
More like American programmers
You’d think so! I did too.
I was the tech lead of the internationalization effort for a popular website a number of years back. This was in the US. The site was English-only and we wanted to make it available in a wide variety of languages. We wanted to make it feel as native to each language as we could, rather than feeling like a translation of a foreign site.
My team and I came up with a bunch of internal tools and a flexible library we could use to make our code work in multiple languages. When I say “flexible” I mean it went way beyond simple token replacement; it could do things like look up different variants of sentences depending on whether a caller-supplied place name referred to a city or a country and whether that distinction mattered in the target language, could use different pluralization rules for different languages, took gender into account if a sentence mentioned a person whose gender was known, and so on. We had people with linguistics backgrounds making sure we didn’t fall into any obvious traps.
The code base was far too big for my little team to update on our own, so an early goal was to give the rest of the engineering team all the resources they needed to do a really good job of updating their own corners of the code. In addition to thoroughly documenting our tools and libraries, we wrote up a set of annotated examples of how to change existing English-only code to be translation-friendly, and we made sure it covered all the common patterns in the code base (including visual design things like assuming a button only needed to be exactly big enough to hold an English label) and included examples of what could go wrong in different languages if people decided to just do string concatenation instead.
Then we started rolling it out. My expectation going into it was like yours: that the monoglot American devs would struggle to embrace all the techniques because English-specific assumptions would be too deeply ingrained.
But once I started doing code reviews of people’s changes, the reality was different. It turned out there was no measurable relationship between how good someone was at making their part of the site translatable into a wide variety of languages and which language(s) they spoke. Americans who’d never spoken anything but English were just as good at it, on average, as trilingual Europeans or people whose native languages were very different from English.
The thing that floored me was seeing people from other countries repeatedly make mistakes that would have made it impossible to correctly translate part of the site into their own native languages. This happened a lot, and it happened across multiple native languages. It seemed to me like some people were able to put their brains in “human language is highly variable and the code needs to act accordingly” mode, and some people were stuck in “I am working in English right now, so everything is English” mode, and it barely mattered if they happened to speak some other language or not.
Maybe the situation would have been different if the site had been in more than one language from the get-go; I don’t know. But that experience really shattered some of my preconceptions about the advantages of speaking multiple languages. (For the record: I still think it’s worthwhile to be multilingual!)
The first job I had in Germany, having moved here as a fresh-faced monolingual foreigner, was kind of like this. We were building an internal tool that was used by warehouse workers in various European countries. We knew we had a lot of fairly monolingual users in a variety of different languages, so when we decided to redesign the tool, I pushed really hard for making sure that every part of the UI was fully translated into all the relevant languages. I was amazed by how much my German colleagues pushed back against this, saying it would be a lot of effort, and people could just learn what the different English-language messages meant over time.
There were things a decade ago that my non-American English native speaker coworkers (Romanian, Croatian, Indian [Hindi & Marathi]) learned alongside me who’d been doing localization for a while — back then, I spoke natively American English but had six school years of Latin, 10+ years of self-driven Esperanto, and smattering of (Mexican) Spanish and (Canadian) French — when we did a big project targeting 10 languages on release days and 22 within four weeks in a patch release. I’ve picked up Dutch and some Korean since then and I’m constantly learning new things about language having gotten into linguist sector of Instagram, Threads, Bluesky, and the fediverse.
Unless you’re a linguist, you’re always learning surprising new things about language, discovering new tools in the toolbox, per se. If you’re a linguist, you’re learning which has/does what because you’re more familiar with what’s in the toolbox.
Cool you’ve learned so many languages. I’m currently trying to learn a new language and struggling a bit so maybe you can help. What are your preferred ways to learn a new language and make it stick?
Consistent practice. Try to experience all modes - reading, writing, listening, speaking, and conversing.
Find media you like. You don’t have to be even at 50% comprehension to listen to some audio, but obviously you’re only going to get little bits.
Adverts are much simpler than anything except children’s media.
Experiencing the language is generally the best way to internalize the rules, but reading up on complex rules to help you practice them is also important.
Regular practice. Duolingo is fine if all you can put into it is 10-15 minutes per day. That’s better than 0 and 5 minutes isn’t doing much. Most of my focus is on reading and writing until I started learning Dutch in 2023. You have to read a ton and listen a lot. I don’t listen as much as I should, but there are plenty of Dutch teachers and comedians on social media that I’ve come to enjoy.
I think it’s important to remember your purpose. I like learning languages because I like linguistics and language, not because I have an acute need to interact in another language. Honestly, some trips to Belgium and The Netherlands in the last few years have been the most immersive foreign language environment I’ve been in… and any Belgian or Dutch can tell you that you can get along just fine in most both of those countries speaking just English. I was able to use nothing but Dutch to get lunch in my great grandmother’s small hometown, though!
Thanks, I’ll keep practicing! :)
Absolutely not, I’ve seen a couple of these with German software, with English/French just an afterthought. And that’s already two languages where half of the stuff doesn’t even apply because they are both LTR languages in latin script. I will admit that it’s of course more likely to be a US/UK dev team.
Which ones are meant by this?
Romanian and Romani
and Romansh! And Romang!
It seems that Wikipedia has an editor in the know on this disambiguation, see the See Also on “Roman Language”.
That mix-up sure caused some embarrassment to the producers of Peaky Blinders.
On the other hand, the writers of Utopia leaned into it and had a whole plot point where the main characters mix up Romanian and Romani.
Both Indo-European though.
Maybe Javanese and Japanese?
This is one of the coolest new things I’ve seen on the internet lately - I can’t put my finger on why, but it has a very solarpunk feel to it.
Between this, forgefed, and radicle, it does feel like we’re starting to move in the right direction, finally!
We would still be limited by the patch order mattering in a snapshot-based VCS which hurts the ability to reasonably work conflict-free in a decentralized manner.
Can you avoid patch ordering in general?
Let’s say you’ve got a function
f()in a file that is called in multiple places. Patch A adds a new place wheref()is called. Patch B renamesf()tog()and updates all call sites.We cannot commute these patches, can we? If patch B comes first, then when patch A lands, it will be using the old name in a codebase that has been updated to use the new name. The resulting code is therefore only valid if A comes before B.
Not all patches commute, such as when they depend on one another, but many patches do commute—tautologically, in the way that 1 + 2 = 2 + 1 so order doesn’t matter in these cases. You deal with these conflict issues if/when they come up rather than every pull if your patch order is out of sync (
rerereis not foolproof, merge commits are incredible noisy & even they cause merge conflict issues sometimes). This does mean Alice can pull in patches from Bob then Carol, while Carol can pull from Alice then Bob & if it commutes, no conflict.In the past year, I have moved to nearly-entirely mouseless macOS.
Is there a way to make the native dialog boxes (typically an OK / Cancel sort of thing) keyboardable? That’s always what drove me nuts about MacOS. Just give me tab select and enter to trigger! I don’t understand why they’ve never adopted that.
My Mac experience doesn’t extend past Mac OS X, but that has/had Enter for OK and I think Space for Cancel. Do those no longer work?
There is an accessibility toggle somewhere that makes them (mostly) keyboard accessible. I can’t remember where it is exactly, but knowing that it exists is half the battle! ;)
Found it! System Settings -> Accessibility -> Keyboard -> Full Keyboard Access
Thank you, this is great. It’s even surprisingly configurable.
Always the first thing I go turn on on new macs!
Yes, this is huge. Forgot it above as I’ve been doing it long before any of those other tools (except maybe LaunchBar, since 2003 probably).
I was excited to try this out, but discovered that it prevents the space bar from working in kitty. I’m sure there is a way to fix that, but I wanted to leave a note here in case anyone else might try this out and then a hour later wonder why their space bar isn’t working in their terminal.
You can click the little ( i ) icon in the top right and change some of the bindings. I switched “activate” from space bar to what Apple’s always called “Return” (although I thought The Mac is not a Typewriter).
But I ended up turning it all off anyway, because the UX was so terrible and got in the way of everything. I only wanted keys for standard buttons on standard dialog boxes! I wish you better luck than I.
Oh. So the scope of change_id is just “active changes”, not “all changes”. I kind of assumed that a combination of base32 having larger … base, and maybe matching on the first (depth wise) was used, which is kind of similar, but I now understand that JJ is calculating actually unique prefix, just in a subset of changes. In my idea, I guess saying which of changes is actually “earlier” and which “later” might be a problem.
Change IDs are actually base 16! They just use a completely nonoverlapping alphabet to commit IDs.
^ This is also a key point. Change IDs are rendered in “reverse hex” notation, which is normal hex notation using the alphabet
z..kinstead of0..9a..f. This makes it easier to differentiate the two types of ID.OH. I’ve never noticed.
It’s kind of both.
All changes get a change ID, and JJ does calculate the unique prefixes for all those IDs when they get rendered (using the main indexes as described in the “Indexes in Jujutsu” section). It can do this efficiently because it stores all the IDs as a sorted list and can therefore see which IDs neighbour any given ID.
But it then also has a separate index for the active changes, that’s much smaller. So any change gets looked up first in the “active changes” index, then in the main indexes if it’s not found.
Is writing a 150 character commit message so difficult that it warrants invoking an
omniscient AIbig hammerLLM? I am not sure what this is forIt’s funny, I think the answer is probably “yes” given how many commit messages are “try” “lol” “ugh try again”.
It may hit a bit close to home, but the folks too lazy/sloppy/unskilled to properly handle good commit messages probably are the ones most easily replaced by LLMs.
Imagine if some people use this to create more descriptive commit messages for their personal projects. Crazy, I know.
Not my experience at all.
This right here. Spicy autocomplete is pretty good for writing a sentence when you’re mentally casting about to find the words.
That is very true :-)
As long as the LLM prompt is not “try” or “lol” or “ugh try again”
Well, let’s consider the cases. If the commit message that one would have put was “try” “lol” “ugh try again”, then what did we gain by having a more verbose commit message written by the LLM? Conversely, if the commit message is actually very important, should we really use an LLM to write it for us?
A very fair point, although I was being a bit tongue in cheek with my comment. I agree with you.
Arguably those provide more context about the “why” than an LLM-provided summary of the change: they convey that the committer is in a hurry, and that this is likely an (attempted) fix to a recent commit by the same author, probably as part of the same merge.
I’m ambivalent tbh. I know amazing devs who write those silly little intermediary commits. I try to organize my commits because I assume someone, one day, might want to review a commit log to figure stuff out, but I don’t have strong feels because I rarely do that myself.
Most of the people I know who write those sorts of commits tend to be basically using them as fixup commits, except that they tend not to be aware of
--fixupand probably find their flow more convenient anyway. When their change eventually appears in the main branch, it’s almost always squashed down to a single commit with a single well-written description (usually done via PRs in some git forge or other).Or in other words, I suspect the people writing those intermediary commits usually see them as temporary, and I don’t think they’d get much out of an LLM describing their changes.
Perhaps, yeah. I tend to clean up my commit history to remove those intermediary ones as well fwiw, but I know a lot of people who don’t. I suppose the answer isn’t “use an LLM” (I know I won’t) but to just learn how to rewrite your history properly.
Or even use tools that make managing your history easier. I do think Git makes it excessively hard to rewrite commits and maintain a history of the rewrites that you’re doing, which leads to people taking the “squash everything in a PR” approach, which is typically a lot easier. But better tooling in this regard can improve things a lot.
That said, this is perhaps getting a bit off-topic from the core idea of LLM-based commit messages.
Most simple use cases of LLMs are not that much more than an admission of the user’s own incompetence.
Sometimes there’s no bigger meaning behind some changes. It’s either obvious why it’s done or it becomes obvious in context of other changes. Writing commit messages for that is just going through the motions which means sometimes it becomes “refactor” or a similar message. In those cases it could be nice to have an automatic summary instead of nothing.
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.
Van Roy & Haridi CTM book argues OO is a specialized paradigm that excels at modeling GUIs.
OO as in the actor model is also excellent at concurrent & distributed systems. Right now, Van Roy is pretty active in Erlang.
The Newton folks claimed that GUIs needed two kinds of OOP. They argued that the class-based OO was good for models, where you would have a lot of the same kind of thing. For example, paragraphs of text in a word processor, people in an address book, and so on. In the traditional MVC model, they argued that the controllers exist because you really want a slightly different version of a view. For example, a one-off GUI widget for entering a phone number, which has to validate that the input is a particular format and then update a model, is annoying to implement as a custom subclass of a text view. They proposed using prototype-based OO for these, because prototype-based OO naturally encourages creating objects that behave almost like others.
I’ve yet to find any evidence that they were wrong. Even if you move to a model-view-update style GUI, I think their points still stand.
Some (possibly circumstantial) evidence against this theory: in Javascript, which is heavily used for building GUIs, and which has prototypal inheritance, most tooling is moving strongly away from OO-style code and towards more closure-oriented patterns. React hooks are the quintessential example here, but the same patterns now show up in Vue, SolidJS, Svelte, Preact etc. The only mainstream framework sticking to the more traditional OO-esque syntax is Angular.
Like I said, this isn’t definitive proof that OO doesn’t work for UI (and the fact that the DOM API is still defined in a largely OO manner with plenty of inheritance is a good counterexample). But I also find it significantly easier to compose behaviours and maintain codebases using the closure-style syntax (regardless of framework), and I think there’s a good reason why so much of the frontend world switched over to this style in a relatively short amount of time.
Cocoa + ObjC is an interesting example, because ObjC pretends to be a class-based OOP language, but the ObjC runtime is much more flexible, and almost a prototype-based OO, with full reflection support.
Cocoa makes great use of that for attaching bindings to objects by replacing implementations of their setters and getters dynamically (per instance, not per class!), as well as translating events to calling methods by name on whatever object in the hierarchy happens to implement one.
This made it possible to have Interface Builder be a GUI for making GUIs, with drag’n’drop declarative connections between models and their views, while using the language runtime for it, and being compatible with programmatically-created objects too, without too much GUI-specific layer in between. That was a pretty neat way to build GUIs back when computers were single-threaded.
I’m not sure what you mean by this, but you can’t add methods or ivars to an individual object. Since OS X 10.7, the Apple runtime has a notion of ‘associated objects’, which are kind-of like adding ivars, though with a very different implementation.
In the GNUstep runtime, we have a slightly more prototype-like model. We half-borrow an idea from V8, which does a hidden class transform to use classes to implement a prototype-based model where each object has a class and objects with the same ivar layout and methods share the same class. In the runtime, we provide the building block for this in the form of hidden classes, which don’t show up when you use most of the reflection APIs. We use this to implement the locks for
@synchronizedand associated objects and have used it for a simple JavaScript-like language that uses the same methods.None of this is really how you’d design a runtime for a prototype-based language though. It isn’t differential inheritance, there’s no way to clone an object as a copy-on-write view of another object. In Self, for example, you create a new object by cloning an existing one and then properties and methods that you assign to that object are unique to it, properties and methods that you don’t assign come from the prototype (or, rather, one of the prototypes: Self supported multiple prototype chains, which was all sorts of fun to implement efficiently).
I’m not sure about the most recent implementations. This is how we implemented KVO on WinObjC, by building on the GNUstep runtime’s hidden class support, but Apple’s implementation at least used to pivot the methods on the class and then to a set lookup to see whether it should trigger the hooks. They may have replaced this with one that added a new subclass for KVO, but that is visible in reflection.
I think 10.7 also introduced the
imp_methodFromBlockcall, which let you generate a trampoline that wrapped a block as a method (moving the receiver over the_cmdargument, the block over theselfargument and then calling the block’s invoke function). This is useful because it allows the block to own the set that contains weak references to objects that have the hook installed, rather than needing two lookups to find it.Interface Builder went all of the way back to NeXT and predated KVO by over a decade. I always felt it was a bad name because building interfaces was not really what it did. It creates serialised object graphs. Some of those objects are views.
Nothing it did was related to prototype-based OO though. It was purely a class-based tool.
Thanks for the corrections.
My memory of this is hazy. I remember looking at ObjC runtime’s API and being surprised it allows a lot of stuff that the language syntax doesn’t hint at.
ObjC2 made
.fieldcall setters and getters, and with bindings that worked as an illusion of it being directly bound to the UI.Yes, that was a mess. Objective-C had the philosophy that new semantics always came with new syntax. The property accessor notation broke this, and it was just syntactic sugar.
a.fooand[a foo]were equivalent, but if you dida.foo += 2that was equivalent to[a setFoo: [a foo] + 2]and the fact that it was two message sends was hidden. The same for the array access things.Bindings didn’t use that at all. They used key-value coding (KVC) and key-value observing (KVO). KVO was fairly complex to implement but KVC was quite simple. The
-setValue:forKey:method in NSObject would look for a method with the name matching the key and call it if it existed, look for an ivar if you had opted into this, or call a fallback method that let you dynamically implement arbitrary keys (for example, in NSMutableDictionary, every key could be set as a dictionary key via this mechanism). This was a totally different mechanism that gave a consistent interface to things exposed via accessors, ivars, or other alternative storage. The key-path variants just split the string using dot as a separator and did the same lookup on each component in the chain.Cocoa Bindings were a set of generic controller objects that were configured by transforming delegate methods into accesses to key paths. They were never implemented in UIKit because, while they were very nice when they worked, they were incredibly painful to debug. If you got a key path wrong, there was nothing to stick a breakpoint on to find out what was going wrong, you just got views not updating. It was usually less effort to write the delegate and data source yourself than debug the one using bindings.
Interface Builder didn’t rely on bindings, it just connected ivars with IBOutlet in their declaration and methods with IBAction together. The nib files contained the instructions for these and the nib loader used the runtime’s APIs to set the ivars when it created the object graph.
I’ve long felt the same and this is why I have experimented with javascript on widget systems so much, and tend to use virtual methods and delegate properties (aka function pointers) a lot to simulate that prototype inheritance in D sometimes.
Glad to hear I’m not the only one. It’d always feel silly to go through the whole subclass dance when i just want something ever so slightly different for this one specific case.
I have been semi seriously using jj for a couple months (i tried it earlier last year and bounced off pretty hard, so this is my second attempt). I think where I’ve come to with it is that I like it in theory a lot, and the git integration is basically required if I’m collaborating with anybody else, but in practice I find it very difficult to use and often have to drop back into git in order to get something done.
I also recognize that it’s still an early project and I haven’t had as much time to put into learning it as would be ideal, so this shouldn’t be read as a critique of the project in any way. I really hope it continues to grow and gain popularity!
What are the things that you’re dropping into git for, out of interest?
Two things:
not knowing how to do something in jj and not being able to (or not having the time to) figure out from the docs - I forget the exact exact details but there was some change I made recently where I couldn’t get jj to do what I wanted so I ended up just recloning the repo in a separate directory and making the change with git
i only have jj installed and set up in a handful of repos so I’m constantly context switching which repo I’m in and how to make it work.
The second problem is hypothetically solvable by just switching everywhere but the fact that I don’t understand it and have run into situations like (1) make me nervous.
Edit: Oh actually I remember now–somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
If you’re willing to use discord, the discord is very friendly to questions, even beginner ones.
The docs do need work. It’ll get there.
This is called a “divergent change” https://jj-vcs.github.io/jj/latest/FAQ/#how-do-i-deal-with-divergent-changes-after-the-change-id and as the FAQ says, if you only want one of them, abandon the other, and if you want both, duplicate one so it gets a new change id, and then abandon the one with the duplicate change id. Hopefully that can help you for next time!
I’ve been having similar feelings, while git feels a bit like a bloated mess, as a Magit (/gitu) user I have not really seen where it solves a significant problem.
I also like the same workflow of making a bunch of changes, then coalescing them into commits. I actually think the “decide on a change, then implement it” flow is nicer, almost Pomodoro-esque, but it’s not how I work in practice.
Otherwise I have years of accumulated git fixing experience that doesn’t help me, and commit signing is painfully slow which isn’t great for jj’s constant committing.
I do hope we get some progress in the space, Pijul seemed promising, I just don’t see the value for me personally at this point.
I’ve been using git practically since it was initially released, I have 4 digit github user id. I’m on my 3rd or 4th attempt to switch to JJ. Breaking habits that are so old is really painful. Also there’s bunch of nice things that JJ could have but still doesn’t, and one can tell right away that the project is still early. Still, I hope it will be worth it…
In git managing a lot of commits is just too inconvenient, and despite all the deficiencies a lot of people (me included) can immediately see the potential of the whole philosophy.
With git I use gpg on yubikey, so I need to touch the yubikey for every signature (paranoia hurts), and I had to just disable it in JJ, because it’s unworkable.
I hope eventually JJ will have ability to sign only when switching away from a change and/or when pushing changes. Similarly, I’m missing git pre-commit hooks. I hope soon JJ will have a hook system optimized for that flow.
I also really, really miss the
git rebase -i.Pijul seems great in theory, but JJ wins by being (at least initially) fully compatible with Git. One can’t ignore network effects as strong as Git has at this point.
Rejoice! This feature was released last week in v0.26.0: https://jj-vcs.github.io/jj/latest/config/#sign-commits-only-on-jj-git-push
That’s awesome! Thanks!
Same here, but with a single unlock. I’ve been experimenting with signing through SSH on Yubikey instead, which seems to be somewhat faster. I guess GPG is also just waiting to get replaced by something that isn’t as user-hostile. I get a pit in my stomach every time I have to fix anything related to it.
This actually reminds me, I really like the fact that branches aren’t named, but in reality we’re all pushing to GitHub, which means you need to name your branches after all, and JJ even adds the extra step of moving your branch/bookmark before every push, which I thought was a bit of a drag.
People are discussion big ideas with “topics” that would bring some of the auto-forwarding functionality of branches back. In the meantime, I found making a few aliases is perfectly fine. This one in particular is great:
It finds the closest ancestor with a bookmark and moves it to the parent of your working-copy commit. For me, pushing a single branch is usually
jj tug ; jj pI also have a more advanced alias that creates a new commit and places it at the tip of an arbitrary bookmark in a single step. This is great in combination with the megamerge workflow and stacked PRs:
Oh, welcome, fellow gpg-sufferer.
I have not looked into it. Does it work? I would definitely consider. Just not having to touch gpg is always a plus.
Same. I’m looking forward to some automatically-moving bookmarks
It generally does, and seems well enough supported (mainly GitHub). It does require registering the key as an allowed signing key in a separate file in
~/.ssh, but I can live with that I guess.I followed https://calebhearth.com/sign-git-with-ssh, and that worked just fine with my key from the Yubikey.
Note that you can still use
git rebase -iin a colocated repo. Make sure to add the--colocatedflag tojj git cloneandjj git init. All my repos are always colocated, it makes all the git tooling work out-of-the-box.The next time you run
jjafter a git rebase, it will import those changes from the git repo, so everything just works. With one big exception: jj will not be able to correlate the old commit hashes with the new ones, so you lose theevologof every commit that changed its hash. But then again, git doesn’t have anevologin the first place, so you’re not losing anything compared to the baseline.It could be a fun side-project to add the git-like rebase UI to jj. A standalone binary that opens your editor with the same git rebase todo list, parses its content and submits equivalent
jj rebasecommands instead of letting git do it.Any particular reason you suggest a separate tool, rather than something to contribute to
jjupstream? I also wouldn’t mind a convenient tool to reorder changes, and I would rather have it integrated injj rebasedirectly. (This could also be a TUI instead, whatever.)There are other interactive modes that
gitsupport, for example the usual-pworkflows with a basic TUI to approve/reject patches in the terminal (as an alternative to jj’ssplitinterface relying on a 2-diff tool), which I wouldn’t mind seeing supported injjas well. (I don’t think it’s a matter of keeping the builtin feature set minimalistic, given that the tool already embeds a builtin pager, etc.)I think nobody has yet invented a text-based interface for general graph editing:
git rebase -iinterface.label/resetcommands ingit rebase -i.git rebase -ican currently initiate edits which would affect multiple branches (with no common descendant), so you incidentally don’t encounter this situation that often in practice.)git rebase -iinterface.A non-text-based TUI might work (perhaps based on GitUp’s control scheme?), but nobody has implemented that, either.
If you’re only relying on approving/rejecting patches (and not e.g. editing hunks), then you should already be able to do this with jj’s
:builtinTUI (see https://jj-vcs.github.io/jj/v0.26.0/config/#editing-diffs).A naive idea for a TUI would be to reuse the current terminal-intended visualization approach of
jj log, orgit log --oneline --graph: they show one change per line, with an ascii-art rendering of the commit placement on the left to visualize the position in the commit graph. In the TUI we could move the cursor to any commit and use simple commands to move them “up” or “down” in their own linear history (the default case), and other commands to move them to another branch that is displayed in parallel to the current branch (or maybe to another parent or child of the current node). Of course, this visualization allows other operations than commit displacement, arbitrary interactive-rebase style operations could be performed, or maybe just prepared, on this view.Woah, thanks! Turns out I read the doc before trying
jj split, and I dutifully followed the recommendation to go withmeldfrom the start, so I never got to try this.Replying to myself: it looks like
jjuioffers a workflow similar to the text-based graph editing I described above, see their demonstration video for Rebase.I do think it would bloat the UI. And I have a hunch that the maintainers would see it the same way, but do feel free to open a feature request! It’s always good to talk these things through.
My opinion is that the rebase todo list workflow is not very good and doesn’t fit with the way jj does things. When you edit the todo file, you are still making several distinct operations (reorder, squash, drop, reword etc.). In jj those map to a single command each. By just using the CLI, you can always confirm that what happens is what you expected. If it isn’t you can easily
jj undothat single step. With the todo file, you just hope for the best and have to start all over if something didn’t go well. The todo file also is not a great graphical representation of your commit tree. In git, it’s realy optimized for a single branch. You can configure git so interactive rebase can be used in the context of a mega-merge-like situation… but the todo file will become very ugly and difficult to manage. On the other hand, the output ofjj logis great! So I think offering the todo-file approach in jj would be inconsistent UI in the sense that it discourages workflows that other parts of the UI intentionally encourage.Regarding the comparison with the pager, I don’t think the maintainers are too concerned about binary size or number of dependencies, but rather having a consistent UI. A pager doesn’t really intrude on that.
I find this argument very unconvincing. When I operate on a patchset that I am preparing for external review, I have a global view of the patchset, and it is common to think of changes that affect several changes in the set at once. Reordering a line of commits, for example (let’s forget about squash,drop,reword for this discussion), is best viewed as a global operation: instead of A-B-C-D I want to have C-B-A-D. The cli forces me to sequentialize this multi-change operation into a sequence of operations on individual changes, and doing this (1) is unnatural, and (2) introduces needless choices. Exercise time: can you easily describe a series of
jj rebasecommand to do this transformation on commits in that order?I agree! But the command-line is even worse as it is no graphical representation at all. It would be nice to have a TUI or a keyboard-driven GUI that is good at displaying trees when we do more complex things, but the linear view of an edit buffer is still better than the no-view-at-all of the CLI when I want to operate on groups of changes as a whole.
Yeah, that’s not hard with jj.
And I would still insist that in a realistic scenario, these commits have semantic meaning so there are naturally going to be thoughts like “X should be before Y” which trivially translates to
jj rebase -r X -B Y.To make it clear though, I’m not saying your perspective is wrong. Just that I don’t think this workflow would be a good addition upstream. I’d be very happy if there was an external tool that implemented this workflow for you and I don’t think the experience would be any worse than as a built-in option (apart from the on-time install step I guess.)
What do you mean it’s not graphical? Have you seen the output of jj log? For example:
I’d say that’s quite graphical. jj even has a templating language that let’s you customize this output in a very powerful and ergonomic way.
You don’t get this visual tree structure in git rebase’s todo file.
I hear what you’re saying, and I think it’s kinda funny: from a different perspective,
git rebaseforces you into a serial sequence of operations, whereasjj rebasenever does. Doesn’t mean you’re wrong, of course, it just took me a moment to grok what you meant, given that I usually view it as the opposite!(Another pain point with the CBAD thing is that last time i had to do this, it introduced a lot of conflicts thanks to the intermediate state being, well, not what i wanted, and so seeing all that red was stressful. they disappeared after moving another commit around, but in the moment, i was not psyched about it)
Oh, that’s good know. Generally, I am afraid to do anything with git directly after enabling jj in a given repo. I’m afraid of confusing myself, and I’m afraid of confusing the tooling.
I’m looking forward for it to be built-in, at least eventually. git has it. And jj already opens commit message editor on
jj desc, so it’s not some new type of UI.Can you describe what you’re doing with interactive rebases that you can’t do (or can’t do as efficiently) with JJ? Is it specifically this interface to rebasing commits that you’re missing, or a particular feature that only works with git rebase -i?
Just the interface. Editing lines in a text editor is a perfect blend of (T)UI and CLI. Just being able to reorder commits would be great. With squash/fixup, that’s 99.9% of my usage of
git rebase -i.TUIs like jjui are really good for that.
The main problem I encounter that it could solve is when I talk to someone who doesn’t already know git and have to kinda sheepishly say “welllll, yeah you can get the code you want with this one tool, but it suuuuuuucks; it’s so bad, I must apologize on behalf of all programmers everywhere except Richard Hipp”
I’m fully aware that I’m just Stockholm-syndromed to git. Having tried to explain how to use git to someone myself, I completely agree that it’s incredibly opaque and inconsistent. I do think that a lot of that only surfaces once you use git in non-trivial ways, clone-edit-stage-commit-push might not be optimal, but it’s fine.
For casual users I feel like the biggest overall usability win would be if GitHub could find a way to let you contribute to a repository without having to fork it.
This is one of the reasons that as a serial drive-by contributor, I much prefer projects hosted on Codeberg (or random Forgejo instances, perhaps even SourceHut, though I’m not a fan of the email based workflow): I can submit PRs without forking.
After your comment I actually went back and signed into Codeberg, but I’m not finding how you’re supposed to PR without forking. Even their documentation talks about the fork-based workflow. Am I missing something?
It is the AGit workflow that lets you do this. It’s not advertised, because there’s no UI built around it (yet?), and is less familiar than the fork+PR model. But it’s there, even if slightly hidden.
While I’m in general not a big fan of it, that’s one useful thing about Githubs
ghcommandline tool: a simplegh repo forkin a clone of the upstream will create a fork and register it as a remote. Now if they only added a way to automatically garbage-collect forks that have no open branches anymore…That’s still 1-2 commands more, and an additional tool, compared to a well crafted
git push.Of course, I could build a small cron job that iterates over my GH repos, and finds forks that have no open PRs, and are older than a day or so, and nukes them. It can be automated. But with Codeberg, I don’t have to automate anything.
Correct. Git is a tool I’d be embarrassed to show a new developer. Jujutsu is one of be proud of.
I at this point have been screwed most of the times that jj ran into a conflict. Not sure how first class it is…
I’m assuming “being screwed” means it was hard to fix the conflict, that sucks, I’m sorry to hear that.
What “first class” means in this conflict is that
jjstores the information that the conflict exists as part of the metadata of the commit itself. Git doesn’t really let you keep a conflict around, it detects conflicts and then has you resolve them immediately.jjwill happily let a change sit there conflicted for as long as you’d like. Rather than “good at making conflicts not happen in the first place,” which is a separate thing that seems like hasn’t been true for you. I don’t know if and what differencesjjhas withgitin that regard.I had it again today and managed to work my way through it but not because there’s a good “first aid in case of conflict” documentation or anything. That’s the major issue: the tricks and skills we collectively built up to work with and around git aren’t there for jj yet.
But then while resolving the conflict, gg showed my bookmark to have split into 3 which was mildly surprising to say the least.
In no particular order:
OpenAI will collapse, the hype around LLMs will subside. There will be societal swing against LLMs to the point that even using them where they are useful will be difficult.
FOSS will completely die out as a culture, but most software will continue to be FOSS purely for pragmatic reasons. That said, it will become impossible to exclusively use FOSS.
“Hacking” culture (in whatever incarnation) will become incompatible with society as large. Yes, there will be holdouts, but you won’t be able to participate in society without proprietary devices and services that track you.
Vi/emacs will become impractical to use. Any new tool will come with VSCode integration and an expectation that VSCode is the only way to use the tool.
Software will become slower and software engineering will become even more byzantine and complicated. New wrappers over the existing wrappers will be developed.
Strong encryption will be made unlawful. Backdoors will be mandated in all software you have to use day to day. Anonymity will be illegal.
Europe will fall even more behind the rest of the world when it comes to technology. Europeans will continue to feel smug about it.
Civil rights will continue to be eroded in Europe. The European Union will become more authoritarian, all in the name of protecting democracy.
Wow, I feel strongly that the opposite will happen for almost all of those, except possibly 5 and 6, possibly 7.
I really wish I didn’t but I find myself agreeing with #2 and #3, at least as far as the next 15-20 years are concerned. I think that “personal computers” as we understood them in the 1990s will be slowly relegated to their Homebrew Computer Club roots – hobbyists tinkering with interesting, but ultimately significantly less capable platforms. Computing at large will increasingly move back to a “mainframe”-like model, via portable terminals which we’ll keep referring to as “phones” out of inertia, tablets, and so on. The incentives aren’t (primarily) technical in nature but economical. It’s hard to argue with the bottom line of a subscription model.
That may not be the worst thing in the long run. All the nominally useful bits of modern computing make it a little difficult to have fun with computers these days. Liberated from the bottom line constraints, personal computing platforms may ultimately become sufficiently “free” to be disruptive again. But I think we’ll see at least a generation or two of programmers before the tide begins to shift again. I’m not sure you and me will be alive to see it swing back that hard :-).
I’m cautiously optimistic about something else though: just like minicomputers and their software were, in part, a response to the enshitification of mainframe platforms, I wouldn’t put it past our generation to come up with a productive alternative to the enshitification of cloud- and subscription-based platforms. I’m not sure what that response would be; it won’t come by looking back on the good old days, that’s for sure.
With a new Cold War looming over us, I also fear the way #6 is going to unfold. I don’t know if strong encryption will be directly made unlawful; the rich and powerful who wield power by proxy (through lobbying, donations and the like) won’t be easily convinced to shove the cat back in the bag. What I suspect is more likely to happen is that stronger encryption schemes won’t be made public anymore, and existing ones will gradually get broken.
Feeble (and crumbling) privacy laws will mean we won’t learn about the latter right away. And, via the former, we’ll end up more or less in the situation we’ve been in the ’80s and early ’90s, where economic incentives (via commercial telecom, TV and so on) tugged at strong, publicly available encryption, but under tight technical lockdown. Basically, the only strong forms of encryption available to the wider public will be DRM schemes.
At the risk of getting banned from this site, I’d say they’re already impractical, but people still use it, so, I don’t see that changing =P
I get the joke, but I’d definitely say that Emacs is more practical to use today than it was in, say, 2005 to 2010. I was trying to write Java in it, then, and the tooling for things like completion was just completely unusable - hard to set up, and unreliable and slow once you did get it set up. I’m not doing Java anymore, but with comparable things like C#, LSP makes Emacs a first-class citizen.
And it will seem perfectly justified in this timeline!
I find the section on how CSS changes the semantic meaning of HTML particularly damning. So much for separation of concerns!
No css does not change the semantic meaning. You, the author of a document, can change the layout and rendering of an element so the semantics are no longer matched. CSS does not do that, you do.
If you put “display: none” on an element are you really going to claim css is responsible for the semantic change?
Did you read the article? You did not respond to the claim in the article.
He responded to the claim in the comment he responded to.
…which is based upon the claim in the article
boom
what?
I said, “boom.”
I mean, kind of, yeah. The semantic meaning of the content is going to change if portions of the content suddenly don’t exist any more. Not even screen readers will treat it as present.
display: noneis often used for toggles and things like that because it essentially removes any ability to see if interact with the hidden elements. That feels like a pretty semantic change to me.That’s a weird argument: Screen readers are presentation!
I used screen readers as an example here because they directly interact with the semantic markup of a page than rendering the page visually would. A good way of getting an intuition for the semantics of a document is asking how a screen reader or the “simplified reader view” in a would see the page.
But that isn’t the key part of my argument, which is that if nothing indicates to the user that some content is there, then is it really semantically there? For example, if I build an accordion-like structure using
display: nonevs removing the DOM elements entirely, both versions will produce the same semantics when processed by any compliant user agent. So what’s the difference? Why is one a semantic change and the other only a visual change?So much of this is missing the original claim, which was that the “semantic meaning of HTML” was changed by CSS. Which is utter nonsense! The semantics of HTML do not change. The way a human interprets what’s presented to them can easily change, but that’s not the same thing as the semantics of HTML.
I could make a bunch of empty divs and spans and use CSS to style them in a way that renders as lines or shapes or even things that look like letters which form words. But they would still, at the HTML level, be divs and spans with no text in them.
This is why I jumped to the example of using margins and padding to squash words together visually (or, if you prefer, to spread text out and create visual “whitespace”). Sure, a human reading the text might interpret it differently, but that doesn’t affect the semantic meaning of the HTML in the slightest.
I understand that you can render whatever you want at the presentational level, and that humans cannot really distinguish, say, semantic text and presentational text. I would argue that this is itself a sign that the “semantics vs presentation vs behaviour” model has significant flaws, but let’s stick with it for now.
This was the reason why I picked up on screen readers, because these provide a presentation of document that is typically much closer to the genuine semantics of a document than most browsers. You cannot just style a bunch of divs/spans/etc and expect the result to be read by a screen reader, because screen readers use a semantic interpretation of the DOM to decide what to present to the user, and those styled divs have no semantic content. Yet because of these whitespace rules (and, in fairness, a number of other rules), screen readers still need to use CSS in order to correctly interpret the
I used the example in another thread of a word like “nowhere”, where it is semantically important where you split it. Consider the HTML
<span>now</span><span>here</span>. The semantics of this HTML is very explicitly to treat it like the single wordnowhere. A screen reader should read the word “nowhere” as opposed to splitting it into two words. If you double-click on any part of this word in a browser, the entire word “nowhere” will be selected. This is the semantics of the HTML as written.Except these semantics do change if we apply a CSS rule that forces either (or both) spans to be rendered as blocks and not as spans. In this case, the semantic meaning of this HTML is two words: “now” and “here”. The screen reader should read this as two words, the browser should treat it in all interactions as two words, and so on.
Note: when rereading your comment, I could also interpret it as saying that the semantic meaning of HTML is nothing more than the parsed AST representation of the HTML document. In a sense this is true, but I don’t think it’s a useful definition of semantics, and it doesn’t match how the term is usually used in this context. Typically, when talking about semantics in HTML, we’re treating the source code as a document containing text with different meanings — such as “text that is a header” or “text that is an abbreviation” or “text that is a link to a different document”. In that regard, I think it’s very clear that the correct semantic interpretation of that document relies on knowing whether, for example, the author intended to write the word “nowhere” or the words “now” and “here”.
I think you’re both right to point to screen readers and suspect some of the friction in discussions around this follow from trying to discuss the semantics of HTML when I think there’s conflict between “semantic HTML” and “the semantics of HTML”.
I’m already finding some small faults with how I put it, but I wrote a bit about this a few years back: https://t-ravis.com/post/doc/semantic_the_8_letter_s-word/
Poking at the screen reader is ~good because at least from the frame of “semantic HTML”, the “semantics” are mainly about the humans that write the HTML and the user agents that leverage it both using the tags in a way that squares with what the specs say they’re for (i.e., authors are not abusing these tags for some other purpose just because they like how user agents display/pronounce/print the contents). The perspective from which to evaluate whether it’s semantic in the sense of “semantic HTML” is the user agent.
Since it’s hard to keep that elephant out of the room, I think it’s very tricky to try and talk about “the semantics of HTML” in any other way… :)
[edit: I think I just replied to another of your comments as well - it was unintentional, just happened to be unread comments and I didn’t realise same author :) ]
Correct, but how is a browser (or more generally any layout mechanism in which semantic meaning and display are separate concerns) meant to identify that an author has created display rules that do not match the semantics of the elements involved? You can change style rules in latex such that the presentation no longer matches the semantics just as easily (YMMV :) ).
Fundamentally it is the job of an author to ensure that their document has the correct semantics, and if they are relying on the default semantics of elements (rather than things like ARIA), then they need to ensure that their presentation rules match those semantics. This isn’t even the standard CS “any problem that is too hard for me to be bothered solving is Turing complete” argument - it’s not possible for anyone other than the content author to know the actual semantics of their content vs the presentation of said content, let alone a computer.
The problem is authors that don’t consider that the way they interpret the world is not universal. This is not specific to anyone or group - while designers are notorious for creating content where the visual layout diverges wildly from the semantic layout, but even the original article is assuming universality of semantic meaning from the presence or absence of white space, which isn’t universal (this is not a dig at the author, this is just to illustrate the ease with which anyone can assume that their own interpretation of something is universal)
The whitespace behavior that people keep getting hung up on doesn’t change the “semantics” of HTML, either; as the original article noted, the exact same DOM parses out regardless. What changes is the presentation, because it turns out that when you instruct a user-agent to render something as
blockinstead ofinline, or vice-versa, it affects… the rendering.I could, if I wanted to, style
spanin a way that renders identically to a header element (eitherheaderitself or one of the numbered ones), and then use a bunch of those in my web page. But an outlining tool would not know or care thatspans are being rendered to look like headers; it would only notice actual headers. That is the “semantics of HTML”. And that is not changed in the slightest by how a document author chooses to style things with CSS, which is the point I keep trying over and over and over to get through to people.Ah, so you were specifically talking about the DOM/AST representation. Fair enough, I think if you see that as the semantics, then of course they don’t change.
I (and I suspect the original comment you replied to, although I can’t be sure) was talking more in terms of the traditional content/presentation/behaviour model, where the contents is the semantics of the text. I guess @abathur is correct that semantics is a very overloaded term! In that sense, though, it’s quite clear that the meaning of the content of a document cannot be determined without applying the presentational rules. Or, more specifically, when acting as a standards-compliant user-agent, you cannot know whether I wrote the word “nowhere” or the words “now here” in my document until you’ve checked the CSS rules to determine whether I was using a block or an inline element.
Even more perverse, perhaps, the HTML specs and authoring guides generally say something like:
I haven’t pondered it too deeply, but I’m not terribly sure how to apply it here. Some incomplete thoughts:
<span>now</span><span>here</span>into anything butnowhereis semantic abuse? (Many user agents ~enable us to do this, but it’s not like they stop us from misusing any other tag for its presentational effects.)Not just the DOM. Going back to my example of
spans styled to look like headings: there’s standardization for this stuff. The old complex HTML outlining algorithm is gone (and was never that great), but the spec still says how to generate an outline: The outline is all headings in a document, in tree order.This is the sort of thing that HTML’s semantics are about. Could styling change how someone interprets the rendered result? Yes, but HTML’s semantics are not the same as the DOM and HTML’s semantics are unaffacted by this.
Consider another example: I could style a
spanto have the same color, text-decoration and cursor style asa, and even use things like:hoverto make it pop a tooltip when you mouse over it. With a little JS I could even catch a click event and trigger navigation to a new URL. But no tool should announce thatspanas a link, because no amount of fiddling with it will make it anaor give it the semantics of ana.This has been known for decades. I remember the original “CSS Zen Garden” project, for example, which showed how vastly differently you could style the same underlying markup. It’s not a new or noteworthy observation at this point.
Sure, but you do not know the correct text to put in each heading unless you also evaluate the styling rules. Or rather, a user agent that supports CSS will (and should) produce very different results from a user agent that does not support CSS, and depending on the CSS in question, two user agents can produce very different results from each other. And this is just fetching the literal text of the heading nodes - this is not rendering, this is part of the specification for the
innerTextproperty, as defined in the HTML standard.innerTextis specifically defined to give a representation of what is displayed on screen, so yes, it is rendering. Hell, the spec https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute literally says:Quotes in the original. innerText results can change if a node is attached or floating from the dom tree too.
Think of innerText not really as a dom operation, but rather what that section would look like in a text-mode browser. It comes from IE’s old clipboard support - highlight this node and hit copy, then paste into notepad. What is there? That’s innerText.
The set of headings doesn’t change.
How their contents look when rendered might change, but that’s expected – as the other reply points out to you, and as I’ve said over and over. Confusing “how it looks” with “the semantics of HTML” is the root error of basically this entire long thread.
That’s literally the point of separating concerns: one controls display of information, one conveys semantics.
More to the point: if your control of style is separated from the semantics then by definition it cannot inhibit display rules that violate those semantics because the display system by definition has no awareness of those semantics.
That said, let’s consider a hypothetical world in which we do not have separation of style and semantics, which is what is required to achieve the behavior the comment I replied to seems to want.
How would that work? How can you permit any styling/control of the presentation of a that has semantic meaning without permitting the author of said styling to undermine the semantic meaning of the element?
Seriously: consider
emph- what style rules can you allow that do not permit undermining the semantic meaning of the element during display?So to support “separation of semantic information and style” as the commenter seems to want the style system has to be aware of the semantics, has to at minimum introduce limitation on what style changes can be applied to elements with semantic meaning (ignoring the question of what those limitations could possibly be), which means if you do want consistent styling across your content you can no longer use any elements that have semantic meaning.
That’s the entire reason we separate the style and semantics in the first place.
Once you do that you have to recognize that it becomes possible for an author to make the visual representation incongruent with the semantic meaning of an element.
You cannot have separation of display and semantics without that possibility.
I don’t quite understand all of your comment, but I do agree that we should accept that CSS can change how the document is understood and perceived. I don’t think that’s a bad thing, either: the medium is the message, as they say! I don’t think it’s possible to separate how a document is marked up semantically from the way that document is styled. If I change one, the other will almost certainly have to change, except in very rare cases (and usually with a significant amount of effort).
In this case, CSS changes how the document gets perceived in a somewhat unexpected way, at least when you break down into the details, but it helps to demonstrate that we can’t separate these concerns fully.
Ok, I’ll try to be more clear. The options for your presentation model are that it is either aware of semantic meaning of the content, or it is not.
If it is not aware of the semantic meaning of the content, you cannot prevent someone from designing a presentation style that does not match the semantic meaning of the underlying content.
If the requirement is that the presentation cannot undermine the semantic meaning of the underlying content then the presentation system is obviously no longer separated from the semantics - eg no separation of display and content - and the only way you can actually prevent the display system from undermining the semantics is to drastically curtail what the style system can do, essentially to the extent that you prohibit per element style at all.
For example: what style rules can you apply to a div, emph, etc that would not allow the semantic meaning to change? Position, colour, font, … all of these impact the semantics for someone reading the content visually.
This is not a hypothetical question: how would you permit any kind of style rules that do not apply document-wide without the presentation being able to undermine the semantic meaning of the document?
I wouldn’t! I don’t think it’s possible to have a presentational layer that cannot alter the meaning of the document. The meaning of a document should — and can only — be interpreted in the context of its presentation. This is why the content/presentation/behaviour model has never made much sense to me, and I suspect why it typically is a poor model for structuring a website’s codebase.
Suppose I have two HTML elements, each containing a single word of text, such that default browser rendering will place some amount of visible space between them, producing a “Hello World”. But then I use CSS to apply negative margin and/or padding to shift one of those elements visually closer and closer to the other, producing a visual “HelloWorld” with no visible space.
Have I changed the “semantic meaning” of the HTML elements and their contents by doing so?
What if, hypothetically, CSS gained finer-grained kerning control in the future and I used that to shift two words to run together?
I personally don’t think so, and I have a feeling you won’t think so. But it’s conceptually no different than the example in the article. The semantics of the HTML elements have not changed. All that’s happened is CSS has been applied to produce a different rendering which, to humans, gives the appearance of different semantics.
The article also doesn’t seem to grasp what’s going on in its own examples. When the author claims “whitespace handling is not done by the HTML parser”, that’s a not-even-wrong type of statement. The previous paragraph points out that the same DOM was produced regardless of the CSS
displayproperty, which clearly shows that the parsing is done identically either way. What changes is how user-agents render that HTML, and it should be no surprise whatsoever that applying CSS, or applying different CSS, can change the rendering. It also is not “damning” that CSS… does what CSS is intended to do, which is affect rendering.It is not just a change of rendering, the textContent itself changes, as well as how the content is interpreted by screenreaders. If you want to shift the goalposts and say “foo\nbar” and “foobar” are identical content, then I won’t argue with that except agreeing to disagree, but I do not think those are identical text content, they have entirely different semantics and aren’t just a change in the rendering of the same content
textContent is not changed, it is innerText that changes, and this is expected with different visual stylings.
textContent is a representation of what is in the DOM. innerText is a plain text representation of what is displayed, so of course it changes with different renderings (it comes from IE’s clipboard support; innerText is what you would copy if you selected the text on screen, it also inserts tab characters between table cells and other things like that too). Screenreaders are also basically reading what’s on the screen, so no surprise they also interpret the styling in their own way when it is applied.
The case of
<pre>andtextContentthe article points out is strange though, I don’t know the justification for that, but that’s a different example.innerTextwould not change for the purely visual changes described in the previous post, nor would a screen reader read anything differently. I’d argue there’s a fairly large semantic difference between, say, “nowhere” and “now here”, but I can toggle between these two different semantics as purely CSS.Now you could argue that even if
innerTextor the screen reader representation hadn’t changed, if we’d have removed the gap on a purely visual level, we’d still have changed the semantics of the text for anyone reading the text visually. Well, yes, and that’s one of the reasons that I think trying to treat semantics vs presentation vs behaviour as a kind of holy grail of web development is a bit of a lie we tell ourselves as web developers. In practice, all three are always locked together and typically cannot easily be separated.But at least, the screen reader would speak those words separately, and other tools would look at those words as separate. You’ve tricked most of your users for sure but Lynx and Links would still display those words separately, screen readers would still speak them separately, and text extraction tool would still keep whitespace between the two words.
With that
inlinevsblockhowever, the difference is felt more than on your regular GUI browser. Pretty much all tools can see a difference. That is, whatever semantic those tools are trying to extract and use, is changed by CSS. You could try and argue that it’s not actual semantics that’s being change, but here’s the thing: semantics is not out there in the world, it needs a cognition engine to act on it — most of the time that would be humans, though when you speak of formal systems the engine is often a program running on a computer.So even your example does change the semantic for sighted users of a GUI browser. For for everyone and everything else however it did not, so you may see a disagreement on what’s the “actual” semantics there. What’s remarkable with
inlinevsblock, is that pretty much everyone (except those who read the HTML directly) perceives a semantic change.The article claimed the parsing of HTML changed based on CSS. The comment was replying to claimed the semantics of HTML elements changed based on CSS.
No such thing happened.
Nothing I do in the rendering/presentation layer changes the way HTML is parsed, or the semantics of HTML elements. All it can do is change what is presented to a user. Perhaps that’s a visual change for a graphical browser. Perhaps it’s a change in pronunciation for a screen reader. Perhaps it’s nothing at all in a browser that doesn’t implement enough rendering features to be affected. But changing the presentation, even if it changes how humans choose to interpret the presented text, does not change the parse and does not change HTML’s own semantics.
It’s not a choice.
It very well can be. But this whole series of comments from you is a non-sequitur because you’re arguing about how a human interprets text while the original nonsensical claim I was rebutting was that the semantics of HTML had somehow been altered by a presentational change.
And I was rebutting your idea of what semantics is.
CSS already has that finer grain kerning control (well not kerning as I don’t recall this impacting actual kerning - ligatures and such): there are word- and letter-spacing styles that can be used to modify the spacing between words and letters (an exercise to the reader for which controls which :) ).
Fun fact: apparently my work on supporting that correctly in webkit was a contributing factor to me originally being hired by Apple originally something like two decades ago :)
I’m not sure how you’re using the word semantic here. The meaning of the HTML is not changed by the CSS at that link, only the layout. The inferred meaning taken from the English seen may be changed by the layout change but it is still a layout change…
I’m writing a blog post at the moment about the difference between SOLID’s “Open/Closed Principle” and the “shredding” concept discussed by Thorsten Ball on his blog. That difference feels very similar to the differences in approach described here: one wants to make smaller, additive changes, but struggles when faced with problems in underlying data models or abstractions; the other requires more work throughout the process, but makes it much easier to course-correct when something isn’t working.
I agree that the original choices had a lot to do with the existing experiences of the developers, but I wonder if Jeffries’ incremental design approach also comes from his background. The larger the project you’re working on, and the more developers are involved, the harder large-scale change becomes, and the more effective this incremental design approach becomes. You can’t rewrite large chunks of the code because (a) you probably don’t understand it in enough detail to handle all the edge cases, and (b) it’s very likely that other people will be working on that code as you make your changes, and they don’t want to have to work around you.
I’m not sure if the logical conclusion to that last paragraph is “incremental design works best for large projects with lots of developers” or “large projects with lots of developers are very difficult”, or some combination of the two…
The conclusion I take from this is that “genre programmers” struggle outside their genre, although we don’t have an example of Peter Norvig struggling to build a CRUD-style webapp for a perfect comparison.
Perhaps the real wisdom here is in knowing your limits and sticking to your expertise!