Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

471–480 of 1001 posts

Re: Resigning as Asahi Linux project lead

#471
post #426

Earlier quoted context omitted.

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible. What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?

It is not concern trolling. It is a harsh disagreement.

Some kernel developers really do feel that any Rust in the kernel will eventually mean that Rust gets accepted as a kernel language, and that they will eventually have to support it, and they the only way to prevent this is to stop any Rust development right now.

And yes, there's nothing that the R4L group can offer to be get around that belief. There isn't any compromise on this. Either Rust is tried, then spreads, then is accepted, or it's snuffed out right now.

A big mistake by R4L people is seeing anti-Rust arguments as "unfair" and "nontechnical." But it is a highly technical argument about the health of the project (though sometimes wrapped in abusive language). Rust is very scary, and calling out scared people as being unfair is not effective.

Re: Resigning as Asahi Linux project lead

#472
post #371

Earlier quoted context omitted.

His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.

How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.

This is not what the "Rust kernel policy" [1] of Rust for Linux says.

[1]: https://rust-for-linux.com/rust-kernel-policy

> Who is responsible if a C change breaks a build with Rust enabled?

> The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

> Didn't you promise Rust wouldn't be extra work for maintainers?

> No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.

Re: Resigning as Asahi Linux project lead

#473

Earlier quoted context omitted.

> Open source attracts some of the very worst users I don't think it's even just that, it seems to be something about the price. I work on a piece of closed-source free software, and we consistently get support requests from unbelievably entitled assholes. The worst of them are the ones that have some technical knowledge; they will not only demand things be fixed or implemented, they make completely erroneous stateme…

> I PAID FOR THIS YOU MUST FIX IT!!!1! Sounds like a great time to give them a refund because they didn’t get the product they thought they were getting. Too passive aggressive? :)

It's even easier to give people a refund when it's open source

Re: Resigning as Asahi Linux project lead

#474

> But then also came the entitled users. This time, it wasn’t about stealing games, it was about features. “When is Thunderbolt coming?” “Asahi is useless to me until I can use monitors over USB-C” “The battery life sucks compared to macOS” (nobody ever complained when compared to x86 laptops…) “I can’t even check my CPU temperature” (yes, I seriously got that one). This sounds so rough. I can't imagine pouring your…

I think entitlement like that is stupid and bad for open source (and everything). However, in the next paragraph the author gets into criticising the opposite position, that asahi linux was not ready for everyday use. The entitled requests came from users that thought of asahi linux as exactly covering an everyday use case, a linux distro they should be able to use to carry on their tasks. This I find contradictory.…

Thing is it will never get to be a daily driver if people don't use it and shake out the bugs.

25 years ago (huh, long time), when Windows ME pissed me off for good, linux wasn't exactly known for being a daily driver but I gave it a try and, unsurprisingly, it did become reliable over the years. Other than Gnome's propensity to make stupid changes to default settings I can't remember the last time I had to even think about messing with the underlying system and other than a simple google search on the linux compatibility of hardware before I buy I just don't think about it. Actually, I take that back, when I first got my current laptop I was messing around to get the AMD mesa drivers (or whatever) working because I wanted to mess around with this fancy GPGPU thing.

Personally, if I were to buy a macbook it would be for the OS and not dodgy linux support because I've walked that road before. If the Christmas sales were just a tiny bit better though...

Re: Resigning as Asahi Linux project lead

#475
post #338

Earlier quoted context omitted.

> This is par for the course I guess, and what exhausts folks like marcan. I wouldn't want to work with someone like Ted Tso'o, who clearly has a penchant for flame wars and isn't interested in being truthful. I am acquainted with Ted via the open source community, we have each other on multiple social media networks, and I think he's a really great person. That said, I also recognize when he gets into flame wars wit…

> Ted hates the new MiB/KiB system of base-2 units, and for whatever reasons like the previous more ambiguous system of confusingly mixed base-10/base-2 units of MB/Mb/mb/KB/Kb/kb Here's my best argument for the binary prefixes: Say you have a cryptographic cipher algorithm that processes 1 byte per clock cycle. Your CPU is 4 GHz. At what rate can your algorithm process data? It's 4 GB/s, not 4 GiB/s. This stuff happ…

> Another one: You buy a 16 GB (real GB) flash drive. You have 16 GiB of RAM. Oops, you can't dump your RAM to flash to hibernate, because 16 GiB > 16 GB so it won't fit.

Right but the problem here is that RAM is produced in different units than storage. It seems strictly worse if your 16GB of RAM doesn't fit in your 16GB of storage because you didn't study the historical marketing practices of these two industries, than if your 16 GiB of RAM doesn't fit in your 16 GB of storage because at least in the second case you have something to tip you off to the fact that they're not using the same units .

Re: Resigning as Asahi Linux project lead

#476

Earlier quoted context omitted.

> Rust has a stability guarantee since 1.0 in 2015. Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. Unfortunately OP has a valid point regarding Rust's lack of commitment to backwards compatibility. Rust has a number of things that can break you that are not considered breaking changes. For example, implementing a trait (like Drop) on a type is a breaking ch…

I was hit by a similar thing. Rust once caused regression failures in 5000+ packages due to incompatibility with older "time" packages [1]. It was considered okay. At that point, I don't care what they say about semver. [1]: https://github.com/rust-lang/rust/issues/127343#issuecomment...

That was a mistake and a breakdown in processes that wasn't identified early enough to mitigate the problem. That situation does not represent the self imposed expectations on acceptable breakage, just that we failed to live up to it and by the time it became clearer that the change was problematic it was too late to revert course because then that would have been a breaking change.

Yes: adding a trait to an existing type can cause inference failures. The Into trait fallback, when calling a.into() which gives you back a is particularly prone to it, and I've been working on a lint for it.

Re: Resigning as Asahi Linux project lead

#477

Drama needs to be worked against, not expanded upon. A lot of what I’m reading seems to make me feel that drama was… not avoided by this person, putting it charitably. And I'm someone who I believe still sponsors them! Asahi Linux is an awesome, and dare I say necessary, project. There is value in learning how to relinquish a constant "defensive posture" mentally. (I have struggled with, and am still working through…

Avoiding drama is a two-way street. I'm not saying marcan wasn't at least somewhat at fault here, but the reason the drama happened in the first place is a leadership crisis and Linux folks calling Rust a cancerous religion without any pushback. Might be valuable to resolve these problems instead of blaming a scapegoat, don't you think?

Re: Resigning as Asahi Linux project lead

#478
post #427

Earlier quoted context omitted.

> language backward-compatibility, vs. standard practices about what semver means I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...

I assume that they mean that you can use Rust as a language without its standard library. This matters here since the Kernel does not use Rust's standard library as far as I know (only the core module). I'm not aware of semver breakage in the language. Another important aspect is that Semver is a social contract, not a mechanical guarantee. The Semver spec dedicates a lot of place to clarify that it's about documente…

> Another important aspect is that Semver is a social contract, not a mechanical guarantee for.

Although there are mechanical aids for it: https://crates.io/crates/cargo-semver-checks

Re: Resigning as Asahi Linux project lead

#479

Earlier quoted context omitted.

My comment might have been technically wrong as originally stated; I’ve since edited to try to correct/clarify. What I really meant is the case where a method is added to a standard struct impl that conflicts with a user-defined trait. For example, you might have implemented some trait OptionExt on Option with a method called foo. If now a method called foo is added to the standard option struct, it will conflict.

Look at the linked code - it literally shows what happens in that case. What happens is not what you're saying.

This code compiles on 1.81 and fails to compile on 1.82: https://godbolt.org/z/9GbbMKjcf

Re: Resigning as Asahi Linux project lead

#480

Earlier quoted context omitted.

What do you mean? Rust 1.0 can compile Rust 1.0. Rust 1.1 can compile Rust 1.1.

But Rust 1.0 can't compile Rust 1.1. And as others have noted, C99 is a standard and Rust lacks one.

But Rust 1.0 can't compile Rust 1.1

That's an impossible standard to hold Rust to, did you mean it the other way around? A C89 compiler can't compile all of C99 either.

Post reply on HN