Live data from Hacker News

Resigning as Asahi Linux project lead

marcan.st

971–980 of 1001 posts

Re: Resigning as Asahi Linux project lead

#971

Earlier quoted context omitted.

It must be said that from an outsider's point a view, in quite a few aspects it very much sounds like a cult. Get an HN article about C++, and you can be certain the comment section is going to deteriorate at some point into a religious war mentioning Rust. Get an article about Rust, and there is going to be drama in the comments. As a programmer that could potential consider Rust, it is off-putting.

Get an article about Rust, and there’s going to be comments about how drama, zealous Rust is from people that never use Rust. Regardless of its content. So yeah, typical internet houlier than thou reactions, I wouldn’t read much into them.

> Get an article about Rust, and there’s going to be comments about how drama, zealous Rust is from people that never use Rust.

Of course: You don't have to use Rust to see this very post here on HN, and quite a few other similar ones. Are you saying people just imagine there's a lot of drama around Rust, or what? (That TFA here or in other similar posts are all lies, or outright made-up?) Because to me -- who never use Rust -- it looks like a fact.

Which is a large contributing factor to why I probably never will, either.

Re: Resigning as Asahi Linux project lead

#972

Earlier quoted context omitted.

It must be said that from an outsider's point a view, in quite a few aspects it very much sounds like a cult. Get an HN article about C++, and you can be certain the comment section is going to deteriorate at some point into a religious war mentioning Rust. Get an article about Rust, and there is going to be drama in the comments. As a programmer that could potential consider Rust, it is off-putting.

You can also be certain when reading a Zig post you will see "Why would I use Zig over Rust?" or "Isn't Zig unsafe?" They cant help but proselytize. Its like talking to my recent born again christian friend who cant help but steer every conversation to Christianity and reciting scripture. It's infuriating. Though TBH it very much feels like the cult of OOP that rocked the 90's. And look where that paradigm is now ...

> Though TBH it very much feels like the cult of OOP that rocked the 90's. And look where that paradigm is now ...

It's alive and well. Sure, Java-style OOP might not be, but that's mainly because it was never sensible OOP to begin with.

A bit like "Agile is dead" and everybody hating "Agile". Sure, what they hate is what's been pushed as "Agile" for the last decade or more: ceremoniel-over-flexibility-Scrum, rigid sprints, "user story" as a synonym for "ticket", etc, etc.

Let's hope that it's just "Fauauxp" that, like Fauxgile, is about to be dead. ASAP.

Re: Resigning as Asahi Linux project lead

#973
post #305

Earlier quoted context omitted.

Its quite a well-known wisdom. I think someone in one of Nintendo or Sony's studios has said it too, in the form of: a complaint is worth twice a compliment. Satisfied customers will tell you they think your stuff is great, but dissatisfied customers will be able to hone in on exactly where the problem is. You can even extend this to personal life: if someone tells you your shabby car doesn't fit with the nice suits…

One does not "hone in" on anything. To hone a thing is to make it sharper or more acute by removing parts of it with an abrasive. The word you are looking for is "home", as in a homing missile, etc. Yes, this is a criticism. Hopefully it's twice as effective as being nice. 8)

You may not hone in on anything, but people who are better at English do.

This would be doubly ironic if you're a native English speaker. Are you?

Re: Resigning as Asahi Linux project lead

#974

Earlier quoted context omitted.

"All happy customers are alike; each unhappy customer is unhappy in its own way" - Tolstoy.

this isn't true, of course, but it sounds good

It's almost true, though, in a way: The only difference is, Tolstoy wrote "families", not "customers".

Re: Resigning as Asahi Linux project lead

#975
post #957

Earlier quoted context omitted.

It’s like how people complain about Apple users. You see more threads complaining about how annoying those Apple fanboys are than you see actual Apple fanboys being annoying.

I mean... Every HN thread with Apple discussion is pretty annoying. It might not be annoying to you as an Apple user, but for many of us it's unbearable...

Only a Sith deals in absolutes. I think blanket statements about a group like this are harmful and generally untrue

Re: Resigning as Asahi Linux project lead

#976
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.

> 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.

How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record.

And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it.

___

[1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.

Re: Resigning as Asahi Linux project lead

#977
post #43

Earlier quoted context omitted.

> Did you read the article? Did you read the rest of it? Sure Apple being not as great to develop drivers, but ~99% of the article is about displeasure working with Linux maintainers. EDIT: Here is the breakdown by paragraphs. | Paragraph # | Tone | | ----------- | -------------------------------------------------------------------------- | | 1 | History recap | | 2 | History recap | | 3 | mentions Apple and M1 in po…

All those "Negative user focused" are actually "Apple proprietary problems" (problems that exist only on apple because of their weird proprietary stuff with no standards following, ie, getting temp on any other system is dead simple). Not sure if you actually believe in your list or you just used an AI that made the mistake. I counted paragraphs topics myself: History (3), Proprietary Hardware Problems (8), Kernel/Ru…

> All those "Negative user focused"

No. Those are issues caused by users. You could have most open hardware platform, and it would still persist. See any OSS maintainer complaining about unrealistic user expectations.

> I counted paragraphs topics myself: Proprietary Hardware Problems (8), Kernel/Rust problems (8)

How are you counting those? I made a table, point me which exact paragraphs. Also it's deceptive to pull Rust into this story. marcan had nothing but praise for it, without it, he wouldn't be able to write those drivers.

The main complaint of marcan is the horrible experience you have as a hobbyist Linux contributor. You can't blame Rust or Apple for that. That's on Linus, and Linux maintainers.

Re: Resigning as Asahi Linux project lead

#978

Earlier quoted context omitted.

I agree that this is needed. It doesn't stop the person requesting the feature from asking for a meeting to explain why and just whining that they need it the whole time and saying they shouldn't have pay anything to get it addressed right now. Having in the person taking these meetings for a software vendor, it can get really toxic quickly and I never had more than 1 meeting a quarter with really toxic people and th…

> Having in the person taking these meetings for a software vendor, it can get really toxic quickly [...] hearing them out was part of the job Does it have to be a meeting? Although it's about sales calls, I'm reminded of https://keygen.sh/blog/no-calls/ (HN discussion: https://news.ycombinator.com/item?id=42725385 )

No, it doesn't have to be a meeting. It can be any method communication.

Re: Resigning as Asahi Linux project lead

#979

Earlier quoted context omitted.

Its sad that they chose Apple, instead of like investing time into the upcoming ARM laptops to make the Linux more optimized on them. That talent should not be wasted on tech jewelry.

I expect you are rage-baiting, but just in case you are not... Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?

Not rage bating. Im legitimately suprised by how many tech people hype up the MBP for no reason what so ever. If the laptops were half the price, they would be worth it from a tech perspective considering what you get.

>isn't it strictly better to have a way to run Linux on it

In a perfect world, Apple would open source the firmware, which would let people just compile the linux driver for it. While Asahi project is cool in terms of figuring stuff out, ultimately its a lost cause because Apple will never be on board.

Re: Resigning as Asahi Linux project lead

#980
post #387

Earlier quoted context omitted.

I'm curious now. What are the backwards compatibility guarantees for C?

For the purposes of linux kernel, there's essentially a custom superset of C that is defined as "right" for linux kernel, and there are maintainers responsible for maintaining it. While GCC with few basic flag will, in general, produce binary that cooperates with kernel, kbuild does load all those flags for a reason.

> For the purposes of linux kernel, there's essentially a custom superset of C that is defined as "right" for linux kernel

Superset? Or subset? I'd have guessed the latter.

Post reply on HN