Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

Post reply on HN
Print view View original

521–530 of 1001 posts

Re: Resigning as Asahi Linux project lead

#521

Post by zifpanachr23 »

dralley wrote: post #440
afr0ck wrote: 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?

To start, not resigning when things don't go their way. That tendency is doing a lot to make the claim of rust people saying they will handle the burden of rust code unbelievable.

Re: Resigning as Asahi Linux project lead

#522

Post by geodel »

ajross wrote: post #490
mulmen wrote: post #446

Earlier quoted context omitted.

> The same people community clutching pearls This is an unfortunate typo because your meaning is completely lost. If your claim is that individuals are being hypocritical then you may have a point. Especially if you can produce examples. But if you mean community vs community then you have simply bought in to the religious debate which isn’t interesting.

[flagged]

[flagged]

Re: Resigning as Asahi Linux project lead

#523

Post by kllrnohj »

arp242 wrote: post #174
imiric wrote: post #147

This is unfortunate, but before pointing fingers, it's worth putting things into perspective. The linked "thin blue line" message[1] also says this: > One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know , through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contr…

I don't really follow what's objectionable about Ted's email, or why it's being singled out. It matches my experience as an open source maintainer pretty accurately. It's also pretty constructive (it goes on to lay out a plan on how to constructively proceed and make everyone happy).

What's objectionable is primarily the phrase "thin blue line" - it's highly politically charged language: https://en.wikipedia.org/wiki/Thin_blue_line

One would hope it was just a particularly bad gaffe, but it could also be an insight into how he actually views himself as a maintainer which is not great.

Re: Resigning as Asahi Linux project lead

#524

Post by toast0 »

nrabulinski wrote: post #314
rdtsc wrote: post #209

A person can be in a tough spot personally and then things seem to spiral out of control around them because that just cannot be 100% isolated from professional stuff or other spheres of life. It seems like this might have happened to Hector based on the post. We've all been there and that part is completely understandable. > I get that some people might not have liked my Mastodon posts. Yes, I can be abrasive someti…

> That’s not ok. Then entertain his question and tell us what is? Bringing up people’s attention to the matter to finally somehow resolve the situation is his last resort, after spending years trying to upstream even trivial patches. You can eat your cake and have it too - you can’t say you want rust in the kernel and then sabotage any upstreaming efforts

> Then entertain his question and tell us what is? Bringing up people’s attention to the matter to finally somehow resolve the situation is his last resort, after spending years trying to upstream even trivial patches.

When upstream won't work with you, the answer is to maintain a separate tree. Yes, it's a lot of work to maintain a separate tree. No, you won't get as much use if you're in a separate tree.

Re: Resigning as Asahi Linux project lead

#525

Post by chongli »

knowitnone wrote: post #382
gkbrk wrote: post #259

Earlier quoted context omitted.

The backwards compatibility guarantee for C is "C99 compilers can compile C99 code". If they can't, that's a compiler bug. Same for other C standards. Since Rust doesn't have a standard, the guarantee is "whatever the current version of the compiler can compile". To check if they broke anything they compile everything on crates.io (called a crater run). But if you check results of crater runs, almost every release so…

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

C makes a distinction between the language version and the compiler version. Rust does not. That's the problem people are discussing here.

Re: Resigning as Asahi Linux project lead

#526

Post by tuna74 »

UncleEntity wrote: post #474
freehorse wrote: post #342

Earlier quoted context omitted.

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 thin…

You can't shake out bugs for features that are not there. More users won't help, only more developers.

Re: Resigning as Asahi Linux project lead

#527

Post by kllrnohj »

tuna74 wrote: post #497
kllrnohj wrote: post #411

Earlier quoted context omitted.

> which is actively hostile to a second Rust compiler implementation Which is hilarious since Linux itself was actively hostile to the idea of a second C compiler supporting it. Just getting Linux to support Clang instead of only GCC was a monumental task that almost certainly only happened because Android forced it to happen.

It happened because the Android people put in the work to make it happen both in Linux and in Clang/LLVM.

Putting in the work is one thing, which is what the Rust-in-Linux people are also doing, but there's also the political requirement to force maintainers to accept it. Android was big enough, and happy enough to fork seeing as it had already done that before, that it forced a lot of hands with top-down mandates.

Rust, despite having Linus' blessing to be in the kernel, is still just getting rejected just because it's Rust, completely unrelated to any technical merits of the code itself.

Re: Resigning as Asahi Linux project lead

#528

Post by gkbrk »

steveklabnik wrote: post #519
gkbrk wrote: post #472

Earlier quoted context omitted.

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 th…

You conveniently left out > However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.

Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible".

The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs.

This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.

Re: Resigning as Asahi Linux project lead

#529

Post by s1mplicissimus »

Certhas wrote: post #357
mietek wrote: post #199

Earlier quoted context omitted.

Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not get out of sync with the code, because they are part of the code, unlike documentation. The language implementation (e.g. the compiler) automatically checks that the types continue to match the rest of the code, in order to catch problems as early as possible.

Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.

> Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive.

if you really need a number, why not use a type specifically aligned to that (something like f32|f64|i32|i64 etc...) instead of relying on + operator definition?

> Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.

do we agree that if it's not in the interface you are not supposed to use it? conversely if you want to use it, the interface has to be extended?

Re: Resigning as Asahi Linux project lead

#530

Post by opan »

vessenes wrote: post #23

First of all, yay Asahi — one of the great modern hacking / hacker stories in my opinion. Second, what’s the drama? I read the blog, and I’m guessing that on top of being burned out, which sucks, Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense. He then says he may have been toxic on Mastodon, which might have got him secretly cancele…

>Marcan didn’t like a kernel developer using the phrase “we are the thin blue line” implies he’s politically liberal, in the US sense.

From what I saw on urbandictionary, it seems more likely to be something cops in high crime areas in the UK say.

Post reply on HN