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

381–390 of 1001 posts

Re: Resigning as Asahi Linux project lead

#381

Post by uecker »

joshkel wrote: post #354
cornstalks wrote: post #257

Earlier quoted context omitted.

As long as you compile with the version specified (e.g., `-std=c11`) I think backwards compatibility should be 100%. I've been able to compile codebases that are decades old with modern compilers with this.

In practice, C has a couple of significant pitfalls that I've read about. First is if you compile with `-Werror -Wall` or similar; new compiler diagnostics can result in a build failing. That's easy enough to work around. Second, nearly any decent-sized C program has undefined behavior, and new compilers may change their handling of undefined behavior. (E.g., they may add new optimizations that detect and exploit und…

Why not entirely wrong, the UB issues are bit exaggerated in my opinion. My C code from 20 years ago still works fine even when using modern compilers. In any case, our plan is to remove most of UB and there is quite good progress. Complaining that your build fails with -Werror seems a bit weird. If you do not want it, why explicitly request this with -Werror?

Re: Resigning as Asahi Linux project lead

#382

Post by knowitnone »

gkbrk wrote: post #259
cratermoon wrote: post #239

Earlier quoted context omitted.

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

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.

Re: Resigning as Asahi Linux project lead

#383

Post by attractivechaos »

cornstalks wrote: post #229
nindalf wrote: post #93

Marcan links to an email by Ted Tso'o ( https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed... ) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining…

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

Re: Resigning as Asahi Linux project lead

#384

Post by j45 »

It's awful that someone who is doing this kind of work as a volunteer experiences harassment for not making proprietary hardware work with open-source quickly enough.

"... I ended up traveling for most of the year, all the while having to handle various abusers and stalkers who harassed and attacked me and my family (and continue to do so)."

Re: Resigning as Asahi Linux project lead

#385

Post by flkiwi »

HankB99 wrote: post #160
bebop wrote: post #92

Earlier quoted context omitted.

I work for a company that is open source and has a large community. I blows my mind (and often aggravates me) how rude some people can be. For some reason people feel that it is appropriate to throw barbs in their issue reports. Please to everyone out there, if you find an issue and want to report it (hurray open source!) please be kind with your words. There are real people on the other side of the issue. Always rem…

> I blows my mind (and often aggravates me) how rude some people can be. That seems to be a general characteristic. I strive to be cheerful and helpful whenever I'm asking for something. I feel like (sadly) it sets me apart from the crowd and helps me to get what I'm asking for. And IAC, with so little effort on my part I may brighten someone else' day and that makes me happy. Just last week I asked housekeeping at a…

I always feel like I'm imposing, and I have to remind myself that there are people who are eager to hear what I have to say. I try to set up my issue reports with appropriate background, and I always volunteer to, for example, submit a PR for a documentation change if the resolution requires it. And I have had some of the most wonderful interactions with complete strangers who had an idea, built a tool for themselves, and found other people had the same need.

There's a broader topic of ... just be nice to people. It doesn't cost anything. It does reassure me that this universe has been struggling with this for decades upon decades--witness the Malvin and Jim scene in WarGames. "Remember when you told me to tell you when you were acting rudely and insensitively?"

Re: Resigning as Asahi Linux project lead

#386

Post by j45 »

nindalf wrote: post #93

Marcan links to an email by Ted Tso'o ( https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed... ) that is interesting to read. Although it starts on a polarising note ("thin blue line"), it does a good job of explaining the difficulties that Linux maintainers face and why they make the choices they do. It makes sense to be extremely adversarial about accepting code because they're on the hook for maintaining…

Perhaps merge requests should have to go through a process of learning the codebase first, and submitting increasingly more complex fixes before jumping to really complex requests.

It can be hard when solving your own acute issue - doing so doesn't mean it is the only fix or the one the project should accept.

Even if it's beneath someone's talent to have to do it, it is an exercise of community building.

Re: Resigning as Asahi Linux project lead

#387

Post by p_l »

cratermoon wrote: post #239
cornstalks wrote: post #229

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

Re: Resigning as Asahi Linux project lead

#388

Post by purplesyringa »

K0nserv wrote: post #312
jstimpfle wrote: post #224

Earlier quoted context omitted.

It's practically impossible to document all your assumptions in the type system. Attempting to do so results in code that is harder to read and write. You have a choice between code that statically asserts all assumptions in the type system but doesn't exist, is slow, or a pain to work with, and code that is beautiful, obvious, performant, but does contain the occasional bug. I am not against static safety, but there…

Encoding assumptions and invariants in the type system is a spectrum. Rust, by it's very nature, places you quite far along that spectrum immediately. One should consider if the correctness achieved by this is worth the extra work. However, if there is one place where correctness is paramount, surely it's the Linux Kernel. > [..]Attempting to do so results in code that is harder to read and write. > You have a choice…

> Encoding assumptions and invariants in the type system is a spectrum. Rust, by it's very nature, places you quite far along that spectrum immediately.

Compared to, say, dependent type systems, Rust really isn't that far along. The Linux kernel has lots of static analyzers, and then auxiliary typedefs, Sparse, and sanitizers cover a significant area of checks in an ad-hoc way. All Rust does is formalize them and bring them together.

And getting Rust into the kernel slowly, subsystem by subsystem, means that the formalization process doesn't have to be disruptive and all-or-nothing.

Re: Resigning as Asahi Linux project lead

#389

Post by School-Cotton »

sophacles wrote: post #348
School-Cotton wrote: post #234

Earlier quoted context omitted.

> Any backwards incompatibilities are explicitly opt-in through the edition system, or fixing a compiler bug. This is a very persistent myth, but it’s wrong. Adding any public method to any impl can break BC (because its name might conflict with a user-defined method in a trait), and the Rust project adds methods to standard library impls all the time.

That's just not true. If the user has defined on the struct and a trait also has the method name, the struct's impl is used. Multiple traits can have methods named the same too. https://play.rust-lang.org/?version=stable&mode=debug&editio...

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.

Re: Resigning as Asahi Linux project lead

#390

Post by adammarples »

School-Cotton wrote: post #320
mcherm wrote: post #296

Earlier quoted context omitted.

In the US, this is a reference to the belief that members of law enforcement should be loyal folirst to other members of law enforcement and only secondarily to the law. Or at least that is how I have always understood it.

It seems obvious that that’s not what Ted intended it to mean, since it wouldn’t even make sense in this context (the debate doesn’t really seem to be about whether maintainers should be loyal to other maintainers). A more charitable interpretation would be “we’re the only line of defense protecting something good and valuable from the outside world, so people should give significant weight to our opinions and decisi…

The thin blue line comes from the thin red line, where a line of British redcoats held back a heavy cavalry charge in the crimean war. I've always taken it to mean that police officers consider themselves soldiers holding the last line of defence against wild enemies. Which is itself a controversial and probably unhelpful way to think about your job as a police officer.
Post reply on HN