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

941–950 of 1001 posts

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

#941

Post by steveklabnik »

HacklesRaised wrote: post #938

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…

Hi! I’m a Rust developer. The kernel should include whatever languages they want to include. I’m in the same reality as you.

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

#942

Post by gigatexal »

ddtaylor wrote: post #409
gigatexal wrote: post #364

I don't have anything to add regarding the Hector v. Linus debate, who was in the wrong, who was in the right, who's to blame etc... All I want to know is what's the long term viability of Asahi Linux or Linux for that matter on M series chip'd Macs? What's the burden going to be for Fedora Asahi if the work remains out of tree? Has Redhat/IBM stated they'll support it via the Fedora project going forward? What if th…

I think right now Marcan can work magic and reverse these chips and other pieces. Long term it's an arms race and Apple has other motivations to lock the platform down further. They may even get told to make it compatible, but they seem to be willing to maliciously comply with those directives. I am reminded of the Beeper messenger stuff. Like it's cool when people hack these things together to do stuff, but the comm…

Some other devs from the project have stepped up to coordinate getting their work into the kernel!

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

#943

Post by DrillShopper »

dfedbeef wrote: post #835
DrillShopper wrote: post #308

Earlier quoted context omitted.

The kernel dev process is more pathological than what I deal with at $DAYJOB. Why the hell would I wish that upon myself?

A stable career where you can move to any of the companies who have a dependency on your subsystem.

But I already have that

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

#944

Post by stonogo »

mort96 wrote: post #923
stonogo wrote: post #921

Earlier quoted context omitted.

Go on?

Then complaining about that on social media is going to sound a lot like "the leader of this subsystem is sabotaging this thing I'm involved with"

Right, and phrased just like that, it wouldn't have been as objectionable. As I said before, the problem is in the specificity and the direct linking to the conversation. I still take issue with the word 'sabotage' being used here, since the person in question didn't do anything except express objections and an intent not to cooperate. Since this was in a context where that person's cooperation is not needed, I'm not sure he sabotaged anything.

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

#945

Post by matu3ba »

pornel wrote: post #887
matu3ba wrote: post #792

Earlier quoted context omitted.

> We don't have a Rust-killer language yet. The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr . One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system. Retroactively patching C to have namespaces will not work and same holds for generic…

There was also Cyclone before Rust, and Checked-C in the meantime. The concepts like regions and affine types existed long before Rust, and Rust started out by copying from older languages ( http://venge.net/graydon/talks/intro-talk-2.pdf ). It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling…

Yes, I do agree with you. Just wanted to inform you that it may still be possible in principle and as you can see with development speed, build system, dependencies etc there is a potential angle.

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

#946

Post by surajrmal »

andrewstuart wrote: post #552
tadfisher wrote: post #318

Earlier quoted context omitted.

Do you feel the same about Make, Device Tree, KConfig, Python, the myriad of machine-specific assembly, POSIX shell, Perl, and every other non-C language currently in the code base?

No, I feel this way about the Linux kernel.

Those all exist in the Linux kernel repository. Granted they are not overlapping with c in their purpose for the most part.

One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.

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

#947

Post by armitron »

tsimionescu wrote: post #762
chikere232 wrote: post #642

Earlier quoted context omitted.

It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary. Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that

Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.

There are no Rust bits anywhere outside drivers, and hopefully that will continue to be the case. This means that mainline Linux kernel has no hard dependency on Rust whatsoever, which also means that Rust can be excised at any point with a minimum of effort.

I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.

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

#948

Post by surajrmal »

Filligree wrote: post #930
f1shy wrote: post #774

Earlier quoted context omitted.

Is it impossible to just delete the rust parts and go back to pure C? That ship could come back to port anytime.

I would quite like my laptop to keep working, and half its drivers are rust…

The Linux drivers can be maintained in a downstream fork. Ultimately that seems to be what upstream wants, unfortunate as that may be.

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

#949

Post by surajrmal »

tsimionescu wrote: post #875
f1shy wrote: post #774

Earlier quoted context omitted.

Is it impossible to just delete the rust parts and go back to pure C? That ship could come back to port anytime.

That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level. Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for t…

The kernel doesn't really have a better system mechanism for having these sorts of decisions made unfortunately.

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

#950

Post by arp242 »

samus wrote: post #578
arp242 wrote: post #218

Earlier quoted context omitted.

People forget things etc. Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"

Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.

> exactly the sort of problem that doesn't happen with a Github issue/PR

What? PRs or issues being forgotten happens all the time, especially for large projects.

Post reply on HN