Unbelievable. I’m more convinced that Google is getting increasingly incompetent rather than being deliberately evil. There isn’t a day where I don’t spot a bug in one of their products. This makes me more skeptical about the SRE principles they spearheaded.
I think the thing with SRE is that there is a process to fix problems. SRE is not a QA department and has never been. SRE is about budgeting errors and spending them to increase development speed or saving them and decreasing development speed.
It’s also about learning from mistakes, so we will follow the postmortem process and see if we can improve our reliability next time or for the next thing.
I’m pretty sure we’re not publishing anything publicly on an issue like this, but there will be something internal.
I mean, I’m not at Google, but I’ve seen a few talks of the SRE marketing tour and it was definitely highlighted that SRE pro-actively works with product teams to avoid errors before they happen.
An under that framing, I would expect “track certificate expiration and rotate early” on the standard checklist, particularly for a device you ship to customers, where patching is not as easy.
It’s not like Google employees are happy to introduce bugs because they have a budget, or if they hadn’t followed the SRE principles they’d have zero bugs.
This certificate expiry thing is just an anecdote, but the bugs I notice every day mean that tracking velocity on the same terms as correctness may be fostering a culture that lowers the overall quality. Maybe SRE isn’t even at fault here, but the velocity/correctness has been tuned a bit too far for the past few years. I can only guess.
Ninety days…or what? Both the article and the linked story in the article don’t seem to explain the consequences and I imagine at Apple’s scale, they can afford to blow off quite a bit, especially if they want to avoid setting a precedent that they will easily comply.
Honestly, people said the same thing when the EU demanded Apple allow sideloading and they quite well caved in on that, even if they were a bit rules-lawyering it (and continue to do so).
The company would have 20 days to comply with Brazil’s antitrust legislation, otherwise it would be fined more than $40,000 a day.
That is still on the injunction from November, but I guess that also applies to the current order.
I mean, that’s probably way less than the daily earnings of the iPhone platform (hardware and software), but usually, that increases with ongoing non-compliance.
Not sure I see this in such a rose-tinted way. The linked ‘bug report’ is full of people specifying very exact ways that they want to be warned beforehand: I want a blog post, the post has to be dedicated specifically to this one thing, I don’t read Reddit, the tool itself should loudly warn me several months in advance.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
Nothing is perfect for sure. There were some more spicy commentary on this on social media, for example. But, it’s all about the overall ratio, and the outcome.
Notably, none of these comments actually volunteer any help with any of the above.
I both agree and disagree. I think it’s normal in bug reports to report the bug, and wait for a decision to be made, before offering help. I’m sure that if they asked for help, they would have gotten it. There’s actually a pretty high degree of social cohesion here, which may not be obvious to outsiders, but I recognize virtually all of the names on that ticket, and so like, I think it’s sort of understood that if active help was desired, all you have to do is ask. The original reporter is on the language team, for example.
Even the maintainer is talking about rustup as a ‘Rust project product’.
The Rust Project has long described their output as a product. There’s pros and cons to this, but it’s been the norm for at least 12 years now. I do attribute that style of thinking to be one of the reasons why Rust has been successful.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
As an ex-lead of the Rust project: I don’t think the Rust project needs more volunteers all the time. It has capacity for fixes, so just stating problems is fine. A lot of people in the discussion are also people who contribute to Rust at other places, by writing libraries, etc.
I think treating a tool as a product of some kind is an important part of ensuring it delivers value to users. There are several things this mindset implies, such as having a product vision rather than just exposing your internals and calling it a day.
I think it’s not about yours/other’s, but rather the fact that this is a link to raw source code, not to a blog post about the source code.
That is, you shouldn’t contextualize something which already explains itself, but, if you are linking to a primary artifact, some explanation is in order!
My father worked for Guinness for about 25 years. When I was growing up we had prints of the John Ireland calendar “the gentle art of making Guinness”, a splendid series of cartoons in the tradition of Heath Robinson or Rube Goldberg. Guinness advertising art was great.
But, it’s a mass-produced factory beer. I occasionally like a stout or other dark beer, but Guinness is boring.
Guinness was relatively early in the use of statistical quality control over large scale biochemical processes – that is where Student’s t-distribution was discovered.
I visited a brewery for one of the top 5 beer producers worldwide and the effort and care going into producing a consistent, safe product is impressive. The fact that the product itself is rather bland and boring is incidental :D
I like boring beer. Incoming long defense of Guinness:
I didn’t always used to be like, I used to like hoppy IPAs. But as I’ve gotten older my desire to drink beers higher than 5% has diminished so thoroughly that I can count the number of times I drink one per year on one hand.
I certainly would like to drink more complex stouts, but there are barely any brewed in America with the same ABV. For an example, I went to my favorite local brewery’s website, and Stout was always prefixed with imperial https://grimmales.com/menu/
I can’t drink these! They taste like syrup and instantly give me a headache.
Frankly, my go to beer these days is Asahi. I’m tired of complexity. Beer is less for me about complex flavors and more about refreshment and the desire to relax. In the cases when I want something more complex, I go for a cocktail. I make myself a Negroni or a Campari soda (depending on which side of refreshment and flavor I want).
Anyway. I love Guinness. It tastes good (that is to say it doesn’t taste like piss water), has a low ABV, and is served in basically every bar in Manhattan and Brooklyn. It fits my need
Thanks for saying that. I like it fine if it’s what’s available, but it tastes watered down to me compared to other stouts I’ve grown accustomed to. I’ll take it over something lighter, but it’s fairly plain.
If you’re in the US, be aware that the Guinness product sold as Extra Stout 20 years ago is now known as Foreign Extra Stout. Today’s Extra Stout is watered down in comparison (and undoubtedly cheaper to produce).
As bait-and-switches go, this is mild compared to Newcastle Ale…
I’m with you but would add that it genuinely does taste better in Ireland! To the point that I know some Irish people who will not drink Guinness abroad.
The story goes that this is due to the water but I suspect the truth is that Guinness have a lot of control over how it’s stored and served in pubs (temperature etc). Whether that should matter is an exercise left to personal taste.
I had an Irish colleague in France that spun the theory that French Guiness is a lot less bitter, because locals don’t like it.
He refused it.
My personal take on Guiness: I rarely drink and then I only rarely drink Guiness, so I enjoy it as an easy stout that comes with an expected taste. Sometimes, that’s just what I want.
(Fun fact about me: I do, however, have a taste for alcohol, my first job was sysadmin on a wineyard)
When I visited the Guinness Storehouse in Dublin the advertising floor was definitely the most interesting part. The rest was over the top displays or sections for social media tourism. I have to agree about it being boring, although I’ll often order it if there’s no other stout or porters served.
Also, their book of world records was endlessly entertaining when I was in primary school.
Many years after I tried Guinness (which I still occasionally enjoy, because it is boring in quite a pleasant way) I learned that the thing I really liked about it was that it was always a nitro pour. Seeking out interesting beers (mostly, but not all stouts) served on nitro taps has been fun.
I’m a big fan of nitro coffee! In the before times, I worked once or twice a week in an office that had a nitro cold brew tap in the kitchen, and that was enough to make me look forward to those office days. Come to think of it, everyone (of those who didn’t dislike coffee in general) really loved that perk.
This is caused by rustup, which shims cargo, rustc, etc to redirect to the required toolchain. Which is usually controlled by the user but a rust-toolchain file allows the directory to override it, which in turn can cause automatic installing of new toolchains without user involvement.
Funnily enough, implicit toolchain install was removed in rustup 1.28.0 but there was a big outcry about it so it’s being restored by default. Maybe a less invasive change would be an easier pill to swallow (e.g. only official toolchains are installed implicitly).
Is it really an error or just the classic issue that some people want safety and other people want the convenience of being able to do whatever they want (e.g. arbitrary code execution)?
I mean, the STPA is basically the observation you make, taken to the extreme: systems of “good” components have emergent behaviour that may or may not be seen as an error. For that reason, e.g. it does model humans in the loop as important, because they can make these judgement call.
The Mozilla lawyers say that CCPA and GDPR are not court-tested enough and they are making the ToU so broad such that the terms can prevent a lot of legal attacks. As someone who works for Mozilla, I have decided to trust them. But I can understand some people want to do their own reading…. ¯\_(ツ)_/¯
It must be stressful working for Mozilla and constantly being held to a higher standard.
Despite holding a pitchfork and having lost all faith in Mozilla’s leadership, I have nothing but respect for the people who have made Firefox a viable browser alternative for so long. Sorry you have to deal with this shit :/
Thank you. It would be a more realistic high standard if people contributed instead of complaining.
Filing bugs, finding duplicates, writing docs, everything counts. Not everyone has the necessary level of masochism to deal with a 20 year old C++/Rust/XHTML/CSS/JS codebase and that’s OK.
Heh, it’s not really masochistic if you just focus on an area that’s fairly isolated (for me it was platform stuff: kinetic scrolling for GTK, damage tracking for EGL, gamepad support with evdev, a couple little Wayland bugs, enabling stuff on FreeBSD…) – and what’s really amazing is the tooling, even just the fact that the build is literally just ./mach build and doesn’t take outrageous amounts of time nor memory (well, without LTO).
But I can understand some people want to do their own reading….
I mean, those terms are written for customers, who have to accept them, who are neither lawyers nor Mozilla employees. Legal writing for lawyers but for users to accept is malpractice.
It’s definitely a change in habit. I worked with Mozilla Legal around the GDPR compliance and documentation of crates.io and around the setup around the Foundation and they were very outside focused. Really loved it.
What I did find however is the classic that Mozilla is - curiously - very Californian, and not very international in their management and thinking. Peak of this was me observing someone trying to apply US case law to Germany, which doesn’t have case law.
All that said: I do trust Mozilla, but that’s because I have a privileged inside view through my work on Rust and in Tech Speakers and that can’t be what’s being asked of general users.
HOWEVER, I think it’s also the obligation of people criticizing to not spin the wildest legal theories. FOSS has a lot of armchair lawyers that can’t tell even tell personal information and copyrightable works apart.
Rustdoc, like a lot of tooling in Rust was actually significant step up from what other languages had when it was being created (pre 1.0). In 2025, after years of using it the novelty and amazement wore off and is a distant memory.
My favorite aspect of it immediately was that it was unobtrusive. I could just write stupid Markdown after three slashes and get decently looking automatically generated API documentation. Seems … basic and obvious, now, but in 2014 it was mind blowing how simple and convenient it is, when Java or C++ would requires some @doc or whatever obnoxious and tedious syntax.
Now, I really love Rust, and I love Rustdoc, but since me and most posters will keep praising it I will specifically focus on the negative side (cuz I’m Slavic, and complaining is our hobby).
The way inline documentation tests are handled (which is and even more so was when introduced an amazing idea), is kind of limited and inconvenient. You need to execute them with special syntax, fixing them is weird because tooling reports them weirdly, at least my text editor (Helix) can’t recognize them as nested Rust code.
LSP does not highlight broken links in documentation. If there’s a way to enable it, I’d love to know, and it really should be the default. After refactoring, I often have to run rustdoc and fix up all the links “manually”.
Integrating with larger documentation could be better. In our project we generate and publish (from the CI) rustdoc documentation with some embedded extra documentation, turning it all into kind of a mdbook. It works, but is limited and required quite a bit of hacking things together. Basically even customizing the landing page is an unstable feature, IIRC. I feel like rustdoc is so good at getting api documentation, that it makes sense to “embed it” into other, larger bodies of documentation in serious larger projects, and it would be easier if it exposed more hooks to tie into.
LSP does not highlight broken links in documentation. If there’s a way to enable it, I’d love to know, and it really should be the default. After refactoring, I often have to run rustdoc and fix up all the links “manually”.
If this is a comment about rust-analyzer: I can find a few open and closed issues about intra-links support in r-a, but nothing that quite describes that. Could you file a bug?
The way inline documentation tests are handled (which is and even more so was when introduced an amazing idea), is kind of limited and inconvenient.
One thing I’m wondering about for pigweed.dev is how good these docs tests work in an embedded Rust context. E.g. some of our code examples are intended to be run on physical RP2350s. Is there a mechanism to cross-compile for the RP2350 and then actually run the docs tests on physical RP2350s as hardware-in-the-loop tests? Based on this comment it sounds like rustc and rustdoc may have no problem with this, but I could also imagine it being quite a can of worms to get working correctly.
LSP does not highlight broken links in documentation. If there’s a way to enable it, I’d love to know, and it really should be the default.
Yes, considering all the craftsmanship in the rest of rustdoc I’m surprised that it has overlooked this core, easily verifiable aspect of docs quality!
Tangentially related, does rustdoc have cross-reference syntactic sugar like Sphinx/reStructuredText? E.g. I can create a section with an ID like this:
.. _guide:
==================
How to foo the bar
==================
And then in other docs to link to this section all I need to do is:
For more information, see :ref:`guide`.
And at “compile-time” it gets rendered as:
For more information, see <a href="…">How to foo the bar</a>.
Integrating with larger documentation could be better.
Definitely know this struggle! I need to figure out how to unify Pigweed’s auto-generated Python, C++, and Rust references with the rest of the site in a consistent manner.
Is there a mechanism to cross-compile for the RP2350 and then actually run the docs tests on physical RP2350s as hardware-in-the-loop tests?
You could make it work, but I believe it doesn’t work OOB. IIRC, the test harness (a program that the test framework generates that calls the test functions) requires std, so you are out of luck on platforms that do not have std.
There’s a few projects out there for this kind of stuff (I think there’s no difference between doctests and regular tests here that matters), but we haven’t found yet anything that ticks our boxes. Embassy is using teleprobe, and if you start to survey the major Rust embedded projects you’ll find a few more, but I don’t think there’s any ready to consume in a nice way yet.
Okay, rustdoc is actually the reason I came to Rust about 12 years ago. I joined at about 0.4. All that I’m writing about, exists roughly since then. Because rustdoc is a tool built by people who understood what can be useful for programming in the real, not in the abstract. Also, I won’t repeat @ssokolow.
On the surface, it’s a documentation generator like any other, with a reasonably nice HTML template (it comes out of browser vendor after all), which is very readable. They have an eye on how docs are consumed. It’s built for deep-linking in all aspects - want to link to a function? Sure. A header in one of the comments? Sure. Line of code in the underlying source code? No problem. It follows the rules of a good document.
It goes the extra mile by trying to make some of the weirder bits of Rust more accessible. A lot of functions that can be called on String are not from String, but from &str through Rust dereference. Of course, there’s a header called Methods from Deref<Target = str> that still lists them all in String. A return type is more a value that is returned because of the traits (think interfaces) it implements? There’s a small (I) next to it to tell you on hover and so on.
Before I go into those features, a little nerdery at first: rustdoc and rustc are intertwined in the sense that rustc is predominantly a library with multiple binaries on top, one of them is the compiler, one of them a linter (clippy) and one of them rustdoc. That means rustdoc always sees everything the compiler sees and is always built with the compiler. That means it can resolve connections between types properly, etc, etc. You can see a status of tools working over rustc nightly here: https://rust-lang.github.io/rustup-components-history/
Another interesting thing to know is that Rust comments are actually understood by the compiler much more than in other languages. They are not just commented out lines.
Something like:
/// This lobster is angry
fn pinch(&mut self, &mut Other) {
}
Docs in Rust are attributes of the thing they document, so they can be picked up through the AST. That means that rustdoc always has a very clear view what a comment belongs to.
What I’m getting at: documentation in Rust is much more a first-class citizen since about forever than you may realise.
That leads to a number of interesting features.
Rustdoc, since forever, e.g. has the ability to parse comments from your documentation and run them as code. If a code example is marked as rust code (```rust), rustdoc can extract it, compile it in the context of the library and run it as a test. This can be controlled, e.g. you can also tell it to compile the code, not run it (e.g. if it’s an example that starts a server and never returns) or even that the example should fail. rustdoc is more than a renderer.
That leads to a culture where Rust documentation examples are often very correct. Particularly all the stdlib examples are run through that process.
The second interesting thing is that rustdoc actually nowadays can be used to output a JSON dump of its data that holds enough meta data to write an extremely good semver checker in it (https://crates.io/crates/cargo-semver-checks).
I really like that it stuck to its guns and uses Markdown a text flavour. That’s a great choice, because, while Markdown lacks certain features one may want (I love rst as well), it is: very low bar, well understood and the right thing for writing a quick documentation comment.
I’m actually not a huge fan of the search function. It’s good, much better things are possible. I used to be a search engineer though, I appreciate that this is hard work that may bot be worth it in the end.
I think rustdoc is not cool because it’s in any way fancy. rustdoc is cool because it’s your reliable worked doing all the annoying work to do docs in good detail for you.
It’s built for deep-linking in all aspects - want to link to a function? Sure.
Just a note: As with non-lexical lifetimes, this is a feature that wasn’t present in Rust v1.0, felt like it took far too long to arrive for us old-timers, and now feels so natural that you’d never imagine it wasn’t there from the start.
Originally, you just had to generate the docs, see what the URL would be, and then reference it as an ordinary relative hyperlink.
I think you’re both saying different things. @skade was saying the anchors in the HTML were there from a very long time. You were saying the ability for rustdoc to compute and insert the link to a symbol is relatively more recent.
I don’t remember when the second ability was added but I remember reading it in release notes and being surprised it wasn’t possible yet! I’m pretty sure it had a nice dedicated section to highlight it.
EDIT: it was in Rust 1.48, released Nov. 19, 2020.
Thanks, this is exactly the kind of “in-depth info from people who have worked extensively with the tool for a long time” that I was looking for.
Docs in Rust are attributes of the thing they document, so they can be picked up through the AST.
Fascinating, did not know this. Do Doxygen and Javadoc not do this? I suppose the main difference is perhaps that Doxygen and Javadoc need to do their own work a lot more to associate the comments with the code, whereas in Rust the compiler itself is doing all that work by default.
rustdoc actually nowadays can be used to output a JSON dump of its data
Does this mean that it would be feasible to write a library like Breathe but for Rust? As commented here I’m pretty sure it’s not actually a good idea. Just curious if it’s possible. One thing I am very interested in, however, is whether it’s possible to pull in rustdoc metadata to improve Sphinx’s built-in, client-side search. E.g. when you go to pigweed.dev and press Ctrl+K to open the in-site search, ideally you can search by Rust type signatures from that UI.
I’m actually not a huge fan of the search function. It’s good, much better things are possible.
Fascinating, did not know this. Do Doxygen and Javadoc not do this? I suppose the main difference is perhaps that Doxygen and Javadoc need to do their own work a lot more to associate the comments with the code, whereas in Rust the compiler itself is doing all that work by default.
Yes, it’s entirely up to the doc tool. This is what the Java Specification has to say about Comments:
This is what the Rust/Ferrocene spec has to say about comments. This goes very much into details about what a comment applies to and how it is transformed on a language level.
rustdoc is just the agent that collects those things and puts them into nicer form.
Does this mean that it would be feasible to write a library like Breathe but for Rust? As commented here I’m pretty sure it’s not actually a good idea. Just curious if it’s possible. One thing I am very interested in, however, is whether it’s possible to pull in rustdoc metadata to improve Sphinx’s built-in, client-side search. E.g. when you go to pigweed.dev and press Ctrl+K to open the in-site search, ideally you can search by Rust type signatures from that UI.
Yes, though the format is unstable and may break between versions (it is indeed behind a barrier so that people are aware of the unstableness). But yes, you could totally use it.
Would love to hear more about this.
It’s very much “left to right”. So e.g. if I search for “Vec Push”, i find something, if i find “push vec”, I do not. I would really love be able to search for return values that implement a certain trait, etc. etc.
Can you at least give a small indicator of what you need the answer for? Improving rustdoc, assessing rustdoc, writing a new tool inspired by rustdoc? That would really help me answer.
Sorry if it was too vague. I was trying to be neutral and not steer the conversation in any particular direction.
My main goal is simply that I want to make my fellow technical writers (TWs) more aware of Rust’s approach to auto-generated docs. TWs at large have some familiarity with how it’s done in any other languages (Doxygen for C++, Javadoc for Java, autodoc for Python, etc.) but I have a hunch that they’re not as aware of Rust’s approach. I’ve dabbled with rustdoc but would like to hear more from people who have extensively worked with it, and especially how it stacks up to how it’s done in other languages. I will eventually probably write blog posts on https://technicalwriting.dev comparing/contrasting how different languages approach auto-generated docs. E.g. I know that being able to search by type signatures is a particularly beloved feature of rustdoc and I have a hunch that a lot of TWs aren’t aware that SWEs often heavily use this search strategy.
So, look. Every single internet-connected thing that involves anything that could even be considered user-generated content, and has lawyers, sooner or later inserts a clause into its terms saying you grant them a royalty-free, non-exclusive, non-revocable (etc. etc.) license to copy and distribute things you, the user, input into it.
This is like the most standard boilerplate-y clause there is for user-generated content. It’s a basic cover-your-ass to prevent someone suing you for copyright violation because, say, they just found out that when you type something in the built-in search box it makes a copy (Illegal! I’ll sue!) and transmits the copy (Illegal! I’ll sue!) to a third party.
But about every six months someone notices once of these clauses, misinterprets it, and runs around panicking and screaming OH MY GOD THEY CLAIM COPYRIGHT OVER EVERYTHING EVERYONE DOES WHY WOULD THEY NEED THAT PANIC PANIC PANIC PANIC PANIC OUTRAGE OUTRAGE PANIC.
And then it sweeps through the internet with huge highly-upvoted threads full of angry comments from people who have absolutely no clue what the terms actually mean but who know from the tone of discussion that they’re supposed to be outraged about it.
After a few days it blows over, but then about six months later someone notices once of these clauses, misinterprets it, and runs around panicking and screaming OH MY GOD THEY CLAIM COPYRIGHT OVER EVERYTHING EVERYONE DOES WHY WOULD THEY NEED THAT PANIC PANIC PANIC PANIC PANIC OUTRAGE OUTRAGE PANIC.
And then…
@pushcx this should not be allowed on lobste.rs. It’s 100% outrage-mob baiting.
That’s the point. GDPR has not been that well tested in court. As long as it hasn’t, people will stick to legal boilerplate to make it as broad as possible. This is why all terms of services look like copypasta.
Saying that everyone else does it does not make it okay.
Putting words in my mouth doesn’t make a counterargument.
What do you think is not OK about this boilerplate CYA clause? Computers by their nature promiscuously copy data. Online systems copy and transmit it. The legal world has settled on clauses like this as an alternative to popping up a request for license every time you type into an online form or upload a file, because even if nobody ever actually would sue they don’t want to trust to that and want an assurance that if someone sues that person will lose, quickly. They’ve settled on this because copy/pasting a standard clause to minimize risk is a win from their perspective.
Why is this evil and bad and wrong from your perspective? Provide evidence.
The system we currently have may be structured in a way which makes clauses like this necessary or expedient in order to do business, but the validity of such a clause for that reason doesn’t excuse the system that created it.
Every single internet-connected thing that involves anything that could even be considered user-generated content, and has lawyers, sooner or later inserts a clause into its terms saying you grant them a royalty-free, non-exclusive, non-revocable (etc. etc.) license to copy and distribute things you, the user, input into it.
But Firefox isn’t a web service. It’s a program that runs on my computer and sends data to websites I choose to visit. Those websites may need such legal language for user generated content, but why does Mozilla need a license to copy anything I type into Firefox?
This. I’ve chatted with a few lawyers in the space and this is literally the first time we’re seeing that interpretation to apply to a local program you choose to run that is your agent.
Firefox integrates with things that are not purely your “local agent”, including online services and things not owned by Mozilla. And before you decide this means some sort of sinister data-stealing data-selling privacy violation, go back and look at my original example.
When you upload something to the python package index you do so because you intend for the python package index to create copies of it and distribute it, which needs a license.
When you make a comment on pull request for work you don’t intend for Mozilla to have anything to do with that. You don’t intend for Mozilla to receive your post. Nor to have any special rights to view it, distribute it, make copies of it, etc. They do not need a license because they shouldn’t be seeing it. Moreover you don’t even necessarily have the right to grant them said rights - someone else might own the copyright to the material you are legitimately working with.
When you make a comment on pull request for work you don’t intend for Mozilla to have anything to do with that.
If you use their integrated search which might send things you type to a third party, Mozilla needs your permission to do that.
If you use their Pocket service which can offer recommendations of articles you might like, Mozilla needs your permission to analyze things you’ve done, which may require things like making copies of data.
If you use their VPN service you’re passing a lot of stuff through their servers to be transmitted onward.
There’s a ton of stuff Mozilla does that could potentially be affected by copyright issues with user-generated/user-submitted content. So they have the standard boilerplate “you let us do the things with that content that are necessary to support the features you’re using” CYA clause.
you grant them a royalty-free, non-exclusive, non-revocable (etc. etc.) license to copy and distribute things you, the user, input into it.
The question for random people reading these clauses is what does that mean? Legalese can be hard for lawyers to understand. It’s much harder for mere mortals.
I think everyone is OK with Firefox (the browser) processing text which you enter it into. This processing includes uploading the text to web sites (which you ask it to, when you ask it to), etc.
What is much more concerning for the average user is believing that the “ royalty-free, non-exclusive, non-revocable (etc. etc.) license” is unrestricted.
Let’s say I write the worlds most beautiful poem, and then submit it to an online poem contest via FireFox. Will Mozilla then go “ha ha! Firefox made a copy, and uploaded it to the Mozilla servers. We’re publishing our own book of your work, without paying you royalties. And oh, by the way, you also used Firefox to upload intimate pictures of you and your spouse to a web site, so we’re going to publish those, too!”
The average person doesn’t know. Reading the legalese doesn’t help them, because legalese is written in legalese (an English-adjacent language which isn’t colloquial English). Legalese exists because lawsuits live and die based on minutiae such as the Oxford Comma. So for Mozillas protection, they need it, but these needs are in conflict with the users need to understand the notices.
The Mozilla blog doesn’t help, because the italicized text at the top says: It does NOT give us ownership of your data or a right to use it for anything other than what is described in the Privacy Notice
OK, what does the Privacy Notice say?
(your) …data stays on your device and is not sent to Mozilla’s servers unless it says otherwise in this Notice
Which doesn’t help. So now the average person has to read pages of legal gobbledygook. And buried in it is the helpful
Identifying, investigating and addressing potential fraudulent activities,
Which is a huge loophole. “We don’t know what’s potentially fraudulent, so we just take all of the data you give to FireFox, upload to our US-based servers, and give the DoJ / FBI access to it all without a warrant”. A lawyer could make a convincing and possibly winning argument that such use-cases are covered.
The psychological reason for being upset is that they are confused by complicated things which affect them personally, which they don’t understand, and which they have no control over. You can’t address that panic by telling them “don’t panic”.
The psychological reason for being upset is that they are confused by complicated things which affect them personally, which they don’t understand, and which they have no control over. You can’t address that panic by telling them “don’t panic”.
Could you explain why the concern is necessarily born of confusion rather than accurate understanding?
you said the reason for being upset is that they are confused. sorry if I was changing your meaning by adding “necessarily.” why do you say the concern is because of confusion or lack of understanding? what understanding would alleviate the concerns?
I don’t see a lot of difference between confusion and lack of understanding. Their upset is because the subject affects them, and they’re confused about it / don’t understand it, and they have no control over it.
This is entirely normal and expected. Simply being confused isn’t enough.
What would alleviate the concerns is to address all three issues, either singly, or jointly. If people don’t use Firefox, then it doesn’t affect them, and they’re not upset. If they understand what’s going on and make informed decisions, then they’re not upset. And then if they can make informed decisions, they have control over the situation, and they’re not upset.
The solution is a clear message from Mozilla. However, for reasons I noted above, Mozilla has to write their policies in legalese, when then makes it extremely difficult for anyone to understand them.
but who does “they” refer to? are you saying this describes people in general who are concerned about the policy, or are you just supposing that there must be someone somewhere for whom it is true?
what about people who have an accurate layman’s understanding of what the policy means, and are nonetheless concerned?
The psychological reason for being upset is that they are confused by complicated things which affect them personally, which they don’t understand, and which they have no control over. You can’t address that panic by telling them “don’t panic”.
The actual reason for them being upset is that someone told them to be afraid of the supposedly scary thing and told them a pack of lies about what the supposedly scary thing meant.
I propose to deal with that at the source: cut off the outrage-baiting posts that start the whole sordid cycle. Having a thread full of panicked lies at the top of the front page is bad and can be prevented.
And if you really want to comfort the frightened people and resolve their confusion, you should be talking to them, shouldn’t you? The fact that your pushback is against the person debunking the fearmongering says a lot.
The actual reason for them being upset is that someone told them to be afraid of the supposedly scary thing and told them a pack of lies about what the supposedly scary thing meant.
i.e. you completely ignored my long and reasoned explanation as to why people are upset.
which explains clearly just how nefarious and far-reaching the new policy is.
At best that comment points out that a consolidated TOS for Mozilla “services” is confusingly being linked for the browser itself. Nothing has been proven in the slightest about it being “nefarious”, and the fact that you just assert malicious intent as the default assumption is deeply problematic.
So your position is completely unconvincing and I feel no need to address it any further.
But you’re not debunking the fear mongering. You’re conspicuously ignoring any comment that explains why the concern is valid. Don’t hapless readers deserve your protection from such disinformation?
You’re largely describing boilerplate for web services, where the expectation is that users input content, and a service uses that content to provide service.
Firefox is a user agent, where the expectation is that users input content and the agent passes that content through to the intended service or resource.
When you upload or input information through Firefox, you hereby grant us a nonexclusive, royalty-free, worldwide license to use that information
You can call this boilerplate if you like, but it certainly gives Mozilla unambiguous rights relative to what you put into it.
This is like the most standard boilerplate-y clause there is for user-generated content. It’s a basic cover-your-ass to prevent someone suing you for copyright violation because, say, they just found out that when you type something in the built-in search box it makes a copy (Illegal! I’ll sue!) and transmits the copy (Illegal! I’ll sue!) to a third party.
This really does beg the question: Firefox is 20 years old. Why did they only feel the need to add this extremely standard boilerplate-y clause now?
what exactly does that mean? Were they already actively doing this, and the lawyers “won” by updating the TOS to cover that behavior? Or did the lawyers “win” because they were pushing for a business decision to change Firefox’s data gathering activities?
I disagree. I think this is actionable, relevant, and very on-topic. I’d even argue about that with you here, except that you in particular have a very solid history of bad-faith arguing, and I have better things to do.
Anyway, so far 84 of us have upvoted it, vs 7 “off-topic” flags and 8 hides, for a ratio of about 5:1, if we care about user opinions. Your paternalism isn’t a good look. Just hide it, flag it, and move on!
I wouldn’t say that the site rules don’t mean anything–I would say that many users and even admins have disregarded them for political expediency.
The long-term effects of this, of course, are deleterious…but that doesn’t matter when gosh darnit, the outgroup is wrong right now.
In the case of Apple, there’s a weird sort of thing where a release tag covers what is technically marketing. They also are both a large software and hardware vendor and, like it or not, have a large userbase. I’m not saying we should see a constant dripfeed of Apple propaganda, but it isn’t entirely without precedent.
I wouldn’t say that the site rules don’t mean anything–I would say that many users and even admins have disregarded them for political expediency.
Of course. I adopted the parent comment’s hyperbole to avoid getting bogged down in minutia. But there’s nothing wrong with more clarity and precision.
I’m really surprised to see anyone pay even the slightest of attention to this on Lobsters. It’s something my granddad would post to Facebook (example)
I see a classic issue though. There’s a grey area between:
The proposed modes will not make use of any language extensions and will not change
semantics in incompatible ways,
(Top of the paper)
and
New rules to allow more operations.
particularly
Annotations for accessing objects via pointers in structures
Annotations for pointer ownership for dynamic memory management.
(End of the paper)
This sounds like at least introducing a kind of dialect into the language that you need to follow. While it is true that C has all the features to make this happen without a lot of changes: this is a different dialect that people need to learn and that codebases need to be ported to.
New rulesets, while theoretically compatible, can create something that is essentially the same as introducing breakages and new syntax.
This is a substantial effort at scale and may trigger the question “well, why not a rewrite in Rust and link it in?”.
However, such questions are useful to raise actively, because the decision may be a recommitting to C and its improvement.
I would like to represent the delegation of broke people in their 20s whose tech salaries are efficiently absorbed by their student loans:
You don’t need a smart bed. My mattress cost $200 and my bedframe cost <50. I sleep fine. I know as people age they need more back support but you do NOT need this. $250 worth of bed is FINE. You will survive!!
I’m not sure I agree. Like if you are living paycheck-to-paycheck then yeah, probably don’t drop $2k on a mattress. But I believe pretty strongly in spending good money on things you use every day.
The way it was explained to me that aligned with my frugal-by-nature mindset was basically an amortization argument. You (hopefully) use a bed every single day. So even if you only keep your bed for a single year (maybe these newfangled cloud-powered beds will also have planned obsolescence built-in, but the beds I know of should last at least a decade), that’s like 5 bucks a day. Which is like, a coffee or something in this economy. I know my colleagues and I will sometimes take an extra coffee break some days, which could be a get up and walk break instead.
You might be young now, but in your situation I would rather save for my old age than borrow against my youth. And for what it’s worth I have friends in their 20s with back problems.
(of course, do your own research to figure out what sort of benefits a mattress will give to your sleep, back, etc. my point is more that even if the perceived benefits feel minimal, so too do the costs when you consider the usage you get)
Mattresses are known to have a rather high markup, and the salesmen have honed the arguments you just re-iterated to perfection. There are plenty of items I’ve used nearly daily for a decade or more. Cutlery, pots, my wallet, certain bags, my bike, etc. None of them cost anywhere near $2000. Yes, amortized on a daily basis, their cost comes to pennies, which is why life is affordable.
Yes, there are bad mattresses that will exacerbate bad sleep and back problems. I’ve slept on some of them. When you have one of those, you’ll feel it. If you wake up rested, without pains or muscle aches in the morning, you’re fine.
I too lament that there are things we buy which have unreasonable markups, possibly without any benefits from the markups at all. I guess my point is more that I believe – for the important things in life – erring on the side of “too much” is fine. I personally have not been grifted by a $2k temperature-controlled mattress, but if it legitimately helped my sleep I wouldn’t feel bad about the spend. So long as I’m not buying one every month.
I think one point you’re glossing over is that sometimes you have to pay an ignorance tax. I know about PCs, so I can tell you that the RGB tower with gaming branding plastered all over it is a grift [1]. And I know enough about the purpose my kitchen knife serves to know that while it looks cool, the most that the $1k chef’s knife could get me is faster and more cleanly cut veggies [2].
You sound confident in your understanding of mattresses, and that’s a confidence I don’t know if I share. But if I think of a field I am confident in, like buying PCs, I would rather end the guy who buys the overly marked-up PC that works well for him than the one who walks a way with a steal that doesn’t meet his needs. Obviously we want to always live in the sweet spot of matching spend to necessity, but I don’t know if it’s always so easy.
[1] except for when companies are unloading their old stock and it’s actually cheap.
[2] but maybe, amortized, that is worth it to you. I won’t pretend to always be making the right decisions.
I personally have not been grifted by a $2k temperature-controlled mattress, but if it legitimately helped my sleep I wouldn’t feel bad about the spend.
Note, because it’s not super obvious from the article: the $2k (or up to about 5k EUR for the newest version) is only the temperature-control, the mattress is extra.
All that said: having suffered from severe sleep issues for a stretch of years, I can totally understand how any amount of thousands feels like a steal to make them go away.
One of the big virtues of the age of the internet is that you can pay your ignorance tax with a few hours of research.
In any case, framing it as ‘$5 a day’ doesn’t make it seem like a lot until you calculate your daily take-home pay. For most people, $5 is like 10% of their daily income. You can probably afford being ignorant about a few purchases, but not about all of them.
One of the big virtues of the age of the internet is that you can pay your ignorance tax with a few hours of research.
Maybe I would have agreed with you five years ago, but I don’t feel the same way today. Even for simple factual things I feel like the amount of misinformation and slop has gone up, much less things for which we don’t have straight answers.
For most people, $5 is like 10% of their daily income. You can probably afford being ignorant about a few purchases, but not about all of them.
Your point is valid. I agree that we can’t 5-bucks-of-coffee-a-day away every purchase we make. Hopefully the ignorance tax we pay is much less than 10% of our daily income.
I think smart features and good quality are completely separate issues. When I was young, I also had a cheap bed, cheap keyboard, cheap desk, cheap chair, etc. Now that I’m older, I kinda regret that I didn’t get better stuff at a younger age (though I couldn’t really afford it, junior/medior Dutch/German IT jobs don’t pay that well + also a sizable student loan). More ergonomic is better long-term and generally more expensive.
Smart features on the other hand, are totally useless. But unfortunately, they go together a bit. E.g. a lot of good Miele washing machines (which do last longer if you look at statistics of repair shops) or things like the non-basic Oral-B toothbrushes have Bluetooth smart features. We just ignore them, but I’d rather have these otherwise good products without she smart crap.
Also, while I’m on a soapbox – Smart TVs are the worst thing to happen. I have my own streaming box, thank you. Many of them make screenshots to spy on you (the samba.tv crap, etc).
Also, while I’m on a soapbox – Smart TVs are the worst thing to happen. I have my own streaming box, thank you. Many of them make screenshots to spy on you (the samba.tv crap, etc).
Yes, absolutely! Although it would be cool to be able to run a mainline kernel and some sort of Kodi, cutting all the crap…
You don’t need a smart bed. My mattress cost $200 and my bedframe cost <50. I sleep fine. I know as people age they need more back support but you do NOT need this. $250 worth of bed is FINE. You will survive!!
I guess you never experienced a period with serious insomnia. It can make you desperate. Your whole life falls in to shambles, you’ll become a complete wreck, and you can’t resolve the problem while everybody else around seems to be able to just go to bed, close their eyes and sleep.
There is so much more to sleep than whether your mattress can support your back. While I don’t think I would ever buy such a ludicrous product, I have sympathy for the people who try this out of sheer desperation. At the end of the day, having Jeff Bezos in your bed and some sleep is actually better than having no sleep at all.
You make some good points why this kind of product shouldn’t exist and anything but a standard mattress should be a matter of medical professionals and sleep studies. When people are delirious from a lack of sleep and desperate, these options shouldn’t be there to take advantage of them. I’m surprised at the crazy number of mattress stores out there in the age of really-very-good sub-$1,000 mattresses you can have delivered to your door. I think we could do more to protect people from their worn out selves.
None of the old people in my family feel the need for an internet connected bed (that stops working during an internet or power outage). Also, I imagine that knowing you are being spied on in your sleep by some creepy amoral tech company does not improve sleep quality.
I do know that creepy amoral tech companies collect tons of personal data so that they can monetize it on the market (grey or otherwise). Knowing that you didn’t use your bed last night would be valuable information for some grey market data consumers I imagine. This seems like a ripe opportunity for organized crime to coordinate house breakins using an app.
I believe the people who buy this want to basically experience the most technological “advanced” thing they can pay for. They don’t “need” it. It’s more about the experience and the bragging rights, but I could be wrong.
I’m sorry to somewhat disagree. The reason I would buy this (not at that price tag, I had actually looked into this product) is because I am a wildly hot person/sleeper. I have just a flat sheet on and I am still sweating. I have ceiling fans running additional fans added. This is not only about the experience unless a good night sleep is now considered “an experience”. I legitimately wear shorts even in up to a foot of snow.
Ouch… Please do not follow this piece of advice. A lot of cheap mattresses contain “cancer dust”[1] that you just breath in when you sleep. You most likely don’t want to buy the most expensive mattress either, because many of the very expensive mattresses are just cheap mattresses made overseas with expensive marketing.
The best thing to do is to look at your independent consumer test results for your local market. (In Germany where I live it’s “Stiftugn Warentest” and in France where I’m from it’s “60 millions de consommateurs (fr).” I don’t know what it is in the US.)
A good mattress is not expensive, but it’s not cheap either. I spend 8 hours sleeping on this every day, I don’t want to cheap out.
[1] I don’t mean literal cancer dust. It’s usually just foam dust created when the mattress foam was cut, or when it rubs against the cover. People jokingly call it “cancer dust”
I think this sort of thing, beyond anything technical, is the biggest argument for growing the standard library (or, at least, those official ordained and maintained by the rust-lang org). I can argue about the technical merits of Rust to my Rust-sceptic colleagues all day, but it’s difficult to deny that a worrying number of important dependencies in the ecosystem have a low bus factor.
I don’t understand how the standard library is any different?
Python, as one example, has several part of its standard library that are unmaintained and falling backward. Same for erlang. How is being part of the standard library helping?
Indeed, being in the standard library doesn’t guarantee active maintenance.
There aren’t enough people in the core team to work on everything. There still has to be someone with expertise and dedication to improve the code.
There aren’t that many people available for reviewing pull requests either. The standard library is focused on preserving backward compatibility and portability, so changes take more time and it’s harder to contribute more than an occasional drive-by tweak.
In Rust, mpsc channels were an example of this: they were in the standard library, technically maintained, but nobody actively worked on improving the implementation. Eventually the std code got replaced with an implementation developed outside of the standard library.
This just puts a bit of rusty paint on the problem. The Rust project had very little capacity for library maintenance, the bus factor would not differ substantially. Indeed, for that reason, the project has more moved libraries out rather than in.
Coming from another language ecosystem, I think this doesn’t acknowledge an extremely common scenario: library maintainer is AWOL, and people show up with patches, and it’s just that there is nobody there to hit merge and do a release.
There are huge piles of projects where there are a bunch of people who are capable, reviewing each other’s changes, and saying “yes this works, I have a fork and we have it working” etc etc etc, but the release can’t happen because one person holds the keys.
Having a large team who holds release keys is generally something that can work out! For every “the maintainer is the only one who could actually make a call on this”-style issue there are hundreds of “maintainer just is done with the project” situations.
I’m not calling to have eminent domain, but having lang teams be able to adopt packages (with maintainer consent) and allowing for a light touch can totally work, especially in the age of Github & co.
Bus factor and capacity are different things. I’m not expecting development to go faster or anything: but when something really, really critical pops up that needs fixing with haste, a larger pool of people ready to merge a fix and deploy a release matters. Ossification and glacial development is fine, not having an official patch for a CVE because the one dev is (quite understandably!) on holiday, less so.
The standard library only releases every six weeks. The more stuff that’s in the standard library, the more stuff that would maybe call for an emergency release, which is far heavier weight and far more disruptive to the ecosystem. People already think Rust releases too often.
Also, a crypto vulnerability is likely to have a high priority. If have to urgently release/deploy, I’d much rather update a single crate than the whole compiler and stdlib.
Not trying to be snarky, but is the complaint about too many releases (and operational churn)? Or too much breakage (from stuff like the “partial ordering for sorts can trigger panics now” saga)?
Like one, you do land on “we should bundle up releases”, but the other is a different flavor of thing, right? Though I mention the sorting panic thing only because it’s the only case I have even heard of.
Saying all that, while I like fat standard libraries, it does feel like the weaker version of “it’s in the rust-lang org but still packaged separately” gets things 95% of the way there for these kinds of issues, IMO.
Operational and “reputational” churn. The time crate is the only breakage I’ve experienced personally in a long time. The process for releasing rustc is involved, the process of releasing a crate is “cargo publish.”
I already regularly hear complaints from very conservative type folks who look at the six week cadence and complain about how often releases happen. Adding more to the mix regularly increases the perception that Rust is still mega unstable, when that’s just not the case.
Can defeinitely see rustc’s released process being involved vs cargo. Having multiple trusted people be able to run cargo publish is the valuable thing here, moreso than it being in the standard library itself.
I do think it’s important to dig into what the reason for the cadence complaints really are though. I feel like the biggest lesson to be taken from Chrome showing up and doing releases all the time is that smaller releases (-> more release) are easier to manage in theory. It would be a shame if those complaints are downstream of other issues that are, in a word, “more” fixable?
This is all context free of course. At least in Python land complaints of things moving too fast that I hear tend to be broken down into “too much new stuff to learn” (a reason I guess, but one I don’t care about) and “old code is not working anymore too often” combined with “package maintainers disappearing” (which are realer issues, and can be handled).
It’s just systems people who are used to C89 and so they see backwards compatible but new features as “breaking” because they want to stay on old compilers but compile new code.
OK I see the case now. The maximally generous version of this is “well there is some issue X that is stopping my upgrade but everything around me is moving so fast that it throws me forward” (in Node this is common because packages agressively upper bound node versions even when they don’t need to, leading to a bunch of incidental things making upgrades hard), but tbh I feel like Rust isn’t doing it that much. Especially nowadays where people seem pretty serious about not using stuff from nightly etc.
The maximally generous version of this is “well there is some issue X that is stopping my upgrade but everything around me is moving so fast that it throws me forward”
I agree, but the “issue x” is mostly “i want to use a dependency and it uses some rust language feature that is newer than my current stable version” and the “stopping my upgrade” is simply “I don’t want to” not “I tried it and it didn’t work.” That is, it’s perceived instability, rather than actual instability. For these folks, “stable” means “unchanging” not “backwards compatible.”
The shift from RSA to ECDSA is, relatively speaking, quite recent and we just had Microsoft announce their crazy qubit capabilities meaning quantum resistant cryptos are maybe sooner required than we previously thought. I think crypto is exactly the kind of thing that needs to be kept out of a standard library to avoid churn/deprecation.
I’ll leave a top-level comment on it, but aside from having a single “blessed” library, I think consensus on cryptographic trait implementations for backends would be fantastic.
High-level libraries that can be built to consume those traits, low-level implementations that implement them; would lead to easier agility when the “blessed” library is no longer the go-to.
The idea that absorbing something like ring into stdlib would automatically give it new maintainers feels like wishful thinking. Getting maintenance done is a combination of having the required skill (and for crypto, the bar is high) and accepting that it’s not someone else’s problem.
The “someone else’s problem” feeling can be pretty high for code in a stdlib. Whereas here, in the crate ecosystem, when the ring maintainer gave up we got an advisory that prompted new maintainers to step in. Looks like FOSS is working.
I am currently doing an apprenticeship and what I am witnessing is, that there seems to be a change in motivation. Many don’t go into development, because they are curios or eager to learn and understand, but to make money and remote working.
I don’t want to say that this is bad, but just a change I’ve seen
It’s not a change. When I studied computer science, most of my peers were motivated by wanting a high grossing job and did not have a lot of ambition to “go beyond” during studies. That was around 2003.
That’s fine, it’s not a bad attitude, just one that needs to end up at the right place. A lot of them ended up really reliable IT workers that can really accurately do a job by spec, much better than I can.
Some others found their love for hacking later and do really absurd stuff now.
I think a lot of this is that you don’t need to be a hacker (https://en.wikipedia.org/wiki/Hacker_culture not cyber security hacker) to be a good software engineer, just like you don’t have to be a good software engineer to be a hacker. It’s more of a difference in culture rather than any sort of indicator as to job performance in my opinion.
Right, but there was an understanding that only good devs could make a high salary, so the money motivation worked. Today there’s the idea that there’s plenty of work LLM copyists and many people would do it for a living wage.
I’ve been observing that trend for at least five years. Maybe ten, though the interest in remote work has obviously changed. I think it’s due both to the influx of money and the lowering of various barriers to entry. Newcomers no longer have to climb the kinds of learning cliffs only dyed-in-the-wool geeks will attempt.
Very sad. Unfortunately it’s been my experience that FOSS is inextricable from inter-maintainer strife even on very small projects. This is a bit of a wild proposal but I do legitimately think video couples therapy would be helpful for soothing disputes between maintainers. Our field is short on emotional intelligence, magnified by text-only communication and further magnified by cross-cultural reach.
I wish I had the time today to write a longer response, but I fundamentally think this is not true. In all my experience as a team lead of multiple open source orgs, I experienced very much the inverse.
What lacks is, for lack of a better term, some kind of professionalism, but not in the corporate sense. One we (and I’m using the collective “we” carefully here) own. The problem here is particularly this:
magnified by text-only communication and further magnified by cross-cultural reach.
FOSS is the forefront of extremely distributed, loosely coupled organisations with an amazing amount of random touch points to the outside. We literally don’t know how to handle this. This isn’t a lack of intelligence, it’s a lack of templates, advisors, experiences. All management philosophy is built around companies, not around organisations that people stay in over 10 years, switching their employers along the way.
This is a bit of a wild proposal but I do legitimately think video couples therapy would be helpful for soothing disputes between maintainers.
It’s not a wild proposal, it exists.
To anyone reading this and wanting this: I know people who do that and I’m happy to connect. Obviously, they don’t work for free.
It’s not new (and you don’t say it is) - practically for ever there have been organisations whose members had different employers. For example, many (not all) political parties, religions, professional and academic associations. In some cases they have internal cohesiveness and in other cases not. I agree with you that “management philosophy” seems to ignore these structures.
It’s not new (and you don’t say it is) - practically for ever there have been organisations whose members had different employers.
Very much yes, and thanks for clarifying that.
I’m always joking that I learned more for FOSS out of my sports club (which is 200 years old and part of a 7 layer international structure that works to a certain extent) than from management school.
Leadership (likely Linus) needs to step in here and either say “rust is ok” or “rust is not ok.” Otherwise these same rehashed arguments in the LKML will be going over and over again, and nothing gets done except people burning out.
The Rust support was merged in v6.1 into mainline in order to help in determining whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs.
That said, people like GregKH are already convinced that Rust for Linux has been success (I do as well, but I’m just watching from the peanut gallery). But that doesn’t mean that “rust is ok” w/o further discussion. Different developers/maintainers still have to be convinced.
Watching from the outside it seems that some maintainers don’t want to be convinced in the first place.
From personal experience with some of the involved in this thread from the maintainers side, I disagree. It’s unsurprising that, after years and years of holding the kernel as a pure C project for good reasons (not even allowing the sister language C++ in), there’s people that hold this as a value. Those aren’t convinced easily, not on a short timeline and not via email. I know people wish for a strong word from Linus, but this is only partially in his hands - particularly as the person who previously held the “pure C” line.
I’m not a fan the tone, but I was for example completely unsurprised by Chris Hellman holding that line and not arbitrarily.
R4L is not just a substantial engineering effort, it is also a substantial social effort. And that means a ton of legwork, and maybe some beers at a bar.
My naive and oversimplified take on this is that Rust would be allowed, but is expected to have backwards compatibility assurances, and so long as Rust constantly changes things and lacks those assurances, Rust won’t be added.
Is this correct? Somewhat correct? Not really the issue? Incorrect?
As someone who sees Rust getting rebuilt monthly or even more often than monthly because of new versions, and codebases like Firefox (and even Rust itself) that can’t use an ever-so-slightly older version of Rust, I get the impression that Rust has a long way to go before it settles enough to be used for software that has extremely long maintenance cycles. But that’s just my impression - I have no experience actually programming in Rust.
The results of the annual survey have come out, and 90% of users use the current stable version for development. 7.8% use a specific stable released within the past year.
These numbers are only so high because it is such a small hassle to update even large Rust codebases between releases.
Rust is stable in the sense of “is backwards compatible” even if it isn’t in the sense of “doesn’t have a slow release cadence.”
A new version of Rust comes out every 6 weeks. Rust has many so-called unstable features, which are not available by default and have to be opted into. Those features can change at any moment. But if you don’t opt in to such features, the language is extremely stable. Every time a new Rust version is being prepared, they compile and run the test suites of pretty much all known publicly available Rust code, just to make sure nothing went wrong.
Rust for Linux does opt into a few unstable features, but they’re pretty close to being finished and making sure R4L can work without unstable features is a high priority goal for the Rust Project.
Rust has stability guarantees written down and heavily tested since nearly 10 years to particularly allow evolution with very strong backwards guarantees.
Rust (ideally) never breaks backwards compatibility except in a very defined set of cases. (e.g. bugs in the language frontend that allow you to bypass it’s guarantees are bugs, not features and will be fixed, at the cost of breaking some notion of backwards compatibility). It has an extremely heavy hammer test suite to ensure no unwanted changes to go in and/or assess the impact of changes called crater - which literally runs for days. https://github.com/rust-lang/crater?tab=readme-ov-file#crater
Recommendation: before you actually enter discussions about Rusts backwards guarantee (I know you haven’t, this is more for the reader), please read the two RFCs. They are relatively short, subtle and good. I often see discussions going wrong where people haven’t read those docs and have discussions that have no basis in reality.
Being a BSD masochist^Wuser, I generally maintain my own package repo. Firefox is included in that repo. I love having full control over the packages installed on my system. I’m probably an outlier here, though.
well now we’re changing the topic, but one reason is that it removes the need to trust external builds. another would be to patch it e.g. to restore FTP support. another is that it’s a necessary on-ramp to contributing, or generally to exercising the rights granted by the license.
These are all good and valid points. Thanks for sharing :-). I can see how that’s important to you and the latter being really important for both of us.
I don’t think this is correct. Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others. None of this would have to do with the language.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
As for the user spending money or whatever, I have nothing to say on the matter. Are users responsible for purchasing decisions? I don’t know, I don’t think it’s relevant at all.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
what I read is that a lot of the drivers for asahi linux are written in rust. are they not part of the main kernel tree?
They’re in the Rust for Linux tree, but they’re not in Linus’s tree yet, because they’re blocked on other stuff getting merged first (like the DMA abstraction).
is “upstream” synonymous with “the main kernel tree”?
Yes. That is Linus’s tree, which is the ultimate upstream of the Linux project.
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I think so. Most of their C drivers aren’t upstreamed yet either, I believe. The C drivers I don’t think are blocked by anything in particular, it’s just work that isn’t finished yet. The announcement blog post says that they are going to focus on upstreaming this year. The Rust drivers are blocked by needed Rust for Linux abstractions not being upstreamed yet.
is “upstream” synonymous with “the main kernel tree”?
Yeah.
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I’m not sure how much is actually merged, if it is though it’s experimental. I believe much of it is not merged, and it was naturally developed outside of the main tree (as anything would be). The GPU driver, often cited as a big success story for Asahi, is not merged, for example.
Max reply depth reached. Perhaps blog about this and submit it?
(We have a max reply depth for technical reasons. But also, at this depth, previous discussions have always gone off the rails in topic or tone.)
a first?? continuing here…
presumably “experimental” code is more liable to have bugs.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
I think I’ve been misunderstanding what is meant by “behavioral” or “API/ABI” stability. I thought this referred to the stability of the interface between the kernel and userland, and that being “experimental” would mean the external interface is not maintained in the same way as other parts of the kernel. but now I’m thinking that the API/ABI stability is between different components within the kernel, and they want to “experiment” with making those internal interfaces more stable. do I have that right now?
That would be right, at least for the most relevant stuff like the filesystem discussions. It’s ensuring that when something changes on the kernel side (not userland facing) that the Rust code matches that.
ok that helps. so to go back to what kicked off this discussion:
Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others.
so this means that the C kernel devs could change things that break RFL code and aren’t obligated to fix it, whereas if it were any other part of the kernel, the C devs would be obligated to fix it or make sure it gets fixed. right?
That’s about right, although there’s always some shared responsibility between the person changing the API and the callers (in RFL’s case it’s all on the Rust devs).
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
that’s what I was getting at when I said “‘it runs linux’ no longer means it has the stability and longevity that could once be expected.” of course it’s a matter of debate whether the rust effort will yield better or worse stability/longevity, but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
I’m not sure that the reputation argument is going to hold much water with me. Linux has a pretty bad reputation in my mind, but how it’s marketed is completely disconnected from that. I can’t tell you how things should or shouldn’t be marketed, or the complexities of layman making technical purchasing decisions, or how the experimental branch might change things, or what is or is not ethical to say about support for a Mac on Linux. If you want to say that Asahi is somehow wrong for something they’re saying about support or stability, you can do so, I just don’t think it’s relevant to RFL. If you want to see their messaging, this seems to be the relevant page: https://asahilinux.org/about/
but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
Maybe? It’s really hard to say. Many drivers are poorly supported or maintained by far fewer/ less motivated people than Asahi.
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
It’s a bad sign for Linux in general, which, as I’ve stated elsewhere, is not going to be a dominant OS in the future because of upstream’s behavior and fundamental structure. In the short term I think the major impact is going to be that Asahi probably isn’t interested in staying out of tree forever, they likely had loftier goals and wanted this to be a larger project as a part of RFL, and so by upstream pushing RFL away Asahi developers will be pushed away/ fail to gain as much traction. I think this will be bad for Asahi and bad for Linux users, sure.
your answers have been duly noted. I take them as assurance that my original comment wasn’t completely off-base or reliant on a fundamental misunderstanding.
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
There is no separate team. RfL is being done by regular kernel maintainers who happened to pick up an interest in Rust. Pretty much everyone (maybe literally everyone) contributing Rust code to Linux has contributed and continues to contribute C code.
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
(please don’t mistake my use of “completely separate” as implying that there are no developers in both groups or that they are hermetically insulated from each other.)
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
Because the vast majority of Linux maintainers do not know Rust, and therefore this experiment couldn’t be run at all if maintainers of C code were expected to fix Rust code when they make changes. And even if RfL is a complete success and Rust becomes a permanent part of the kernel, most likely there will need to continue to be a collaboration between Linux devs who know Rust and those who don’t, to keep Rust code up to date with changes in C interfaces.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
in general terms it seems like if any of the rust code used by asahi is merged with the main tree, then the stability of asahi linux does depend on the stability of that code.
I’m wondering if we’re talking about stability in the same way? Are you talking about stability in terms of stable behaviors/ API/ ABI? Or do you mean in terms of crashing? The former is what’s being discussed with RFL, not the latter.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
here I was referring to “stability and longevity” in the sense that would be relevant to a casual linux user, who may have come to expect that if a system runs linux it will continue to run linux for a decade or more with fewer crashes and bugs than a proprietary OS.
I am acutely aware that user concerns are conspicuously absent from the RFL discussion.
I don’t really follow your point throughout this. Is your concern that Rust will be less stable in the sense of less reliable or something? Or that Asahi Linux will be? I don’t really know how that’s relevant to RFL or actually anything that’s been brought up, or why you’re bringing it up.
as an uninformed casual linux user, over the past year I have gotten the impression that “linux runs on M1 macs,” and in another life this might have motivated me to buy one. with this news it seems like linux might not run on M1 macs for much longer, or might not gain the eventual reliability that I would normally expect if I hear that linux is getting ported to a platform.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole, as was once implied if linux is said to run on a platform.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole,
Right, so there are a few things here.
With regards to bug fixes/ patching, it is not up to the RFL members at all, it’s up to the Asahi developers, who work downstream. This is totally separate from RFL.
With regards to RFL, completely distinct from Asahi, the issue is not crashing it is behavioral and API stability. As RFL is “experimental” it is up for RFL to maintain interfaces that are up to date and not the C developers who maintain other code. Nothing to do with Asahi or bug fixes etc.
You might be under the impression that the Linux kernel considers stability to be a shared responsibility (ie: “everyone is responsible for bug fixes”) but this is not the case at all. Typically it is one developer maintaining a suite of drivers, a filesystem, etc, and they are the only ones responsible. There isn’t a big difference in reliability between something upstream or downstream, what changes is primarily on the committers side in terms of maintaining patches, others contributing Rust, etc, which is what RFL is about. If one of those solo committers/ maintainers left users would be just as fucked as ever - and this happens.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens? if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens?
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Of course, but why would RFL change anything? The code has a bug or it doesn’t. The issue is things like relying on the behavior of the C driver vs the behavior of the Rust driver, which is why RFL wants to formalize those semantics.
I think we’ll probably start hitting the limits of my knowledge if we get too into the details of why Asahi wants to do one thing or another, RFL has numerous motivations. The tl;dr is that the stability discussed is about ABI/API stability, RFL would help Asahi because it would help them formally adopt the behaviors of the C code (by stating those behaviors vs those behaviors just being assumed by one maintainer), and Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens?
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
point taken.
if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Of course, but why would RFL change anything? The code has a bug or it doesn’t.
presumably “experimental” code is more liable to have bugs.
Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
Right, RFL would presumably help that, which is why they want RFL so that they can go upstream.
presumably “experimental” code is more liable to have bugs.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
Hmmm, I’m not sure what you mean. Asahi relies on the code that it relies on, that’s all. RFL would allow their code to live upstream, and would imply some things that RFL is pushing for like more defined behaviors of existing interfaces. That’s what I’m saying. Asahi will rely on RFL code when their code makes it upstream as “experimental”, otherwise that same code would be downstream but otherwise the same. RFL code won’t necessarily come from Asahi, certainly, anyone is free to try to push their own Rust code to upstream.
the paycheck I had in mind would be biweekly with taxes and benefits taken out.
but even your X/12 idea seems needlessly judgemental and paternalistic, and doesn’t account for savings and fluctuations in income. the average salaried indian makes $200-300 a month; median is probably much less. it would be irresponsible for them to spend that much on a computer?
The normal rules for intra-kernel interfaces are “you can break somebody else’s code, but you have to then fix it”.
But if you break some Rust code, it’s the duty of the Rust for Linux people to fix it.
Unbelievable. I’m more convinced that Google is getting increasingly incompetent rather than being deliberately evil. There isn’t a day where I don’t spot a bug in one of their products. This makes me more skeptical about the SRE principles they spearheaded.
I think the thing with SRE is that there is a process to fix problems. SRE is not a QA department and has never been. SRE is about budgeting errors and spending them to increase development speed or saving them and decreasing development speed.
It’s also about learning from mistakes, so we will follow the postmortem process and see if we can improve our reliability next time or for the next thing.
I’m pretty sure we’re not publishing anything publicly on an issue like this, but there will be something internal.
I mean, I’m not at Google, but I’ve seen a few talks of the SRE marketing tour and it was definitely highlighted that SRE pro-actively works with product teams to avoid errors before they happen.
An under that framing, I would expect “track certificate expiration and rotate early” on the standard checklist, particularly for a device you ship to customers, where patching is not as easy.
Thank you, that’s exactly what I meant.
It’s not like Google employees are happy to introduce bugs because they have a budget, or if they hadn’t followed the SRE principles they’d have zero bugs.
This certificate expiry thing is just an anecdote, but the bugs I notice every day mean that tracking velocity on the same terms as correctness may be fostering a culture that lowers the overall quality. Maybe SRE isn’t even at fault here, but the velocity/correctness has been tuned a bit too far for the past few years. I can only guess.
Ninety days…or what? Both the article and the linked story in the article don’t seem to explain the consequences and I imagine at Apple’s scale, they can afford to blow off quite a bit, especially if they want to avoid setting a precedent that they will easily comply.
Honestly, people said the same thing when the EU demanded Apple allow sideloading and they quite well caved in on that, even if they were a bit rules-lawyering it (and continue to do so).
The 9to5Mac article has something:
That is still on the injunction from November, but I guess that also applies to the current order.
I mean, that’s probably way less than the daily earnings of the iPhone platform (hardware and software), but usually, that increases with ongoing non-compliance.
https://9to5mac.com/2025/03/06/brazilian-court-apple-sideloading-ios/
I am not sure, but I’d suspect if they don’t comply there will be increasingly larger fines.
Not sure I see this in such a rose-tinted way. The linked ‘bug report’ is full of people specifying very exact ways that they want to be warned beforehand: I want a blog post, the post has to be dedicated specifically to this one thing, I don’t read Reddit, the tool itself should loudly warn me several months in advance.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
Nothing is perfect for sure. There were some more spicy commentary on this on social media, for example. But, it’s all about the overall ratio, and the outcome.
I both agree and disagree. I think it’s normal in bug reports to report the bug, and wait for a decision to be made, before offering help. I’m sure that if they asked for help, they would have gotten it. There’s actually a pretty high degree of social cohesion here, which may not be obvious to outsiders, but I recognize virtually all of the names on that ticket, and so like, I think it’s sort of understood that if active help was desired, all you have to do is ask. The original reporter is on the language team, for example.
The Rust Project has long described their output as a product. There’s pros and cons to this, but it’s been the norm for at least 12 years now. I do attribute that style of thinking to be one of the reasons why Rust has been successful.
As an ex-lead of the Rust project: I don’t think the Rust project needs more volunteers all the time. It has capacity for fixes, so just stating problems is fine. A lot of people in the discussion are also people who contribute to Rust at other places, by writing libraries, etc.
I think treating a tool as a product of some kind is an important part of ensuring it delivers value to users. There are several things this mindset implies, such as having a product vision rather than just exposing your internals and calling it a day.
So it is okay to write such long annotations to one’s own postings? Okay, I will do so next time :)
I think it’s not about yours/other’s, but rather the fact that this is a link to raw source code, not to a blog post about the source code.
That is, you shouldn’t contextualize something which already explains itself, but, if you are linking to a primary artifact, some explanation is in order!
I think this is mistagged, it should be in the “show” category, where it is common to actually write a contextualising comment.
My father worked for Guinness for about 25 years. When I was growing up we had prints of the John Ireland calendar “the gentle art of making Guinness”, a splendid series of cartoons in the tradition of Heath Robinson or Rube Goldberg. Guinness advertising art was great.
But, it’s a mass-produced factory beer. I occasionally like a stout or other dark beer, but Guinness is boring.
Guinness was relatively early in the use of statistical quality control over large scale biochemical processes – that is where Student’s t-distribution was discovered.
I visited a brewery for one of the top 5 beer producers worldwide and the effort and care going into producing a consistent, safe product is impressive. The fact that the product itself is rather bland and boring is incidental :D
I like boring beer. Incoming long defense of Guinness:
I didn’t always used to be like, I used to like hoppy IPAs. But as I’ve gotten older my desire to drink beers higher than 5% has diminished so thoroughly that I can count the number of times I drink one per year on one hand.
I certainly would like to drink more complex stouts, but there are barely any brewed in America with the same ABV. For an example, I went to my favorite local brewery’s website, and Stout was always prefixed with imperial https://grimmales.com/menu/
I can’t drink these! They taste like syrup and instantly give me a headache.
Frankly, my go to beer these days is Asahi. I’m tired of complexity. Beer is less for me about complex flavors and more about refreshment and the desire to relax. In the cases when I want something more complex, I go for a cocktail. I make myself a Negroni or a Campari soda (depending on which side of refreshment and flavor I want).
Anyway. I love Guinness. It tastes good (that is to say it doesn’t taste like piss water), has a low ABV, and is served in basically every bar in Manhattan and Brooklyn. It fits my need
Thanks for saying that. I like it fine if it’s what’s available, but it tastes watered down to me compared to other stouts I’ve grown accustomed to. I’ll take it over something lighter, but it’s fairly plain.
Completely agree about the watered down flavor. The Extra Stout, however, is quite tasty…
If you’re in the US, be aware that the Guinness product sold as Extra Stout 20 years ago is now known as Foreign Extra Stout. Today’s Extra Stout is watered down in comparison (and undoubtedly cheaper to produce).
As bait-and-switches go, this is mild compared to Newcastle Ale…
I still find it funny, that the main UK production plant for Newcastle Brown Ale is on Sunderland.
That was a notorious bit of management fuckery https://en.wikipedia.org/wiki/Geographical_indications_and_traditional_specialities_in_the_European_Union#Within_the_European_Union
I’m with you but would add that it genuinely does taste better in Ireland! To the point that I know some Irish people who will not drink Guinness abroad.
The story goes that this is due to the water but I suspect the truth is that Guinness have a lot of control over how it’s stored and served in pubs (temperature etc). Whether that should matter is an exercise left to personal taste.
I hope to put that theory to the test one day!
I had an Irish colleague in France that spun the theory that French Guiness is a lot less bitter, because locals don’t like it.
He refused it.
My personal take on Guiness: I rarely drink and then I only rarely drink Guiness, so I enjoy it as an easy stout that comes with an expected taste. Sometimes, that’s just what I want.
(Fun fact about me: I do, however, have a taste for alcohol, my first job was sysadmin on a wineyard)
When I visited the Guinness Storehouse in Dublin the advertising floor was definitely the most interesting part. The rest was over the top displays or sections for social media tourism. I have to agree about it being boring, although I’ll often order it if there’s no other stout or porters served.
Nothing wrong with mass-produced factory beer. Writing this from Germany and I’m always up for a good Maß of Augustiner.
Also, their book of world records was endlessly entertaining when I was in primary school.
Many years after I tried Guinness (which I still occasionally enjoy, because it is boring in quite a pleasant way) I learned that the thing I really liked about it was that it was always a nitro pour. Seeking out interesting beers (mostly, but not all stouts) served on nitro taps has been fun.
I had never made the connection between the beer and the books before. Thanks!
You should also try nitro (cold brew) coffee. It has that same silky mouthfeel and bitterness. Plus, you can drink it any time of day guilt-free :)
I’m a big fan of nitro coffee! In the before times, I worked once or twice a week in an office that had a nitro cold brew tap in the kitchen, and that was enough to make me look forward to those office days. Come to think of it, everyone (of those who didn’t dislike coffee in general) really loved that perk.
Don’t event need cargo,
rustc --versionwill pwn you: https://github.com/jonas-schievink/malloryThis is caused by
rustup, which shimscargo,rustc, etc to redirect to the required toolchain. Which is usually controlled by the user but a rust-toolchain file allows the directory to override it, which in turn can cause automatic installing of new toolchains without user involvement.Funnily enough, implicit toolchain install was removed in rustup 1.28.0 but there was a big outcry about it so it’s being restored by default. Maybe a less invasive change would be an easier pill to swallow (e.g. only official toolchains are installed implicitly).
It’s not related to toolchain installs, just to path overrides, but otherwise yeah, this is how it works.
This is a nice illustration of how errors arise out of combinations of known-good and tested products working by spec.
Welcome to STPA ;)
Is it really an error or just the classic issue that some people want safety and other people want the convenience of being able to do whatever they want (e.g. arbitrary code execution)?
I mean, the STPA is basically the observation you make, taken to the extreme: systems of “good” components have emergent behaviour that may or may not be seen as an error. For that reason, e.g. it does model humans in the loop as important, because they can make these judgement call.
Are there any actual lawyers here who could weigh in?
I’ve largely given up on techies correctly interpreting legalese.
The Mozilla lawyers say that CCPA and GDPR are not court-tested enough and they are making the ToU so broad such that the terms can prevent a lot of legal attacks. As someone who works for Mozilla, I have decided to trust them. But I can understand some people want to do their own reading….
¯\_(ツ)_/¯It must be stressful working for Mozilla and constantly being held to a higher standard.
Despite holding a pitchfork and having lost all faith in Mozilla’s leadership, I have nothing but respect for the people who have made Firefox a viable browser alternative for so long. Sorry you have to deal with this shit :/
Thank you. It would be a more realistic high standard if people contributed instead of complaining.
Filing bugs, finding duplicates, writing docs, everything counts. Not everyone has the necessary level of masochism to deal with a 20 year old C++/Rust/XHTML/CSS/JS codebase and that’s OK.
Heh, it’s not really masochistic if you just focus on an area that’s fairly isolated (for me it was platform stuff: kinetic scrolling for GTK, damage tracking for EGL, gamepad support with evdev, a couple little Wayland bugs, enabling stuff on FreeBSD…) – and what’s really amazing is the tooling, even just the fact that the build is literally just
./mach buildand doesn’t take outrageous amounts of time nor memory (well, without LTO).I mean, those terms are written for customers, who have to accept them, who are neither lawyers nor Mozilla employees. Legal writing for lawyers but for users to accept is malpractice.
It’s definitely a change in habit. I worked with Mozilla Legal around the GDPR compliance and documentation of crates.io and around the setup around the Foundation and they were very outside focused. Really loved it.
What I did find however is the classic that Mozilla is - curiously - very Californian, and not very international in their management and thinking. Peak of this was me observing someone trying to apply US case law to Germany, which doesn’t have case law.
All that said: I do trust Mozilla, but that’s because I have a privileged inside view through my work on Rust and in Tech Speakers and that can’t be what’s being asked of general users.
HOWEVER, I think it’s also the obligation of people criticizing to not spin the wildest legal theories. FOSS has a lot of armchair lawyers that can’t tell even tell personal information and copyrightable works apart.
Fair point. I can agree that this has been blundered in a variety of ways and I’m sorry that it appalled so, so many people.
Rustdoc, like a lot of tooling in Rust was actually significant step up from what other languages had when it was being created (pre 1.0). In 2025, after years of using it the novelty and amazement wore off and is a distant memory.
My favorite aspect of it immediately was that it was unobtrusive. I could just write stupid Markdown after three slashes and get decently looking automatically generated API documentation. Seems … basic and obvious, now, but in 2014 it was mind blowing how simple and convenient it is, when Java or C++ would requires some
@docor whatever obnoxious and tedious syntax.Now, I really love Rust, and I love Rustdoc, but since me and most posters will keep praising it I will specifically focus on the negative side (cuz I’m Slavic, and complaining is our hobby).
The way inline documentation tests are handled (which is and even more so was when introduced an amazing idea), is kind of limited and inconvenient. You need to execute them with special syntax, fixing them is weird because tooling reports them weirdly, at least my text editor (Helix) can’t recognize them as nested Rust code.
LSP does not highlight broken links in documentation. If there’s a way to enable it, I’d love to know, and it really should be the default. After refactoring, I often have to run rustdoc and fix up all the links “manually”.
Integrating with larger documentation could be better. In our project we generate and publish (from the CI) rustdoc documentation with some embedded extra documentation, turning it all into kind of a mdbook. It works, but is limited and required quite a bit of hacking things together. Basically even customizing the landing page is an unstable feature, IIRC. I feel like rustdoc is so good at getting api documentation, that it makes sense to “embed it” into other, larger bodies of documentation in serious larger projects, and it would be easier if it exposed more hooks to tie into.
If this is a comment about rust-analyzer: I can find a few open and closed issues about intra-links support in r-a, but nothing that quite describes that. Could you file a bug?
One thing I’m wondering about for pigweed.dev is how good these docs tests work in an embedded Rust context. E.g. some of our code examples are intended to be run on physical RP2350s. Is there a mechanism to cross-compile for the RP2350 and then actually run the docs tests on physical RP2350s as hardware-in-the-loop tests? Based on this comment it sounds like
rustcandrustdocmay have no problem with this, but I could also imagine it being quite a can of worms to get working correctly.Yes, considering all the craftsmanship in the rest of
rustdocI’m surprised that it has overlooked this core, easily verifiable aspect of docs quality!Tangentially related, does
rustdochave cross-reference syntactic sugar like Sphinx/reStructuredText? E.g. I can create a section with an ID like this:And then in other docs to link to this section all I need to do is:
And at “compile-time” it gets rendered as:
Definitely know this struggle! I need to figure out how to unify Pigweed’s auto-generated Python, C++, and Rust references with the rest of the site in a consistent manner.
You could make it work, but I believe it doesn’t work OOB. IIRC, the test harness (a program that the test framework generates that calls the test functions) requires
std, so you are out of luck on platforms that do not havestd.There’s a few projects out there for this kind of stuff (I think there’s no difference between doctests and regular tests here that matters), but we haven’t found yet anything that ticks our boxes. Embassy is using teleprobe, and if you start to survey the major Rust embedded projects you’ll find a few more, but I don’t think there’s any ready to consume in a nice way yet.
Okay, rustdoc is actually the reason I came to Rust about 12 years ago. I joined at about 0.4. All that I’m writing about, exists roughly since then. Because rustdoc is a tool built by people who understood what can be useful for programming in the real, not in the abstract. Also, I won’t repeat @ssokolow.
On the surface, it’s a documentation generator like any other, with a reasonably nice HTML template (it comes out of browser vendor after all), which is very readable. They have an eye on how docs are consumed. It’s built for deep-linking in all aspects - want to link to a function? Sure. A header in one of the comments? Sure. Line of code in the underlying source code? No problem. It follows the rules of a good document.
It goes the extra mile by trying to make some of the weirder bits of Rust more accessible. A lot of functions that can be called on String are not from String, but from &str through Rust dereference. Of course, there’s a header called Methods from Deref<Target = str> that still lists them all in String. A return type is more a value that is returned because of the traits (think interfaces) it implements? There’s a small (I) next to it to tell you on hover and so on.
Before I go into those features, a little nerdery at first: rustdoc and rustc are intertwined in the sense that rustc is predominantly a library with multiple binaries on top, one of them is the compiler, one of them a linter (clippy) and one of them rustdoc. That means rustdoc always sees everything the compiler sees and is always built with the compiler. That means it can resolve connections between types properly, etc, etc. You can see a status of tools working over rustc nightly here: https://rust-lang.github.io/rustup-components-history/
Another interesting thing to know is that Rust comments are actually understood by the compiler much more than in other languages. They are not just commented out lines.
Something like:
is the same as
Docs in Rust are attributes of the thing they document, so they can be picked up through the AST. That means that rustdoc always has a very clear view what a comment belongs to.
What I’m getting at: documentation in Rust is much more a first-class citizen since about forever than you may realise.
That leads to a number of interesting features.
Rustdoc, since forever, e.g. has the ability to parse comments from your documentation and run them as code. If a code example is marked as rust code (```rust), rustdoc can extract it, compile it in the context of the library and run it as a test. This can be controlled, e.g. you can also tell it to compile the code, not run it (e.g. if it’s an example that starts a server and never returns) or even that the example should fail. rustdoc is more than a renderer.
That leads to a culture where Rust documentation examples are often very correct. Particularly all the stdlib examples are run through that process.
The second interesting thing is that rustdoc actually nowadays can be used to output a JSON dump of its data that holds enough meta data to write an extremely good semver checker in it (https://crates.io/crates/cargo-semver-checks).
I really like that it stuck to its guns and uses Markdown a text flavour. That’s a great choice, because, while Markdown lacks certain features one may want (I love rst as well), it is: very low bar, well understood and the right thing for writing a quick documentation comment.
I’m actually not a huge fan of the search function. It’s good, much better things are possible. I used to be a search engineer though, I appreciate that this is hard work that may bot be worth it in the end.
I think rustdoc is not cool because it’s in any way fancy. rustdoc is cool because it’s your reliable worked doing all the annoying work to do docs in good detail for you.
Just a note: As with non-lexical lifetimes, this is a feature that wasn’t present in Rust v1.0, felt like it took far too long to arrive for us old-timers, and now feels so natural that you’d never imagine it wasn’t there from the start.
Originally, you just had to generate the docs, see what the URL would be, and then reference it as an ordinary relative hyperlink.
I think you’re both saying different things. @skade was saying the anchors in the HTML were there from a very long time. You were saying the ability for rustdoc to compute and insert the link to a symbol is relatively more recent.
I don’t remember when the second ability was added but I remember reading it in release notes and being surprised it wasn’t possible yet! I’m pretty sure it had a nice dedicated section to highlight it.
EDIT: it was in Rust 1.48, released Nov. 19, 2020.
This is correct, I talked about deep-linking (linking into any aspect of the document), not intra-doc-links, which indeed came late and were missed.
Thanks, this is exactly the kind of “in-depth info from people who have worked extensively with the tool for a long time” that I was looking for.
Fascinating, did not know this. Do Doxygen and Javadoc not do this? I suppose the main difference is perhaps that Doxygen and Javadoc need to do their own work a lot more to associate the comments with the code, whereas in Rust the compiler itself is doing all that work by default.
Does this mean that it would be feasible to write a library like Breathe but for Rust? As commented here I’m pretty sure it’s not actually a good idea. Just curious if it’s possible. One thing I am very interested in, however, is whether it’s possible to pull in rustdoc metadata to improve Sphinx’s built-in, client-side search. E.g. when you go to pigweed.dev and press
Ctrl+Kto open the in-site search, ideally you can search by Rust type signatures from that UI.Would love to hear more about this.
Yes, it’s entirely up to the doc tool. This is what the Java Specification has to say about Comments:
https://docs.oracle.com/javase/specs/jls/se11/html/jls-3.html#jls-3.7
This is what the Rust/Ferrocene spec has to say about comments. This goes very much into details about what a comment applies to and how it is transformed on a language level.
https://spec.ferrocene.dev/lexical-elements.html#comments
rustdoc is just the agent that collects those things and puts them into nicer form.
Yes, though the format is unstable and may break between versions (it is indeed behind a barrier so that people are aware of the unstableness). But yes, you could totally use it.
It’s very much “left to right”. So e.g. if I search for “Vec Push”, i find something, if i find “push vec”, I do not. I would really love be able to search for return values that implement a certain trait, etc. etc.
Can you at least give a small indicator of what you need the answer for? Improving rustdoc, assessing rustdoc, writing a new tool inspired by rustdoc? That would really help me answer.
Sorry if it was too vague. I was trying to be neutral and not steer the conversation in any particular direction.
My main goal is simply that I want to make my fellow technical writers (TWs) more aware of Rust’s approach to auto-generated docs. TWs at large have some familiarity with how it’s done in any other languages (Doxygen for C++, Javadoc for Java, autodoc for Python, etc.) but I have a hunch that they’re not as aware of Rust’s approach. I’ve dabbled with
rustdocbut would like to hear more from people who have extensively worked with it, and especially how it stacks up to how it’s done in other languages. I will eventually probably write blog posts on https://technicalwriting.dev comparing/contrasting how different languages approach auto-generated docs. E.g. I know that being able to search by type signatures is a particularly beloved feature ofrustdocand I have a hunch that a lot of TWs aren’t aware that SWEs often heavily use this search strategy.Oh, it’s this again.
So, look. Every single internet-connected thing that involves anything that could even be considered user-generated content, and has lawyers, sooner or later inserts a clause into its terms saying you grant them a royalty-free, non-exclusive, non-revocable (etc. etc.) license to copy and distribute things you, the user, input into it.
This is like the most standard boilerplate-y clause there is for user-generated content. It’s a basic cover-your-ass to prevent someone suing you for copyright violation because, say, they just found out that when you type something in the built-in search box it makes a copy (Illegal! I’ll sue!) and transmits the copy (Illegal! I’ll sue!) to a third party.
But about every six months someone notices once of these clauses, misinterprets it, and runs around panicking and screaming OH MY GOD THEY CLAIM COPYRIGHT OVER EVERYTHING EVERYONE DOES WHY WOULD THEY NEED THAT PANIC PANIC PANIC PANIC PANIC OUTRAGE OUTRAGE PANIC.
And then it sweeps through the internet with huge highly-upvoted threads full of angry comments from people who have absolutely no clue what the terms actually mean but who know from the tone of discussion that they’re supposed to be outraged about it.
After a few days it blows over, but then about six months later someone notices once of these clauses, misinterprets it, and runs around panicking and screaming OH MY GOD THEY CLAIM COPYRIGHT OVER EVERYTHING EVERYONE DOES WHY WOULD THEY NEED THAT PANIC PANIC PANIC PANIC PANIC OUTRAGE OUTRAGE PANIC.
And then…
@pushcx this should not be allowed on lobste.rs. It’s 100% outrage-mob baiting.
Saying that everyone else does it does not make it okay. Are there court cases or articles describing the limits you say are implicit?
If you are as right as you think you are, then you could be educating instead of complaining to moderators.
That’s the point. GDPR has not been that well tested in court. As long as it hasn’t, people will stick to legal boilerplate to make it as broad as possible. This is why all terms of services look like copypasta.
Putting words in my mouth doesn’t make a counterargument.
What do you think is not OK about this boilerplate CYA clause? Computers by their nature promiscuously copy data. Online systems copy and transmit it. The legal world has settled on clauses like this as an alternative to popping up a request for license every time you type into an online form or upload a file, because even if nobody ever actually would sue they don’t want to trust to that and want an assurance that if someone sues that person will lose, quickly. They’ve settled on this because copy/pasting a standard clause to minimize risk is a win from their perspective.
Why is this evil and bad and wrong from your perspective? Provide evidence.
The system we currently have may be structured in a way which makes clauses like this necessary or expedient in order to do business, but the validity of such a clause for that reason doesn’t excuse the system that created it.
But Firefox isn’t a web service. It’s a program that runs on my computer and sends data to websites I choose to visit. Those websites may need such legal language for user generated content, but why does Mozilla need a license to copy anything I type into Firefox?
This. I’ve chatted with a few lawyers in the space and this is literally the first time we’re seeing that interpretation to apply to a local program you choose to run that is your agent.
Firefox integrates with things that are not purely your “local agent”, including online services and things not owned by Mozilla. And before you decide this means some sort of sinister data-stealing data-selling privacy violation, go back and look at my original example.
So clearly rejecting their TOS should just toggle off all of those services, right?
None of these are activities falling under copyright, so a license is meaningless.
The list of data subprocessors is short and well documented: https://support.mozilla.org/en-US/kb/firefox-subprocessor-list
So it also can’t be an issue of “let’s be blanket because we can’t give you the list”.
The Python Package Index has almost exactly the same clause in its terms of service for things you voluntarily choose to send to them.
I guess their legal advisers are just bad or something. Maybe you could go see about getting hired to replace them.
When you upload something to the python package index you do so because you intend for the python package index to create copies of it and distribute it, which needs a license.
When you make a comment on pull request for work you don’t intend for Mozilla to have anything to do with that. You don’t intend for Mozilla to receive your post. Nor to have any special rights to view it, distribute it, make copies of it, etc. They do not need a license because they shouldn’t be seeing it. Moreover you don’t even necessarily have the right to grant them said rights - someone else might own the copyright to the material you are legitimately working with.
These scenarios are not even remotely similar.
If you use their integrated search which might send things you type to a third party, Mozilla needs your permission to do that.
If you use their Pocket service which can offer recommendations of articles you might like, Mozilla needs your permission to analyze things you’ve done, which may require things like making copies of data.
If you use their VPN service you’re passing a lot of stuff through their servers to be transmitted onward.
There’s a ton of stuff Mozilla does that could potentially be affected by copyright issues with user-generated/user-submitted content. So they have the standard boilerplate “you let us do the things with that content that are necessary to support the features you’re using” CYA clause.
More specifically, their recommendations are at odds with the interests of users.
The question for random people reading these clauses is what does that mean? Legalese can be hard for lawyers to understand. It’s much harder for mere mortals.
I think everyone is OK with Firefox (the browser) processing text which you enter it into. This processing includes uploading the text to web sites (which you ask it to, when you ask it to), etc.
What is much more concerning for the average user is believing that the “ royalty-free, non-exclusive, non-revocable (etc. etc.) license” is unrestricted.
Let’s say I write the worlds most beautiful poem, and then submit it to an online poem contest via FireFox. Will Mozilla then go “ha ha! Firefox made a copy, and uploaded it to the Mozilla servers. We’re publishing our own book of your work, without paying you royalties. And oh, by the way, you also used Firefox to upload intimate pictures of you and your spouse to a web site, so we’re going to publish those, too!”
The average person doesn’t know. Reading the legalese doesn’t help them, because legalese is written in legalese (an English-adjacent language which isn’t colloquial English). Legalese exists because lawsuits live and die based on minutiae such as the Oxford Comma. So for Mozillas protection, they need it, but these needs are in conflict with the users need to understand the notices.
The Mozilla blog doesn’t help, because the italicized text at the top says: It does NOT give us ownership of your data or a right to use it for anything other than what is described in the Privacy Notice
OK, what does the Privacy Notice say?
(your) …data stays on your device and is not sent to Mozilla’s servers unless it says otherwise in this Notice
Which doesn’t help. So now the average person has to read pages of legal gobbledygook. And buried in it is the helpful
Identifying, investigating and addressing potential fraudulent activities,
Which is a huge loophole. “We don’t know what’s potentially fraudulent, so we just take all of the data you give to FireFox, upload to our US-based servers, and give the DoJ / FBI access to it all without a warrant”. A lawyer could make a convincing and possibly winning argument that such use-cases are covered.
The psychological reason for being upset is that they are confused by complicated things which affect them personally, which they don’t understand, and which they have no control over. You can’t address that panic by telling them “don’t panic”.
Could you explain why the concern is necessarily born of confusion rather than accurate understanding?
I didn’t say the concern is necessarily born of confusion. I said that the concern was because they didn’t understand the issues.
you said the reason for being upset is that they are confused. sorry if I was changing your meaning by adding “necessarily.” why do you say the concern is because of confusion or lack of understanding? what understanding would alleviate the concerns?
I don’t see a lot of difference between confusion and lack of understanding. Their upset is because the subject affects them, and they’re confused about it / don’t understand it, and they have no control over it.
This is entirely normal and expected. Simply being confused isn’t enough.
What would alleviate the concerns is to address all three issues, either singly, or jointly. If people don’t use Firefox, then it doesn’t affect them, and they’re not upset. If they understand what’s going on and make informed decisions, then they’re not upset. And then if they can make informed decisions, they have control over the situation, and they’re not upset.
The solution is a clear message from Mozilla. However, for reasons I noted above, Mozilla has to write their policies in legalese, when then makes it extremely difficult for anyone to understand them.
but who does “they” refer to? are you saying this describes people in general who are concerned about the policy, or are you just supposing that there must be someone somewhere for whom it is true?
what about people who have an accurate layman’s understanding of what the policy means, and are nonetheless concerned?
The actual reason for them being upset is that someone told them to be afraid of the supposedly scary thing and told them a pack of lies about what the supposedly scary thing meant.
I propose to deal with that at the source: cut off the outrage-baiting posts that start the whole sordid cycle. Having a thread full of panicked lies at the top of the front page is bad and can be prevented.
And if you really want to comfort the frightened people and resolve their confusion, you should be talking to them, shouldn’t you? The fact that your pushback is against the person debunking the fearmongering says a lot.
i.e. you completely ignored my long and reasoned explanation as to why people are upset.
Alternatively, you could look at the comment above in https://lobste.rs/s/de2ab1/firefox_adds_terms_use#c_yws3nv, which explains clearly just how nefarious and far-reaching the new policy is.
I haven’t seen you debunk anything. In order to “debunk” my argument, you would have to address it. Instead, you simply re-stated your position.
I explained why your position wasn’t convincing. If you’re not going to address those arguments, I don’t need to respond to your “debunking”.
At best that comment points out that a consolidated TOS for Mozilla “services” is confusingly being linked for the browser itself. Nothing has been proven in the slightest about it being “nefarious”, and the fact that you just assert malicious intent as the default assumption is deeply problematic.
So your position is completely unconvincing and I feel no need to address it any further.
But you’re not debunking the fear mongering. You’re conspicuously ignoring any comment that explains why the concern is valid. Don’t hapless readers deserve your protection from such disinformation?
You’re largely describing boilerplate for web services, where the expectation is that users input content, and a service uses that content to provide service.
Firefox is a user agent, where the expectation is that users input content and the agent passes that content through to the intended service or resource.
You can call this boilerplate if you like, but it certainly gives Mozilla unambiguous rights relative to what you put into it.
This really does beg the question: Firefox is 20 years old. Why did they only feel the need to add this extremely standard boilerplate-y clause now?
Their lawyers won the debate this time.
why though?
what exactly does that mean? Were they already actively doing this, and the lawyers “won” by updating the TOS to cover that behavior? Or did the lawyers “win” because they were pushing for a business decision to change Firefox’s data gathering activities?
Please, If you could reflect for a moment on your own comment that you have written could you determine if comes off as outraged?
I am incredibly tired of this sort of thing sparking ignorant outrage on a regular basis. It should not be permitted on this site.
There’s a “hide” button just for you. You can be the ninth lobster to click it!
This post is
Many much more mild examples have been removed on this site without hesitation. This one has to be, too, if the site rules mean anything.
I disagree. I think this is actionable, relevant, and very on-topic. I’d even argue about that with you here, except that you in particular have a very solid history of bad-faith arguing, and I have better things to do.
Anyway, so far 84 of us have upvoted it, vs 7 “off-topic” flags and 8 hides, for a ratio of about 5:1, if we care about user opinions. Your paternalism isn’t a good look. Just hide it, flag it, and move on!
I will note that we have both a
privacytag andlawtag, which are explicit carveouts for this sort of content.Now, whether or not we should retire those or not is a bigger question.
We already know the site rules don’t mean anything. The same rules are regularly violated for Apple marketing presentations.
What would a post that is not meant to whip up outrage look like? Presumably the blog author did their best to write such a post.
I wouldn’t say that the site rules don’t mean anything–I would say that many users and even admins have disregarded them for political expediency.
The long-term effects of this, of course, are deleterious…but that doesn’t matter when gosh darnit, the outgroup is wrong right now.
In the case of Apple, there’s a weird sort of thing where a
releasetag covers what is technically marketing. They also are both a large software and hardware vendor and, like it or not, have a large userbase. I’m not saying we should see a constant dripfeed of Apple propaganda, but it isn’t entirely without precedent.Of course. I adopted the parent comment’s hyperbole to avoid getting bogged down in minutia. But there’s nothing wrong with more clarity and precision.
then don’t express the ignorant outrage?
I’m really surprised to see anyone pay even the slightest of attention to this on Lobsters. It’s something my granddad would post to Facebook (example)
Such an ad-hominem argument is something my grandma would post on Instagram.
It’s not an ad hominem. I’m not attacking anyone instead of their argument.
Hm, this is relatively rough, but I’ll take it.
I see a classic issue though. There’s a grey area between:
(Top of the paper)
and
particularly
(End of the paper)
This sounds like at least introducing a kind of dialect into the language that you need to follow. While it is true that C has all the features to make this happen without a lot of changes: this is a different dialect that people need to learn and that codebases need to be ported to.
New rulesets, while theoretically compatible, can create something that is essentially the same as introducing breakages and new syntax.
This is a substantial effort at scale and may trigger the question “well, why not a rewrite in Rust and link it in?”.
However, such questions are useful to raise actively, because the decision may be a recommitting to C and its improvement.
I’m surprised there’s nothing about smartphones and “everyone needs an app” on here.
Good point, tablets might also go in the “minor” category.
I would like to represent the delegation of broke people in their 20s whose tech salaries are efficiently absorbed by their student loans:
You don’t need a smart bed. My mattress cost $200 and my bedframe cost <50. I sleep fine. I know as people age they need more back support but you do NOT need this. $250 worth of bed is FINE. You will survive!!
I’m not sure I agree. Like if you are living paycheck-to-paycheck then yeah, probably don’t drop $2k on a mattress. But I believe pretty strongly in spending good money on things you use every day.
The way it was explained to me that aligned with my frugal-by-nature mindset was basically an amortization argument. You (hopefully) use a bed every single day. So even if you only keep your bed for a single year (maybe these newfangled cloud-powered beds will also have planned obsolescence built-in, but the beds I know of should last at least a decade), that’s like 5 bucks a day. Which is like, a coffee or something in this economy. I know my colleagues and I will sometimes take an extra coffee break some days, which could be a get up and walk break instead.
You might be young now, but in your situation I would rather save for my old age than borrow against my youth. And for what it’s worth I have friends in their 20s with back problems.
(of course, do your own research to figure out what sort of benefits a mattress will give to your sleep, back, etc. my point is more that even if the perceived benefits feel minimal, so too do the costs when you consider the usage you get)
Mattresses are known to have a rather high markup, and the salesmen have honed the arguments you just re-iterated to perfection. There are plenty of items I’ve used nearly daily for a decade or more. Cutlery, pots, my wallet, certain bags, my bike, etc. None of them cost anywhere near $2000. Yes, amortized on a daily basis, their cost comes to pennies, which is why life is affordable.
Yes, there are bad mattresses that will exacerbate bad sleep and back problems. I’ve slept on some of them. When you have one of those, you’ll feel it. If you wake up rested, without pains or muscle aches in the morning, you’re fine.
I too lament that there are things we buy which have unreasonable markups, possibly without any benefits from the markups at all. I guess my point is more that I believe – for the important things in life – erring on the side of “too much” is fine. I personally have not been grifted by a $2k temperature-controlled mattress, but if it legitimately helped my sleep I wouldn’t feel bad about the spend. So long as I’m not buying one every month.
I think one point you’re glossing over is that sometimes you have to pay an ignorance tax. I know about PCs, so I can tell you that the RGB tower with gaming branding plastered all over it is a grift [1]. And I know enough about the purpose my kitchen knife serves to know that while it looks cool, the most that the $1k chef’s knife could get me is faster and more cleanly cut veggies [2].
You sound confident in your understanding of mattresses, and that’s a confidence I don’t know if I share. But if I think of a field I am confident in, like buying PCs, I would rather end the guy who buys the overly marked-up PC that works well for him than the one who walks a way with a steal that doesn’t meet his needs. Obviously we want to always live in the sweet spot of matching spend to necessity, but I don’t know if it’s always so easy.
[1] except for when companies are unloading their old stock and it’s actually cheap.
[2] but maybe, amortized, that is worth it to you. I won’t pretend to always be making the right decisions.
Note, because it’s not super obvious from the article: the $2k (or up to about 5k EUR for the newest version) is only the temperature-control, the mattress is extra.
All that said: having suffered from severe sleep issues for a stretch of years, I can totally understand how any amount of thousands feels like a steal to make them go away.
One of the big virtues of the age of the internet is that you can pay your ignorance tax with a few hours of research.
In any case, framing it as ‘$5 a day’ doesn’t make it seem like a lot until you calculate your daily take-home pay. For most people, $5 is like 10% of their daily income. You can probably afford being ignorant about a few purchases, but not about all of them.
Maybe I would have agreed with you five years ago, but I don’t feel the same way today. Even for simple factual things I feel like the amount of misinformation and slop has gone up, much less things for which we don’t have straight answers.
Your point is valid. I agree that we can’t 5-bucks-of-coffee-a-day away every purchase we make. Hopefully the ignorance tax we pay is much less than 10% of our daily income.
I think smart features and good quality are completely separate issues. When I was young, I also had a cheap bed, cheap keyboard, cheap desk, cheap chair, etc. Now that I’m older, I kinda regret that I didn’t get better stuff at a younger age (though I couldn’t really afford it, junior/medior Dutch/German IT jobs don’t pay that well + also a sizable student loan). More ergonomic is better long-term and generally more expensive.
Smart features on the other hand, are totally useless. But unfortunately, they go together a bit. E.g. a lot of good Miele washing machines (which do last longer if you look at statistics of repair shops) or things like the non-basic Oral-B toothbrushes have Bluetooth smart features. We just ignore them, but I’d rather have these otherwise good products without she smart crap.
Also, while I’m on a soapbox – Smart TVs are the worst thing to happen. I have my own streaming box, thank you. Many of them make screenshots to spy on you (the samba.tv crap, etc).
Yes, absolutely! Although it would be cool to be able to run a mainline kernel and some sort of Kodi, cutting all the crap…
I guess you never experienced a period with serious insomnia. It can make you desperate. Your whole life falls in to shambles, you’ll become a complete wreck, and you can’t resolve the problem while everybody else around seems to be able to just go to bed, close their eyes and sleep.
There is so much more to sleep than whether your mattress can support your back. While I don’t think I would ever buy such a ludicrous product, I have sympathy for the people who try this out of sheer desperation. At the end of the day, having Jeff Bezos in your bed and some sleep is actually better than having no sleep at all.
You make some good points why this kind of product shouldn’t exist and anything but a standard mattress should be a matter of medical professionals and sleep studies. When people are delirious from a lack of sleep and desperate, these options shouldn’t be there to take advantage of them. I’m surprised at the crazy number of mattress stores out there in the age of really-very-good sub-$1,000 mattresses you can have delivered to your door. I think we could do more to protect people from their worn out selves.
None of the old people in my family feel the need for an internet connected bed (that stops working during an internet or power outage). Also, I imagine that knowing you are being spied on in your sleep by some creepy amoral tech company does not improve sleep quality.
I do know that creepy amoral tech companies collect tons of personal data so that they can monetize it on the market (grey or otherwise). Knowing that you didn’t use your bed last night would be valuable information for some grey market data consumers I imagine. This seems like a ripe opportunity for organized crime to coordinate house breakins using an app.
I believe the people who buy this want to basically experience the most technological “advanced” thing they can pay for. They don’t “need” it. It’s more about the experience and the bragging rights, but I could be wrong.
I’m sorry to somewhat disagree. The reason I would buy this (not at that price tag, I had actually looked into this product) is because I am a wildly hot person/sleeper. I have just a flat sheet on and I am still sweating. I have ceiling fans running additional fans added. This is not only about the experience unless a good night sleep is now considered “an experience”. I legitimately wear shorts even in up to a foot of snow.
As the article says, you can get the same cooling effect with an aquarium chiller for that purpose. You don’t need a cloud-only bed cooler.
Ouch… Please do not follow this piece of advice. A lot of cheap mattresses contain “cancer dust”[1] that you just breath in when you sleep. You most likely don’t want to buy the most expensive mattress either, because many of the very expensive mattresses are just cheap mattresses made overseas with expensive marketing.
The best thing to do is to look at your independent consumer test results for your local market. (In Germany where I live it’s “Stiftugn Warentest” and in France where I’m from it’s “60 millions de consommateurs (fr).” I don’t know what it is in the US.)
A good mattress is not expensive, but it’s not cheap either. I spend 8 hours sleeping on this every day, I don’t want to cheap out.
[1] I don’t mean literal cancer dust. It’s usually just foam dust created when the mattress foam was cut, or when it rubs against the cover. People jokingly call it “cancer dust”
source?
https://www.everydayhealth.com/healthy-home/does-your-mattress-contain-fiberglass-how-to-know-and-why-its-dangerous/
wait… is it carcinogenic? Now I’m concerned lol
I wouldn’t know. Because it depends on what the “dust” is. It just lead most reviewer to say “this can’t be healthy”
This article claims that it just lead to lung irritation. But again, I’m just paranoid, with asbestos we started having concerns way too late.
I think this sort of thing, beyond anything technical, is the biggest argument for growing the standard library (or, at least, those official ordained and maintained by the
rust-langorg). I can argue about the technical merits of Rust to my Rust-sceptic colleagues all day, but it’s difficult to deny that a worrying number of important dependencies in the ecosystem have a low bus factor.I don’t understand how the standard library is any different?
Python, as one example, has several part of its standard library that are unmaintained and falling backward. Same for erlang. How is being part of the standard library helping?
Indeed, being in the standard library doesn’t guarantee active maintenance.
There aren’t enough people in the core team to work on everything. There still has to be someone with expertise and dedication to improve the code.
There aren’t that many people available for reviewing pull requests either. The standard library is focused on preserving backward compatibility and portability, so changes take more time and it’s harder to contribute more than an occasional drive-by tweak.
In Rust, mpsc channels were an example of this: they were in the standard library, technically maintained, but nobody actively worked on improving the implementation. Eventually the std code got replaced with an implementation developed outside of the standard library.
This just puts a bit of rusty paint on the problem. The Rust project had very little capacity for library maintenance, the bus factor would not differ substantially. Indeed, for that reason, the project has more moved libraries out rather than in.
Coming from another language ecosystem, I think this doesn’t acknowledge an extremely common scenario: library maintainer is AWOL, and people show up with patches, and it’s just that there is nobody there to hit merge and do a release.
There are huge piles of projects where there are a bunch of people who are capable, reviewing each other’s changes, and saying “yes this works, I have a fork and we have it working” etc etc etc, but the release can’t happen because one person holds the keys.
Having a large team who holds release keys is generally something that can work out! For every “the maintainer is the only one who could actually make a call on this”-style issue there are hundreds of “maintainer just is done with the project” situations.
I’m not calling to have eminent domain, but having lang teams be able to adopt packages (with maintainer consent) and allowing for a light touch can totally work, especially in the age of Github & co.
Bus factor and capacity are different things. I’m not expecting development to go faster or anything: but when something really, really critical pops up that needs fixing with haste, a larger pool of people ready to merge a fix and deploy a release matters. Ossification and glacial development is fine, not having an official patch for a CVE because the one dev is (quite understandably!) on holiday, less so.
The standard library only releases every six weeks. The more stuff that’s in the standard library, the more stuff that would maybe call for an emergency release, which is far heavier weight and far more disruptive to the ecosystem. People already think Rust releases too often.
Also, a crypto vulnerability is likely to have a high priority. If have to urgently release/deploy, I’d much rather update a single crate than the whole compiler and stdlib.
Not trying to be snarky, but is the complaint about too many releases (and operational churn)? Or too much breakage (from stuff like the “partial ordering for sorts can trigger panics now” saga)?
Like one, you do land on “we should bundle up releases”, but the other is a different flavor of thing, right? Though I mention the sorting panic thing only because it’s the only case I have even heard of.
Saying all that, while I like fat standard libraries, it does feel like the weaker version of “it’s in the
rust-langorg but still packaged separately” gets things 95% of the way there for these kinds of issues, IMO.Operational and “reputational” churn. The time crate is the only breakage I’ve experienced personally in a long time. The process for releasing rustc is involved, the process of releasing a crate is “cargo publish.”
I already regularly hear complaints from very conservative type folks who look at the six week cadence and complain about how often releases happen. Adding more to the mix regularly increases the perception that Rust is still mega unstable, when that’s just not the case.
Can defeinitely see
rustc’s released process being involved vs cargo. Having multiple trusted people be able to runcargo publishis the valuable thing here, moreso than it being in the standard library itself.I do think it’s important to dig into what the reason for the cadence complaints really are though. I feel like the biggest lesson to be taken from Chrome showing up and doing releases all the time is that smaller releases (-> more release) are easier to manage in theory. It would be a shame if those complaints are downstream of other issues that are, in a word, “more” fixable?
This is all context free of course. At least in Python land complaints of things moving too fast that I hear tend to be broken down into “too much new stuff to learn” (a reason I guess, but one I don’t care about) and “old code is not working anymore too often” combined with “package maintainers disappearing” (which are realer issues, and can be handled).
It’s just systems people who are used to C89 and so they see backwards compatible but new features as “breaking” because they want to stay on old compilers but compile new code.
OK I see the case now. The maximally generous version of this is “well there is some issue X that is stopping my upgrade but everything around me is moving so fast that it throws me forward” (in Node this is common because packages agressively upper bound node versions even when they don’t need to, leading to a bunch of incidental things making upgrades hard), but tbh I feel like Rust isn’t doing it that much. Especially nowadays where people seem pretty serious about not using stuff from
nightlyetc.I agree, but the “issue x” is mostly “i want to use a dependency and it uses some rust language feature that is newer than my current stable version” and the “stopping my upgrade” is simply “I don’t want to” not “I tried it and it didn’t work.” That is, it’s perceived instability, rather than actual instability. For these folks, “stable” means “unchanging” not “backwards compatible.”
The shift from RSA to ECDSA is, relatively speaking, quite recent and we just had Microsoft announce their crazy qubit capabilities meaning quantum resistant cryptos are maybe sooner required than we previously thought. I think crypto is exactly the kind of thing that needs to be kept out of a standard library to avoid churn/deprecation.
Some officially blessed crate, sure.
I’ll leave a top-level comment on it, but aside from having a single “blessed” library, I think consensus on cryptographic trait implementations for backends would be fantastic.
High-level libraries that can be built to consume those traits, low-level implementations that implement them; would lead to easier agility when the “blessed” library is no longer the go-to.
The idea that absorbing something like ring into stdlib would automatically give it new maintainers feels like wishful thinking. Getting maintenance done is a combination of having the required skill (and for crypto, the bar is high) and accepting that it’s not someone else’s problem.
The “someone else’s problem” feeling can be pretty high for code in a stdlib. Whereas here, in the crate ecosystem, when the ring maintainer gave up we got an advisory that prompted new maintainers to step in. Looks like FOSS is working.
I am currently doing an apprenticeship and what I am witnessing is, that there seems to be a change in motivation. Many don’t go into development, because they are curios or eager to learn and understand, but to make money and remote working. I don’t want to say that this is bad, but just a change I’ve seen
It’s not a change. When I studied computer science, most of my peers were motivated by wanting a high grossing job and did not have a lot of ambition to “go beyond” during studies. That was around 2003.
That’s fine, it’s not a bad attitude, just one that needs to end up at the right place. A lot of them ended up really reliable IT workers that can really accurately do a job by spec, much better than I can.
Some others found their love for hacking later and do really absurd stuff now.
I think a lot of this is that you don’t need to be a hacker (https://en.wikipedia.org/wiki/Hacker_culture not cyber security hacker) to be a good software engineer, just like you don’t have to be a good software engineer to be a hacker. It’s more of a difference in culture rather than any sort of indicator as to job performance in my opinion.
Right, but there was an understanding that only good devs could make a high salary, so the money motivation worked. Today there’s the idea that there’s plenty of work LLM copyists and many people would do it for a living wage.
I’ve been observing that trend for at least five years. Maybe ten, though the interest in remote work has obviously changed. I think it’s due both to the influx of money and the lowering of various barriers to entry. Newcomers no longer have to climb the kinds of learning cliffs only dyed-in-the-wool geeks will attempt.
Very sad. Unfortunately it’s been my experience that FOSS is inextricable from inter-maintainer strife even on very small projects. This is a bit of a wild proposal but I do legitimately think video couples therapy would be helpful for soothing disputes between maintainers. Our field is short on emotional intelligence, magnified by text-only communication and further magnified by cross-cultural reach.
I wish I had the time today to write a longer response, but I fundamentally think this is not true. In all my experience as a team lead of multiple open source orgs, I experienced very much the inverse.
What lacks is, for lack of a better term, some kind of professionalism, but not in the corporate sense. One we (and I’m using the collective “we” carefully here) own. The problem here is particularly this:
FOSS is the forefront of extremely distributed, loosely coupled organisations with an amazing amount of random touch points to the outside. We literally don’t know how to handle this. This isn’t a lack of intelligence, it’s a lack of templates, advisors, experiences. All management philosophy is built around companies, not around organisations that people stay in over 10 years, switching their employers along the way.
It’s not a wild proposal, it exists.
To anyone reading this and wanting this: I know people who do that and I’m happy to connect. Obviously, they don’t work for free.
It’s not new (and you don’t say it is) - practically for ever there have been organisations whose members had different employers. For example, many (not all) political parties, religions, professional and academic associations. In some cases they have internal cohesiveness and in other cases not. I agree with you that “management philosophy” seems to ignore these structures.
Very much yes, and thanks for clarifying that.
I’m always joking that I learned more for FOSS out of my sports club (which is 200 years old and part of a 7 layer international structure that works to a certain extent) than from management school.
Leadership (likely Linus) needs to step in here and either say “rust is ok” or “rust is not ok.” Otherwise these same rehashed arguments in the LKML will be going over and over again, and nothing gets done except people burning out.
But it is neither, I don’t know where people think to think that the adoption of Rust in the Linux kernel is already a decision that has been made years ago. From: https://docs.kernel.org/rust/index.html#the-rust-experiment
That said, people like GregKH are already convinced that Rust for Linux has been success (I do as well, but I’m just watching from the peanut gallery). But that doesn’t mean that “rust is ok” w/o further discussion. Different developers/maintainers still have to be convinced.
Watching from the outside it seems that some maintainers don’t want to be convinced in the first place.
Some seem ready to actually make an effort to see what the experiment will lead to, but that’s far from the majority.
From personal experience with some of the involved in this thread from the maintainers side, I disagree. It’s unsurprising that, after years and years of holding the kernel as a pure C project for good reasons (not even allowing the sister language C++ in), there’s people that hold this as a value. Those aren’t convinced easily, not on a short timeline and not via email. I know people wish for a strong word from Linus, but this is only partially in his hands - particularly as the person who previously held the “pure C” line.
I’m not a fan the tone, but I was for example completely unsurprised by Chris Hellman holding that line and not arbitrarily.
R4L is not just a substantial engineering effort, it is also a substantial social effort. And that means a ton of legwork, and maybe some beers at a bar.
At this point what is happening there is not ‘leadership’.
My naive and oversimplified take on this is that Rust would be allowed, but is expected to have backwards compatibility assurances, and so long as Rust constantly changes things and lacks those assurances, Rust won’t be added.
Is this correct? Somewhat correct? Not really the issue? Incorrect?
As someone who sees Rust getting rebuilt monthly or even more often than monthly because of new versions, and codebases like Firefox (and even Rust itself) that can’t use an ever-so-slightly older version of Rust, I get the impression that Rust has a long way to go before it settles enough to be used for software that has extremely long maintenance cycles. But that’s just my impression - I have no experience actually programming in Rust.
The results of the annual survey have come out, and 90% of users use the current stable version for development. 7.8% use a specific stable released within the past year.
These numbers are only so high because it is such a small hassle to update even large Rust codebases between releases.
Rust is stable in the sense of “is backwards compatible” even if it isn’t in the sense of “doesn’t have a slow release cadence.”
A new version of Rust comes out every 6 weeks. Rust has many so-called unstable features, which are not available by default and have to be opted into. Those features can change at any moment. But if you don’t opt in to such features, the language is extremely stable. Every time a new Rust version is being prepared, they compile and run the test suites of pretty much all known publicly available Rust code, just to make sure nothing went wrong.
Rust for Linux does opt into a few unstable features, but they’re pretty close to being finished and making sure R4L can work without unstable features is a high priority goal for the Rust Project.
Rust has stability guarantees written down and heavily tested since nearly 10 years to particularly allow evolution with very strong backwards guarantees.
Language: https://rust-lang.github.io/rfcs/1122-language-semver.html Libraries: https://rust-lang.github.io/rfcs/1105-api-evolution.html
Rust (ideally) never breaks backwards compatibility except in a very defined set of cases. (e.g. bugs in the language frontend that allow you to bypass it’s guarantees are bugs, not features and will be fixed, at the cost of breaking some notion of backwards compatibility). It has an extremely heavy hammer test suite to ensure no unwanted changes to go in and/or assess the impact of changes called crater - which literally runs for days. https://github.com/rust-lang/crater?tab=readme-ov-file#crater
Recommendation: before you actually enter discussions about Rusts backwards guarantee (I know you haven’t, this is more for the reader), please read the two RFCs. They are relatively short, subtle and good. I often see discussions going wrong where people haven’t read those docs and have discussions that have no basis in reality.
I don’t think that’s true. You get amazing backcompat by default and guaranteed compat by using Rust editions.
Firefox doesn’t have to upgrade every six week. We enjoy upgrading. We can do so because the benefits outweigh the costs.
the benefits to whom? goodness gracious…
news flash: your users don’t enjoy you upgrading.
Are you compiling Firefox by yourself?
no; it’s impractical to do so.
Help me understand. Why would you want to compile it yourself?
Being a BSD masochist^Wuser, I generally maintain my own package repo. Firefox is included in that repo. I love having full control over the packages installed on my system. I’m probably an outlier here, though.
well now we’re changing the topic, but one reason is that it removes the need to trust external builds. another would be to patch it e.g. to restore FTP support. another is that it’s a necessary on-ramp to contributing, or generally to exercising the rights granted by the license.
These are all good and valid points. Thanks for sharing :-). I can see how that’s important to you and the latter being really important for both of us.
no problem
I don’t think this is correct. Rust would be experimental and it would be entirely on the RFL members to ensure it stays up to date and correct, without blocking others. None of this would have to do with the language.
so if a casual linux user hears “linux runs on M1 macs,” then spends their whole paycheck on a computer with no ethernet or USB-A ports because of it, then too bad for them because they should have known that “it runs linux” no longer means it has the stability and longevity that could once be expected.
Asahi linux and RFL are two different projects with totally unrelated stability guarantees, none of those guarantees have to do with the RFL code working.
As for the user spending money or whatever, I have nothing to say on the matter. Are users responsible for purchasing decisions? I don’t know, I don’t think it’s relevant at all.
what I read is that a lot of the drivers for asahi linux are written in rust. are they not part of the main kernel tree?
They’re in the Rust for Linux tree, but they’re not in Linus’s tree yet, because they’re blocked on other stuff getting merged first (like the DMA abstraction).
Asahi Linux is not upstream, that’s correct.
is “upstream” synonymous with “the main kernel tree”?
are all of the rust drivers that an asahi linux system uses part of the asahi project and not in the main kernel tree?
I don’t know much about this so I want to make sure I understand.
Yes. That is Linus’s tree, which is the ultimate upstream of the Linux project.
I think so. Most of their C drivers aren’t upstreamed yet either, I believe. The C drivers I don’t think are blocked by anything in particular, it’s just work that isn’t finished yet. The announcement blog post says that they are going to focus on upstreaming this year. The Rust drivers are blocked by needed Rust for Linux abstractions not being upstreamed yet.
so then none of the rust drivers are merged in the main tree. can we say that definitively?
Yeah.
I’m not sure how much is actually merged, if it is though it’s experimental. I believe much of it is not merged, and it was naturally developed outside of the main tree (as anything would be). The GPU driver, often cited as a big success story for Asahi, is not merged, for example.
a first?? continuing here…
I think I’ve been misunderstanding what is meant by “behavioral” or “API/ABI” stability. I thought this referred to the stability of the interface between the kernel and userland, and that being “experimental” would mean the external interface is not maintained in the same way as other parts of the kernel. but now I’m thinking that the API/ABI stability is between different components within the kernel, and they want to “experiment” with making those internal interfaces more stable. do I have that right now?
That would be right, at least for the most relevant stuff like the filesystem discussions. It’s ensuring that when something changes on the kernel side (not userland facing) that the Rust code matches that.
ok that helps. so to go back to what kicked off this discussion:
so this means that the C kernel devs could change things that break RFL code and aren’t obligated to fix it, whereas if it were any other part of the kernel, the C devs would be obligated to fix it or make sure it gets fixed. right?
That’s about right, although there’s always some shared responsibility between the person changing the API and the callers (in RFL’s case it’s all on the Rust devs).
so if the reputation of linux is due to the C developers, then having a completely separate team develop code that people are told is linux could subvert the expectation that linux is developed by the same group that built its reputation.
that’s what I was getting at when I said “‘it runs linux’ no longer means it has the stability and longevity that could once be expected.” of course it’s a matter of debate whether the rust effort will yield better or worse stability/longevity, but the development process for M1 macs is not time-tested in the same way as the development process for, say, the thinkpad x13s. is that fair to say?
and do you think the recent debacle is a bad sign for the stability/longevity of linux on M1 macs? regardless of who you blame for it. I saw some other comments to that effect.
I’m not sure that the reputation argument is going to hold much water with me. Linux has a pretty bad reputation in my mind, but how it’s marketed is completely disconnected from that. I can’t tell you how things should or shouldn’t be marketed, or the complexities of layman making technical purchasing decisions, or how the experimental branch might change things, or what is or is not ethical to say about support for a Mac on Linux. If you want to say that Asahi is somehow wrong for something they’re saying about support or stability, you can do so, I just don’t think it’s relevant to RFL. If you want to see their messaging, this seems to be the relevant page: https://asahilinux.org/about/
Maybe? It’s really hard to say. Many drivers are poorly supported or maintained by far fewer/ less motivated people than Asahi.
It’s a bad sign for Linux in general, which, as I’ve stated elsewhere, is not going to be a dominant OS in the future because of upstream’s behavior and fundamental structure. In the short term I think the major impact is going to be that Asahi probably isn’t interested in staying out of tree forever, they likely had loftier goals and wanted this to be a larger project as a part of RFL, and so by upstream pushing RFL away Asahi developers will be pushed away/ fail to gain as much traction. I think this will be bad for Asahi and bad for Linux users, sure.
your answers have been duly noted. I take them as assurance that my original comment wasn’t completely off-base or reliant on a fundamental misunderstanding.
There is no separate team. RfL is being done by regular kernel maintainers who happened to pick up an interest in Rust. Pretty much everyone (maybe literally everyone) contributing Rust code to Linux has contributed and continues to contribute C code.
then why the need for a different policy on who is responsible for what in regards to RFL vs the rest of the kernel? seems like a separation to me.
(please don’t mistake my use of “completely separate” as implying that there are no developers in both groups or that they are hermetically insulated from each other.)
Because the vast majority of Linux maintainers do not know Rust, and therefore this experiment couldn’t be run at all if maintainers of C code were expected to fix Rust code when they make changes. And even if RfL is a complete success and Rust becomes a permanent part of the kernel, most likely there will need to continue to be a collaboration between Linux devs who know Rust and those who don’t, to keep Rust code up to date with changes in C interfaces.
makes sense
cool good to know. so can you clarify this part:
in general terms it seems like if any of the rust code used by asahi is merged with the main tree, then the stability of asahi linux does depend on the stability of that code.
I’m wondering if we’re talking about stability in the same way? Are you talking about stability in terms of stable behaviors/ API/ ABI? Or do you mean in terms of crashing? The former is what’s being discussed with RFL, not the latter.
here I was referring to “stability and longevity” in the sense that would be relevant to a casual linux user, who may have come to expect that if a system runs linux it will continue to run linux for a decade or more with fewer crashes and bugs than a proprietary OS.
I am acutely aware that user concerns are conspicuously absent from the RFL discussion.
I don’t really follow your point throughout this. Is your concern that Rust will be less stable in the sense of less reliable or something? Or that Asahi Linux will be? I don’t really know how that’s relevant to RFL or actually anything that’s been brought up, or why you’re bringing it up.
as an uninformed casual linux user, over the past year I have gotten the impression that “linux runs on M1 macs,” and in another life this might have motivated me to buy one. with this news it seems like linux might not run on M1 macs for much longer, or might not gain the eventual reliability that I would normally expect if I hear that linux is getting ported to a platform.
I was under the impression that Asahi Linux was hoping to eventually depend on RFL for the practical aspects of reliability, and if it’s “entirely on the RFL members to ensure it stays up to date and correct,” then that is qualitatively less assurance than if the code is supported by the kernel team as a whole, as was once implied if linux is said to run on a platform.
I see. So yeah, I think it’s good to point out that the stability referred to in RFL conversations is in terms of behavioral stability, not things like bug fixes. Asahi is a downstream project, it is maintained separately, and its stability (in terms of not crashing) has nothing to do with RFL. Asahi users will continue to get patches for bugs as long as there are developers willing to do so, this is not related to RFL, although presumably Asahi wants RFL to happen to ease their development burdens etc.
Right, so there are a few things here.
With regards to bug fixes/ patching, it is not up to the RFL members at all, it’s up to the Asahi developers, who work downstream. This is totally separate from RFL.
With regards to RFL, completely distinct from Asahi, the issue is not crashing it is behavioral and API stability. As RFL is “experimental” it is up for RFL to maintain interfaces that are up to date and not the C developers who maintain other code. Nothing to do with Asahi or bug fixes etc.
You might be under the impression that the Linux kernel considers stability to be a shared responsibility (ie: “everyone is responsible for bug fixes”) but this is not the case at all. Typically it is one developer maintaining a suite of drivers, a filesystem, etc, and they are the only ones responsible. There isn’t a big difference in reliability between something upstream or downstream, what changes is primarily on the committers side in terms of maintaining patches, others contributing Rust, etc, which is what RFL is about. If one of those solo committers/ maintainers left users would be just as fucked as ever - and this happens.
thanks for the overview.
I still don’t get this part. doesn’t a lack of behavioral stability risk creating bugs?
if asahi’s stability “in terms of not crashing” doesn’t depend on RFL, how would RFL ease their development burdens? if some code that is needed for asahi to run is taken up by RFL, then woudn’t bugs in that RFL code affect the running of an asahi linux system?
Maybe, but since Asahi is its own distro it picks its own kernel and userland, so the distro can just not upgrade userland components that would rely on some behavioral change in the kernel. They own that themselves so their users aren’t any worse off.
I think there’s a number of things that would play out longer term. One thing that RFL wants is to start to formalize some of the behaviors in the kernel so that their drivers can provide safe, stable interfaces, and reduce the burden for all developers in maintaining them. Asahi would then have less of a burden of development.
Of course, but why would RFL change anything? The code has a bug or it doesn’t. The issue is things like relying on the behavior of the C driver vs the behavior of the Rust driver, which is why RFL wants to formalize those semantics.
I think we’ll probably start hitting the limits of my knowledge if we get too into the details of why Asahi wants to do one thing or another, RFL has numerous motivations. The tl;dr is that the stability discussed is about ABI/API stability, RFL would help Asahi because it would help them formally adopt the behaviors of the C code (by stating those behaviors vs those behaviors just being assumed by one maintainer), and Asahi users aren’t going to experience a less stable OS by virtue of RFL being “experimental” since RFL’s impact would only mean that the code lives in one spot vs another.
all else being equal, a decrease in kernel ABI/API stability would mean more work to keep up with changes and identify which userland components are safe to upgrade. for the same amount of developer/maintainer time, the system would be either less reliable or less up to date and their users would be worse off.
point taken.
presumably “experimental” code is more liable to have bugs.
are you saying that Asahi wouldn’t rely on RFL code if it weren’t experimental? or that all of the RFL code relied upon by Asahi will inevitably come from the Asahi project, and would be in Asahi if it weren’t in RFL?
Right, RFL would presumably help that, which is why they want RFL so that they can go upstream.
Nope, not in this case. It just means it’s an experiment, if it isn’t successful it’ll get pushed back downstream.
Hmmm, I’m not sure what you mean. Asahi relies on the code that it relies on, that’s all. RFL would allow their code to live upstream, and would imply some things that RFL is pushing for like more defined behaviors of existing interfaces. That’s what I’m saying. Asahi will rely on RFL code when their code makes it upstream as “experimental”, otherwise that same code would be downstream but otherwise the same. RFL code won’t necessarily come from Asahi, certainly, anyone is free to try to push their own Rust code to upstream.
Why would you spend your whole paycheck on a computer? That’s irresponsible.
if someone makes under $30k a year, buying a $1000 computer is irresponsible?
If someone makes X a year, buying a X/12 computer is irresponsible.
the paycheck I had in mind would be biweekly with taxes and benefits taken out.
but even your X/12 idea seems needlessly judgemental and paternalistic, and doesn’t account for savings and fluctuations in income. the average salaried indian makes $200-300 a month; median is probably much less. it would be irresponsible for them to spend that much on a computer?
the idea that you can have Rust in the kernel but it doesn’t have the same stability guarantees is just atrocious.
what stability guarantees?
The normal rules for intra-kernel interfaces are “you can break somebody else’s code, but you have to then fix it”. But if you break some Rust code, it’s the duty of the Rust for Linux people to fix it.