6 ms·

No. Stop it. I don't want to hear that we should be re-writing all of our systems code in Rust, or that Oberon and the Wirth family should have won, or that C i

No. Stop it. I don't want to hear that we should be re-writing all of our systems code in Rust, or that Oberon and the Wirth family should have won, or that C is crap, and Linux should die, and be re-written, or that this wouldn't have happened if we had all just adopted the Lisp Machine. We've all heard it already, we all know what you'll say. So skip the smug post, and go do something productive. Like writing a really cool piece of new code, or fixing a use-after-free, or posting something more insightful, or inventing a new type of shoelace that doesn't come untied until you want it to.

nine_k 10y ago
Instead of fixing a particular use-after-free, how about making use-after-free impossible?
- walter_bishop 10y ago
  > Instead of fixing a particular use-after-free, how about making use-after-free impossible? Yes .. Does this vulnerability work only on a particular architecture?
  - mark4o 10y ago
    The bug is architecture independent, although a particular exploit may work only on a specific architecture.
- otterley 10y ago
  At what cost to performance? Very rarely are there solutions that exist without tradeoffs.
  - johncolanduoni 10y ago
    Many verification systems can understand virtually any proof you can throw at them, so any memory management scheme for which you have a rigorous argument for correctness should be able to operate with no additional runtime overhead. And if you don't have such an argument, you've already lost no matter what language you use.
  - AstralStorm 10y ago
    The main cost to performance is related to multicore proofs. It is an open question on how to work out complete proofs of multithreaded operations. This is why seL4 does not support internal SMP. You can run an instance per core and assign it a separate memory space like to a VM though.
- qwertyuiop924 10y ago
  Great. Instead of telling us, most of whom already know, about it, go do it.
kardashian007 10y ago
There are no unicorn solutions, however being religously blind to potential net value of fallible but potentially better interoperable alternatives would be irrational. Any rewrite cannot likely be accomplished in one pass (without some really smart code transpiler), but would more likely occur on a gradual migration todo list with a bidirectional interoperable language. The evaluation of such languages would likely involve requesting necessary features such as freestanding compilation, performance profiling/tracing tools and debugger integration, proofs of correctness and GC-less operation, among others. It's not impossible but it would need to be demonstrated that the perceived immense cost is significantly offset by the perceived immense value over "doing things as they've always been done."
- swsieber 10y ago
  And it definitely could be done in one pass because bugs like this do exist, and the language we want to port to should prevent them.
geofft 10y ago
The smug replies on this comment seem to be the ones saying "Don't tell me about Rust". So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? I've been a C++ and C developer for a long time and have been waiting for some safer language that lets me do what I've been doing in those languages. Knowing that Rust was a realistic option was what inspired me to learn it and write new things in it. If that happens at scale, that's how we actually get things written in a memory-safe language.
- sirtaj 10y ago
  > So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? The Linux kernel didn't get written because people on a forum said "we need to write a complete open source reimplementation of the UNIX kernel," but because Torvalds just went ahead and wrote it. Most things in F/OSS work that way.
  - geofft 10y ago
    GNU had a whole manifesto, though. https://www.gnu.org/gnu/manifesto.en.html https://www.gnu.org/gnu/manifesto.en.html (Although, yes, a signifiant body of software existed when the manifesto was published.)
    - Natsu 10y ago
      Linus Benedict Torvalds 8/25/91 Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...
  - falcolas 10y ago
    I imagine the project is big enough now that anyone who would undertake it would want to be compensated for it. And since that is unlikely to ever pass the cost/benefit ratio for any given corporation, it's unlikely to happen. Not to mention the potential for alienating of the entire existing kernel development group. It would be much easier to submit patches to slowly upgrade the kernel to a memory safe language, but that would require a lot of political savvy to push through, also making it an unlikely path to be taken. Ultimately, you'd have to convince Linus of the merits, and we all know how much he likes complex languages.
xenadu02 10y ago
"The revolution will not be televised". The beginning of the end of use-after-free, buffer overflows, stack smashers, et al will be when we as a community finally accept that C is a terrible language, impossible for ordinary humans to reason about, and must be abandoned. Only when we begin to accept that truth will we all get serious about moving away from it. For many years the response has been that "C is fine" or some variant of "humans will be better programmers in the future" both of which are demonstrably false. No one questions the wisdom of paramtaraizing SQL. No one questions the wisdom of not writing your own crypto. Yet despite the mountains of evidence, wasting billions (yes BILLIONS) of man-hours and dollars, and even lives lost there is still resistance to the idea that C needs to die ASAP. So as long as there are posts like yours our job of educating and persuading isn't finished and that's extremely important if we have a hope of actually making this desperately needed change. If you still doubt let me go ahead and make a prediction: before the end of the year there will be another RCE exploit in the Linux kernel discovered and a different one will be written, code-reviewed, and committed but not discovered until later (but within 5 years). I'm happy to put $1,000 on this wager.
- crististm 10y ago
  Actually, it is still possible to use C as a higher than assembly target language for compilers.
  - MaulingMonkey 10y ago
    While I'm really interested in this for making languages available everywhere (tm), basic things like signed integer overflow being undefined behavior make me question is C is fit for purpose even here.
    - jjnoakes 10y ago
      Since you are generating the C code, you can generate the appropriate checks where needed to avoid such undefined behavior too.
      - 10y ago
topspin 10y ago
Well that's the thing about C and its ilk; it is an endless wellspring of awful failures and so the voices you are trying to shout down have an unlimited supply of ammo. This will keep happening and you're going to keep hearing about it and the arguments for alternatives will continue to strengthen. That's the reality to which you need to adapt, if you're a reasonable person. The advocates of these alternatives aren't creating this situation. The unavoidable fact is that our traditional tools have a propensity to propagate bugs that are fabulously difficult to discover. That's one of the lessons of nearly a half century of C. New tools are emerging that solve this problem and their advocates have every reason to say so. Another lesson C teaches us through its popularity and longevity is that performance will always be critical for systems code; there will never be a day when we can squander cycles and RAM on garbage collectors and reference counts and indirections and all the other bookkeeping and abstractions inherent to so many languages that have utterly failed to displace C for systems programming. I don't know what the future looks like. Maybe it's Rust. Maybe Linus will get fed up and invent a better language in 4 days. Maybe someone will create an AI system that can spot this sort of bug before it ever gets checked in. All I know for sure is that the current situation is intolerable and yelling at people to shut up about it won't work.
- zigzigzag 10y ago
  I don't know about that - very little software is written in C these days. Even parts of the Windows and Mac kernels are written in at least C++ and Microsoft had an entire OS written in C# internally. Meanwhile the games industry has been C++ since forever (which still isn't great but better than C) and most business and web software is written in GCd languages. BTW the kernel is full of reference counts.
  - johncolanduoni 10y ago
    > BTW the kernel is full of reference counts. I think the OP is pointing to languages like Swift/Objective-C where reference counts are used even if you don't really need them, not that ever reference counting anything is a lazy abstraction.
- qwertyuiop924 10y ago
lmm 10y ago
This is a discussion forum, of course you're going to find talking rather than doing here. Once there's a firm consensus that it's time to move away from C we'll probably stop talking about it. But that consensus has to develop through discussion and argument here and elsewhere (and if you look at the conversations now compared to a year or two ago, I'd say we've made a lot of progress). If you don't believe there's value in talking about technical issues then what are you even doing here?
- meanduck 10y ago
  I guess GP is refering to repetitiveness of same arguments. A tree thread is good for discovery but not so good for reaching a conclusion/consensus. Flat/linear thread should be used instead.
- qwertyuiop924 10y ago
  There's actually a pretty solid consensus here. I'm the only one I've seen arguing about C, and even I agree that it should be moved away from with these sorts of codebases. It's the rest of the world which doesn't have a consensus. You're welcome to post, of course. I'd just rather you not. There's no sense preaching to the choir.
  - anonymousiam 10y ago
    If I understood you correctly, you are suggesting that the Linux kernel codebase should move away from C. What I missed was your suggested replacement and the rationale for it. Thanks.
falcolas 10y ago
I'll add to this. Before you can even begin championing your language for kernel development, make sure it can compile to all of the same architectures that C can. Make sure that programs written in your language are as space and time efficient as the equivalent C programs. These are things you can do today, if you feel strongly enough about this cause. Once your language is at that point, then start building up your arguments to convince Linus and the majority of the core kernel developers that your language is the right choice for continued development. Until these occur, it's all just pointless speculation.
- zzzcpan 10y ago
  > to convince Linus and the majority of the core kernel developers The biggest cost is not them, it's every other C programmer, every other company, the whole industry. It's unrealistic to even think that any significant part of them is going to invest resources into another language just to gain memory safety.
  - falcolas 10y ago
    I figure, if you're capable of coming up with an argument which convinces Linus to move away from C, you can use that logic to convince anybody (who is capable of being convinced by logic in the first place).

nine_k 10y ago

Instead of fixing a particular use-after-free, how about making use-after-free impossible?

walter_bishop 10y ago
> Instead of fixing a particular use-after-free, how about making use-after-free impossible? Yes .. Does this vulnerability work only on a particular architecture?
- mark4o 10y ago
  The bug is architecture independent, although a particular exploit may work only on a specific architecture.
otterley 10y ago
At what cost to performance? Very rarely are there solutions that exist without tradeoffs.
- johncolanduoni 10y ago
  Many verification systems can understand virtually any proof you can throw at them, so any memory management scheme for which you have a rigorous argument for correctness should be able to operate with no additional runtime overhead. And if you don't have such an argument, you've already lost no matter what language you use.
- AstralStorm 10y ago
  The main cost to performance is related to multicore proofs. It is an open question on how to work out complete proofs of multithreaded operations. This is why seL4 does not support internal SMP. You can run an instance per core and assign it a separate memory space like to a VM though.
qwertyuiop924 10y ago
Great. Instead of telling us, most of whom already know, about it, go do it.

kardashian007 10y ago

There are no unicorn solutions, however being religously blind to potential net value of fallible but potentially better interoperable alternatives would be irrational. Any rewrite cannot likely be accomplished in one pass (without some really smart code transpiler), but would more likely occur on a gradual migration todo list with a bidirectional interoperable language. The evaluation of such languages would likely involve requesting necessary features such as freestanding compilation, performance profiling/tracing tools and debugger integration, proofs of correctness and GC-less operation, among others. It's not impossible but it would need to be demonstrated that the perceived immense cost is significantly offset by the perceived immense value over "doing things as they've always been done."

swsieber 10y ago
And it definitely could be done in one pass because bugs like this do exist, and the language we want to port to should prevent them.

geofft 10y ago

The smug replies on this comment seem to be the ones saying "Don't tell me about Rust". So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? I've been a C++ and C developer for a long time and have been waiting for some safer language that lets me do what I've been doing in those languages. Knowing that Rust was a realistic option was what inspired me to learn it and write new things in it. If that happens at scale, that's how we actually get things written in a memory-safe language.

sirtaj 10y ago
> So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? The Linux kernel didn't get written because people on a forum said "we need to write a complete open source reimplementation of the UNIX kernel," but because Torvalds just went ahead and wrote it. Most things in F/OSS work that way.
- geofft 10y ago
  GNU had a whole manifesto, though. https://www.gnu.org/gnu/manifesto.en.html https://www.gnu.org/gnu/manifesto.en.html (Although, yes, a signifiant body of software existed when the manifesto was published.)
  - Natsu 10y ago
    Linus Benedict Torvalds 8/25/91 Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...
- falcolas 10y ago
  I imagine the project is big enough now that anyone who would undertake it would want to be compensated for it. And since that is unlikely to ever pass the cost/benefit ratio for any given corporation, it's unlikely to happen. Not to mention the potential for alienating of the entire existing kernel development group. It would be much easier to submit patches to slowly upgrade the kernel to a memory safe language, but that would require a lot of political savvy to push through, also making it an unlikely path to be taken. Ultimately, you'd have to convince Linus of the merits, and we all know how much he likes complex languages.

xenadu02 10y ago

"The revolution will not be televised". The beginning of the end of use-after-free, buffer overflows, stack smashers, et al will be when we as a community finally accept that C is a terrible language, impossible for ordinary humans to reason about, and must be abandoned. Only when we begin to accept that truth will we all get serious about moving away from it. For many years the response has been that "C is fine" or some variant of "humans will be better programmers in the future" both of which are demonstrably false. No one questions the wisdom of paramtaraizing SQL. No one questions the wisdom of not writing your own crypto. Yet despite the mountains of evidence, wasting billions (yes BILLIONS) of man-hours and dollars, and even lives lost there is still resistance to the idea that C needs to die ASAP. So as long as there are posts like yours our job of educating and persuading isn't finished and that's extremely important if we have a hope of actually making this desperately needed change. If you still doubt let me go ahead and make a prediction: before the end of the year there will be another RCE exploit in the Linux kernel discovered and a different one will be written, code-reviewed, and committed but not discovered until later (but within 5 years). I'm happy to put $1,000 on this wager.

crististm 10y ago
Actually, it is still possible to use C as a higher than assembly target language for compilers.
- MaulingMonkey 10y ago
  While I'm really interested in this for making languages available everywhere (tm), basic things like signed integer overflow being undefined behavior make me question is C is fit for purpose even here.
  - jjnoakes 10y ago
    Since you are generating the C code, you can generate the appropriate checks where needed to avoid such undefined behavior too.
    - 10y ago

topspin 10y ago

Well that's the thing about C and its ilk; it is an endless wellspring of awful failures and so the voices you are trying to shout down have an unlimited supply of ammo. This will keep happening and you're going to keep hearing about it and the arguments for alternatives will continue to strengthen. That's the reality to which you need to adapt, if you're a reasonable person. The advocates of these alternatives aren't creating this situation. The unavoidable fact is that our traditional tools have a propensity to propagate bugs that are fabulously difficult to discover. That's one of the lessons of nearly a half century of C. New tools are emerging that solve this problem and their advocates have every reason to say so. Another lesson C teaches us through its popularity and longevity is that performance will always be critical for systems code; there will never be a day when we can squander cycles and RAM on garbage collectors and reference counts and indirections and all the other bookkeeping and abstractions inherent to so many languages that have utterly failed to displace C for systems programming. I don't know what the future looks like. Maybe it's Rust. Maybe Linus will get fed up and invent a better language in 4 days. Maybe someone will create an AI system that can spot this sort of bug before it ever gets checked in. All I know for sure is that the current situation is intolerable and yelling at people to shut up about it won't work.

zigzigzag 10y ago
I don't know about that - very little software is written in C these days. Even parts of the Windows and Mac kernels are written in at least C++ and Microsoft had an entire OS written in C# internally. Meanwhile the games industry has been C++ since forever (which still isn't great but better than C) and most business and web software is written in GCd languages. BTW the kernel is full of reference counts.
- johncolanduoni 10y ago
  > BTW the kernel is full of reference counts. I think the OP is pointing to languages like Swift/Objective-C where reference counts are used even if you don't really need them, not that ever reference counting anything is a lazy abstraction.
qwertyuiop924 10y ago

lmm 10y ago

This is a discussion forum, of course you're going to find talking rather than doing here. Once there's a firm consensus that it's time to move away from C we'll probably stop talking about it. But that consensus has to develop through discussion and argument here and elsewhere (and if you look at the conversations now compared to a year or two ago, I'd say we've made a lot of progress). If you don't believe there's value in talking about technical issues then what are you even doing here?

meanduck 10y ago
I guess GP is refering to repetitiveness of same arguments. A tree thread is good for discovery but not so good for reaching a conclusion/consensus. Flat/linear thread should be used instead.
qwertyuiop924 10y ago
There's actually a pretty solid consensus here. I'm the only one I've seen arguing about C, and even I agree that it should be moved away from with these sorts of codebases. It's the rest of the world which doesn't have a consensus. You're welcome to post, of course. I'd just rather you not. There's no sense preaching to the choir.
- anonymousiam 10y ago
  If I understood you correctly, you are suggesting that the Linux kernel codebase should move away from C. What I missed was your suggested replacement and the rationale for it. Thanks.

falcolas 10y ago

I'll add to this. Before you can even begin championing your language for kernel development, make sure it can compile to all of the same architectures that C can. Make sure that programs written in your language are as space and time efficient as the equivalent C programs. These are things you can do today, if you feel strongly enough about this cause. Once your language is at that point, then start building up your arguments to convince Linus and the majority of the core kernel developers that your language is the right choice for continued development. Until these occur, it's all just pointless speculation.

zzzcpan 10y ago
> to convince Linus and the majority of the core kernel developers The biggest cost is not them, it's every other C programmer, every other company, the whole industry. It's unrealistic to even think that any significant part of them is going to invest resources into another language just to gain memory safety.
- falcolas 10y ago
  I figure, if you're capable of coming up with an argument which convinces Linus to move away from C, you can use that logic to convince anybody (who is capable of being convinced by logic in the first place).