So let me be very clear: if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG.
I wish it happened before this all blew over but I agree with the sentiment
I too put my feet down. Daily.
Some people pay for that you know, make sure to cash in!
Well, would you look at that, after all forcing things to be discussed and bringing them to the news and social is actually a good thing to get more clear things when there’s problems.
I don’t see how that follows. Linus wanted to see how the discussion went on the mailing list. I doubt he wanted nor appreciated the negative media and social media attention.
I’m not really familiar with any of this, but if they want to keep this stuff private why bother to publish it on public mailing lists?
It is not about it being public. He just wants it on the mailing list.
The people subscribed to the mailing list are all people involved in or specifically interested in kernel development. The hope is that the conversations there will be less technical and less political. What he does not want is a bunch of social or political pressure from drive by opinion holders on social media (like us).
It is fine for us to be discussing there discussion here. But he wants the discussion to be had “there”.
The main place to have technical discussions, big and small, is on a public mailing list. So everyone in the world with proper qualifications can join any time. It’s a way to ensure the best ideas with, instead of the loudest voice, or the person with the best networking.
There’s no other place to have these discussions.
Exactly. Airing-out Hellwig’s successful attempt to sabotage Rust efforts (and it was successful, given that at least two important maintainers have already resigned) was good, actually.
Unfortunately, it seems that Linus doesn’t have the maturity to recognize that, and this cycle is likely to continue, barring something good and unforeseen happening.
so the social media publicity was required to resolve this issue?
do you realise the rust contributor quit after making everything public?
this was a technical issue that took Linus more than a week to check before making a clear decision
what you said is speculative nonsense
Nothing speculative about it. The substance of the problem (obstinate, crotchety baby that was blocking useful code) was ignored and Linus instead chose to wrongly focus on Marcan calling out the problem. There’s nothing wrong with people calling out toxic bullshit, and it seemed that social media was necessary for that in this case, yeah.
it was ignored for 5 days, hardly forever. does Linus’ SLA need to be quicker?
making things public loads the issue with political and social pressure making more damage to the project and everyone involved inevitable. it was made more toxic
the code would have made it in either way
You are really trying hard to contort things into things I didn’t say.
The people problem is being ignored, and it wasn’t until Linus was made aware of a technical justification for slapping Hellwig down that Linus focused his disapproval away from Marcan, who was rightly calling this out, to the person creating the problem.
And we lost at least three solid R4L devs, of which, Marcan was one, and there’s zero acknowledgement from Linus that fixating on Marcan rightly calling this shit out was wrong.
The people problem of letting obstinate babies block valid code for any non-technical reason still has not been addressed, and this will keep happening until that changes.
so now you say nothing has been resolved after all?
social media or not, we still have the:
people problem of letting obstinate babies block valid code for any non-technical reason
so when you said
Airing-out Hellwig’s successful attempt to sabotage Rust efforts was good, actually.
what you meant was, it didn’t do a damn thing
That’s not what any of that means. Your reading comprehension could use some work.
so the social media publicity was required to resolve this issue?
Certainly seems that way unfortunately.
you really think Linus would have ignored that email forever?
If the Rust guy hadn’t made a fuss? Absolutely.
I think it’s a positive cycle. There’s unfortunately a lot of emotion in kernel maintenance, and this attacks a huge part of it. Subsystem maintainers are maintainers, they don’t own the project, they just make sure the code stays in a good state. In other words, they serve the users.
Good on Linus, that’s a very fair answer.
Yeah… I kinda wish he had provided it before all those devs quit, though.
Of course, he might have kept silent as a test to see if the project can remain healthy without his active stewardship, which makes sense for such a large and important project. I’m sure he’s unimpressed by the result.
Yeah, maybe just a good steward quality-testing the Bus Factors?
The issue I see is that Greg did spoke in a way that would not undermind Linux leadership. If Linux was out, I’m sure Greg would have said stuff publicly much earlier.
That makes sense too. I guess it’s a very difficult balance to hit, for all concerned. I think a lot of the famous outbursts that happen on LKML are probably an inevitable side-effect of that balancing-act, and of maintainers being stretched in multiple directions.
Too little, too late. As usual.
Good reply
What the fuck is with the person in the email chain implying not all drivers can be written in Rust? Rust does literally everything C can, nothing stopping you from using unsafe properly to achieve that.
A more serious answer would be that Rust can’t be compiled to all targets. There is a lot of work to get Rust to compile with gcc though, which would help with this tremendously.
Gnu C has computed goto.
That’s a performance optimisation which llvm is likely to do for you anyways, jump tables aren’t exactly rocket science. Gazing into my crystal ball, might have to turn your enum variant
Foo(u8)with possible values 0…15 intoFoo0throughFoo15(or maybe betterFoo(EnumWith16Variants)) so that the compiler doesn’t have to evaluate code to figure out that it doesn’t need to NOP the rest of the jump range out, or bail out of generating a jump table, whatever it would do.But is it used in the kernel?
Longjmp? Not that the kernel uses that ofc.
Begone, vile creature, use
call/ccif you’re into that kind of stuff. What you’re doing might be consensual but it sure ain’t safe or sane. Unless you’re implementingcall/cc, then I forgive you, and extend my condolences.Longjmp in C is generally used for implementing exceptions or things of that sort, which is fine. Even Ada and Haskell have exceptions. C++ has them too, though maybe that doesn’t speak in their favor as much. Rust lacks them, but so far that seems to me to be a shortcoming in Rust. Even those wanting unwinding of error value checking through the entire call stack could look at the C++ deterministic exception proposal which is similar to Haskell’s ErrorT monad transformer.
This is worth reading about Haskell if such topics are of interest: https://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf
Anyway, Rust has its own sort of call/cc thing as far as I can tell (not sure), in its async runtimes. There is a coroutine switching scheme underneath that, amirite? Where do the call stacks for the different async tasks live and how are they allocated? I’ve been wondering, “Comprehensive Rust” doesn’t go into any detail about this.
Call/cc in its most general form is possibly evil, but delimited continuations, the most common use of call/cc, are perfectly cromulent as far as I know. My brain is not currently big enough to understand the topic but I’m going by some of Oleg Kiselyov’s old writings, probably linked from here: https://okmij.org/ftp/continuations/index.html
Rust lacks them, but so far that seems to me to be a shortcoming in Rust
I think it’s a benefit. In Rust, you have two options:
- panic - usually catchable with
catch_unwind()(some types are not), and should be used rarely, this isn’t try/catch - result - return a value that indicates an error, like a super fancy errno, but with monad semantics that force you to acknowledge it
This is good for a few reasons:
- “normal” errors are explicit in the return type; if a function doesn’t return a result, it can’t return errors
- outliers aren’t accidentally handled - since you shouldn’t be catching panics, you can rely on them to completely crash
- no need to instrument the code with unwinding logic in case something throws an exception, meaning a more efficient runtime
Where do the call stacks for the different async tasks live and how are they allocated?
The async runtime handles that. You’d need to look at the specific implementation to see how they handle it, the standard library only provides tools for dealing with async.
My understanding is that it works kind of like a generator, so any await call yields to the runtime, which resumes another generator. That’s an over simplification, but hopefully it’s close enough.
Call/cc
I think this is basically just the general idea of a generator, but the caller chooses where the yield yields to.
I agree with the criticisms of call/cc, and I think it’s much clearer to just use coroutines (of which generators are a special case) and otherwise linear control flow instead of messing about with continuations. IMO, the only people that should mess with continuations are lower level engineers, like driver authors, compiler devs, and async lib devs. Regular devs will just create more problems for themselves.
- panic - usually catchable with
async is stackless coroutines, less powerful than stackful ones and vastly less powerful than first-class continuations, which is what call/cc provides, but also way more performant as there’s basically zero memory management overhead…
Where do the call stacks for the different async tasks live and how are they allocated?
That’s the neat thing: They aren’t, futures don’t contain their stack the compiler infers, statically, what they will need, and put that in a struct. As said, practically zero memory overhead.
First-class continuations aren’t evil they’re naughty, dirty only if used when not actually making anything clearer. Delimited continuations are actually a generalisation of call/cc and arguably way easier to think about, it’s just that call/cc predates their discovery and made it into standard lisp and scheme, where is that Felleisen paper, here: 1988. 13 years after scheme, 28 after lisp. longjmp/setjmp exist since at least System V and C89 according to the linux man pages, I guess they implemented it to implement lisp in. It’s just that C is about the worst language to use when you’re writing anything involving continuations, everything gets very complicated very fast, and not because continuations are involved but because you have no gc, no nothing, to support you.
Scheme has call/cc but standard Lisp (i.e. Common Lisp) doesn’t. Hmm, Rust async is like C++20 coroutines, so they can only yield from the outermost level of the task etc.? (Added: C Protothreads also come to mind). That sounds constraining even compared to the very lightweight Forth multitaskers of the 1970s. Python’s original generators were like that, but they fixed them later to be stackful coroutines. ~
And do you mean there is something like a jump table in the async task, going to every possible yield point in the task, such as any asynchronous i/o call? That could be larger than a stack frame, am I missing something?~ (No that wouldn’t be needed, oops).Setjmp/longjmp in C had some predecessor with a different name, that went all the way back to early Unix, way before C89. It was routinely used for error handling in C programs.
I’ve implemented Lisp (without call/cc) in C using longjmp to handle catch/throw. It wasn’t bad. Emacs Lisp also works like that.
I had been pretty sure that delimited continuations were strictly less powerful than first-class continuations, but I’ll look at the paper you linked.
I found some search hits saying you were supposed to implement signal handlers in Rust by setting a flag in the handler and then checking it manually all through the program. Even C lets you avoid that! It sounds painful, especially when there can be asynchronous exceptions such as arithmetic error traps (SIGFPE) that you want to treat sanely. But I haven’t looked at any Rust code that does stuff like that yet.
Hmm, I wonder if it’s feasible to use the Boehm garbage collection method in Rust, where the unsafe region is limited to the GC itself. Of course it would use pointer reversal to avoid unbounded stack growth. Of course I don’t know if it’s feasible to do that in Ada either.
Holy moly that is a
manpage of a roast. Linus has gotten extremely good at making himself clear while maintaining his temper just enough.His argument is applicable to much of FLOSS: your code and contributions you have say over, but you can’t complain about how people used your FLOSS code endpoints downstream. In exchange, any changes you make are the accessors’ responsibility to keep up with.
Exactly. I loved his irate rants before, but this is much more respectful but just as effective. Keep it up Linus.
Not a follower of kernel development, but I agree with Linus. The latest drama is just full of unprofessional toxicity (from both sides).
Linus had said for years that he wants to see Rust in some form in the kernel. You might not like it, but sometimes you just have to disagree and commit.
