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

Asahi Linux lead developer Hector Martin resigns from Linux kernel

lkml.org

Post reply on HN
Print view View original

931–940 of 1001 posts

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#931

Post by artyom »

ksec wrote: post #891
artyom wrote: post #201

Earlier quoted context omitted.

> an uncommon failure of leadership for Torvalds Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results. So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community sho…

>"Community" is just a very naive ideal for me. I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.

[flagged]

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#932

Post by arghwhat »

roca wrote: post #871
arghwhat wrote: post #595

Earlier quoted context omitted.

In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI. In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that…

"The email patch usually gets dealt with within a week or two" is absolutely not my experience dealing with the kernel. Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".

That your experience is not shared suggests that the other "workflows" are not in fact objectively easier to deal with than the kernel workflow, but instead that there's a high variability in the frustration experienced across all three workflows.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#933

Post by arghwhat »

roca wrote: post #870
mook wrote: post #656

Earlier quoted context omitted.

I haven't touched Gecko in a decade, but your second paragraph sounds like my experience. My best record was something like a single character bug fix taking months (might have been years?). Yes, the review flag was set to the right person. I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…

I'm sorry you had a bad experience with someone, but at least you know who wasn't doing their job. On the kernel side, you don't.

get_maintainer.pl gives you the list. Theres no equivalent in Firefox or Chromium to flag which Mozilla/Red Hat/Google/... manager does not consider your ticket an area of focus.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#934

Post by pas »

sgt wrote: post #929
pas wrote: post #881

Earlier quoted context omitted.

Sometimes there's no win-win-win solution. I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.

> "I think people who write C should stop unless it's to fix security bugs and should do something else" That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though. And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?

Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :)

... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.

And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.

But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.

https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...

https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...

If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#935

Post by cies »

TuxSH wrote: post #882
cies wrote: post #670

Earlier quoted context omitted.

> As a pilot program, R4L should have graduated or ended a long time ago. Disagree. These things take time. Linus knows that, and as I see it, he's giving it the time it needs. "After years of active development" we've only recently arrived at a point where actual driver development in Rust is possible. > We all know [Linus'] stance on C++ Yes. And looking back I think that was a good stance. C++ is not for kernels:…

> C++ is not for kernels That's a broad generalization to make. Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers. I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.

There's C-- (and a few other similar efforts) that are basically C++ with a lot of features forbidden/disabled. I suspect Horizon OS also does this.

I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#936

Post by znpy »

bitbasher wrote: post #283
znpy wrote: post #37

Earlier quoted context omitted.

I think the core of the issue is expecting people to agree with stuff. Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.

The kernel is nearly 30 million lines of code. I would love to see a fork where Rust starts taking over sections of it, but that's a huge undertaking that would clearly take many years.

Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#937

Post by TuxSH »

cies wrote: post #935
TuxSH wrote: post #882

Earlier quoted context omitted.

> C++ is not for kernels That's a broad generalization to make. Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers. I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.

There's C-- (and a few other similar efforts) that are basically C++ with a lot of features forbidden/disabled. I suspect Horizon OS also does this. I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.

3DS HOS was known to be using armcc and Switch HOS is known to be using clang.

Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)

My opinion (and the opinion of people using C++ in such constrained envs.):

* C++ (the language itself along with stuff like and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm

* most of the other parts of the stdlib are defective

* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#938

Post by HacklesRaised »

It is a quandry, the kernel is predominantly C, Rust has demonstrated a path forward, producing safer code without sacrificing performance, but it is undeniable that a mixed code base is far harder to maintain, not impossible.

Here's the thing, in the next couple of years languages like Carbon, Zig, even Jai, will come of age. They will have their proponents and people who want to introduce them into kernel code.

If there is a rust developer out there who doesn't resist the introduction of these languages as ardently as the chosen people (C) are resisting rust, then I will show you someone who lives in some kind of alternate reality.

Personally, I'd be pressuring the C committee to introduce defer, tout suite, otherwise Zig looks favourite. But the reality is that your preferred language is just that, your preferred language, most have seen this drama before and will choose not to participate.

As to whether Linus is failing in his leadership role? Nah, Then again, I wish Sony would open source the PS OS and we can be done with this juvenile debate as to which OS should rule the world. Either that or let's have an exokernal and move on from this monololithic story, surely that would meet the needs of the MY FAVOURITE LANGUAGE isn't appreciated crowd!!

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#939

Post by roca »

arghwhat wrote: post #933
roca wrote: post #870

Earlier quoted context omitted.

I'm sorry you had a bad experience with someone, but at least you know who wasn't doing their job. On the kernel side, you don't.

get_maintainer.pl gives you the list. Theres no equivalent in Firefox or Chromium to flag which Mozilla/Red Hat/Google/... manager does not consider your ticket an area of focus.

A kernel maintainer can completely ignore any submission with no repercussions even in principle. And they often do.

In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#940

Post by mmooss »

steveklabnik wrote: post #912
mmooss wrote: post #906

Earlier quoted context omitted.

I got that - that's why I added the parenthetical. My point was the second sentence. Anyway, thanks for the input about the drivers. And for what it's worth, I expect Rust would offer significant improvements.

Ah, sorry, I misunderstood you. I don’t have a link handy, but Marcan had a post about how they actually re-wrote some in progress drivers from C to Rust because it was easier to do, and so didn’t expect a c version to exist. Basically it was about how driver complexity has increased over time, and Rust helps tackle that in a way that C can’t.

Yes, I realized later that I should add 'efficiency' (for development) to security and stability, which could also be a big win for Rust in particular.
Post reply on HN