7 ms·

Well the fact that C is going so strong guarantees we'll be dealing with easily preventable bugs for the next 100 years

by tray5 10y ago

pjmlp 10y ago
Sadly getting rid of C means getting rid of UNIX, as they are symbiotic and UNIX vendors will surely never rewrite them in anything else or replace POSiX standard.
- cellularmitosis 10y ago
  Really? Why can't the C bits be replaced with e.g. Rust?
  - ganfortran 10y ago
    Good Luck with your precious Rust to be compatible with your client's millions of lines of code. For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.
    - bluejekyll 10y ago
      Writing Rust off as flashy is demeaning to the excellent work that has been going on in the Rust ecosystem to specifically address the area you mention with a safe language alternative.
      - ganfortran 10y ago
        That doesn't make the OP's claim of rewriting 100 million of lines of code with Rust and that would solve the whole problem, sounds less stupider.
  - jacquesm 10y ago
    They could be. But you'd need a reason in order to be able to fund it (or maybe you just want to scratch an itch). But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements: - it really needs to be better in terms of bugs - it needs to be about as fast or faster - it would have to come with similar start-up times for the runtime - you'd need to find funding somewhere or convince people the need is so high they should volunteer their time For a single individual this is likely not a viable project, even doing just the basics (coreutils) would take you a couple of years at a minimum. What might be a better way is to reboot unix entirely starting from the kernel and working your way up into userland. There is plenty there that could use a more modern look at things, after all UNIX really is showing its age and LINUX is a re-implementation of something that was already old when it was started.
    - peterwwillis 10y ago
      The Linux ecosystem was created with the userland already having being rewritten from scratch, by the GNU Project. Then a Finnish student came along and wrote a kernel. So you can probably start anywhere, but maybe starting with a working kernel would be better. Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years.
      - jacquesm 10y ago
        > Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years. Hm. I'm not sure I see the similarities there. plan9: small, elegant, really an improvement on Unix in many respects but unfortunately somewhat theoretical rather than practically oriented. Linux: bloated, blunt, practically oriented, gets the job done but it never feels like it's the shortest path.
  - pjmlp 10y ago
    No because UNIX requires C semantics, so even if someone writes a UNIX like OS in Rust, Ada whatever language it might be, for compatibility with UNIX software it would require a POSIX API to be available. POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures. Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code. This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes. As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.
    - mjw1007 10y ago
      There used to be POSIX standards for both Ada and Fortran as well a C (POSIX.5 and POSIX.12). Though I don't think they can be described as successful. If I remember right, the Fortran one was defined in terms of the C one, but the Ada one was written as if it was an independent specification. I suppose this was only possible because POSIX misses out a lot of the fiddlier bits of Unix anyway (and the Ada one specified a spawn to use instead of fork+exec).
      - pjmlp 10y ago
        Yes I remember those, but you still have the safety problem. Let's say how does one make memcpy() safe in Ada? The very first step of converting the pointers + length into an access type must trust the caller did the right thing.
    - viraptor 10y ago
      I wouldn't say the OS requires unsafe POSIX compatibility. The whole system can be mostly unaware of POSIX if you can use the available APIs to create shims. Basically a wine equivalent - Linux didn't implement any windows APIs after all. So all the unsafe bits can exist only in the process which is based on them.
- rocqua 10y ago
  C and say, rust or c++ can interface. You don't need to rewrite, just stop writing extra stuff in C, maybe when you do a really big refactor in C, port it. In the end, we can migrate away from C gradually. That makes me wonder, is there any chance in hell we get some RUST in the Linux source code?
  - viraptor 10y ago
    Upstream? Likely never. Out of tree? https://github.com/tsgates/rust.ko/blob/master/README.md https://github.com/tsgates/rust.ko/blob/master/README.md
    - majewsky 10y ago
      I recall that Linus once said on the LKML that he could see himself accepting Rust code into the kernel. But I cannot find the source right now.
  - pjmlp 10y ago
    The problem isn't technical rather political. If you want to fix UNIX security issues related to C, first you need to convince kernel developers across all UNIX variants to move away from C. Then even a fully modernized UNIX kernel needs to provide support to unsafe POSIX APIs.
    - 0192380101 10y ago
      As we all know, Windows is totally secure, GUIs are awesome and the Burroughs architecture is unique.
      - pjmlp 10y ago
        See you already know, improving the world one person at a time.
  - bluejekyll 10y ago
    One issue that would make Rust more likely in Linux would be a GCC toolchain for Rust. I personally don't want to see fragmented development of the language, though. Perhaps a backend for MIR for GCC could be done? But, Linus et al still love C...
- voidlogic 10y ago
  Maybe, I think it would be possible to take a BSD or Linux (tech not a UNIX) and port the kernel space to Rust and user space to Go? Not all UNIXs are closed source.
  - jrobn 10y ago
    Might as well write it from scratch without POSIX and all the lessons we've learned since then. I think rust opens the door to designing kernels that are small and tight with most of the OS stuff that was traditionally in kernel space moved into user space.
    - cestith 10y ago
      Opens which door? Minix3 is microkernel based and userland compatible with NetBSD. XNU is originally based on the Mach microkernel and has part of FreeBSD bolted on. Both are open source, as are Mach proper and L4. Perhaps someone could start with Minix3 or Darwin rather than Linux or BSD or from scratch. Replace one component at a time in Rust, or D, or Ada...
      - jrobn 10y ago
        Easily machine verified kernels that have a high degree of having no security exploits because of buffer overruns or null pointer shenanigans etc...
    - bluejekyll 10y ago
      Checkout https://en.m.wikipedia.org/wiki/Redox_(operating_system) https://en.m.wikipedia.org/wiki/Redox_(operating_system)
  - cestith 10y ago
    Or maybe Minix3, XNU, L4, or Mach? http://www.minix3.org/ http://www.minix3.org/ https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/L4_microkernel_family https://en.wikipedia.org/wiki/L4_microkernel_family
adrianN 10y ago
Or moving to C is something so exceptional nowadays that it warrants an explanation and thus gets included in this matrix, whereas everybody and their dog thinks moving away from C is the most natural thing in the world and doesn't blog about it.
- tray5 10y ago
  If that were true wouldn't we see greater results from C to X? Seems like people are moving away from C less often than Java or even Python strangely enough
  - adrianN 10y ago
    Only if people using C are equally likely to blog as people using Java or Python.
peterwwillis 10y ago
C is a tadpole in the ocean of easily preventable bugs.
- tempodox 10y ago
  And when it grows up, it becomes the toad that is C++? I'm not sure I get your analogy. Besides, Real Programmers™ eat mutable state and NULL for breakfast.
  - bluejekyll 10y ago
    NULL is just macro for Cheerios...
- lmm 10y ago
  Then why do we see a major internet security bug that would be simply impossible in any other language every couple of months?
  - JustSomeNobody 10y ago
    Because the vast amount of C code running the internet. That's all. Rewrite everything in <language> and you'd see just as many security vulnerabilities.
    - lmm 10y ago
      I very much doubt that. Buffer overflows simply wouldn't happen in most languages, and those are the majority of the vulnerabilities we see.
      - f2f 10y ago
        XSS (cross-site scripting) replaced buffer overflows as the most common vulnerability in 2005. source: http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Years-of-Vulnerabilities-Research-Report.pdf http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Y...
JustSomeNobody 10y ago
All software has bugs. Any half arsed developer can create a lot of them in any language. C alone doesn't guarantee anything. Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back?
- omginternets 10y ago
  Yes, you're right. Tools don't matter at all. /s
  - JustSomeNobody 10y ago
    Not as much as understanding what you're writing and taking the time to write it correctly.
- tray5 10y ago
  >Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back? You make the serious mistake of assuming all or the majority of C devs know how powerful the language is, or how to properly use a language like C. All software has bugs, true. It's just that C bugs tend to be a wee bit more dangerous than a lot of other bugs because of the raw power of low level languages like C. Writing secure code in low level languages is tough, and it requires knowledge of all the pitfalls and nasty corners of the language, which many devs don't have the time, interest or desire to learn.

Well the fact that C is going so strong guarantees we'll be dealing with easily preventable bugs for the next 100 years

by tray5 10y ago

Well the fact that C is going so strong guarantees we'll be dealing with easily preventable bugs for the next 100 years

pjmlp 10y ago

Sadly getting rid of C means getting rid of UNIX, as they are symbiotic and UNIX vendors will surely never rewrite them in anything else or replace POSiX standard.

cellularmitosis 10y ago
Really? Why can't the C bits be replaced with e.g. Rust?
- ganfortran 10y ago
  Good Luck with your precious Rust to be compatible with your client's millions of lines of code. For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.
  - bluejekyll 10y ago
    Writing Rust off as flashy is demeaning to the excellent work that has been going on in the Rust ecosystem to specifically address the area you mention with a safe language alternative.
    - ganfortran 10y ago
      That doesn't make the OP's claim of rewriting 100 million of lines of code with Rust and that would solve the whole problem, sounds less stupider.
- jacquesm 10y ago
  They could be. But you'd need a reason in order to be able to fund it (or maybe you just want to scratch an itch). But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements: - it really needs to be better in terms of bugs - it needs to be about as fast or faster - it would have to come with similar start-up times for the runtime - you'd need to find funding somewhere or convince people the need is so high they should volunteer their time For a single individual this is likely not a viable project, even doing just the basics (coreutils) would take you a couple of years at a minimum. What might be a better way is to reboot unix entirely starting from the kernel and working your way up into userland. There is plenty there that could use a more modern look at things, after all UNIX really is showing its age and LINUX is a re-implementation of something that was already old when it was started.
  - peterwwillis 10y ago
    The Linux ecosystem was created with the userland already having being rewritten from scratch, by the GNU Project. Then a Finnish student came along and wrote a kernel. So you can probably start anywhere, but maybe starting with a working kernel would be better. Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years.
    - jacquesm 10y ago
      > Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years. Hm. I'm not sure I see the similarities there. plan9: small, elegant, really an improvement on Unix in many respects but unfortunately somewhat theoretical rather than practically oriented. Linux: bloated, blunt, practically oriented, gets the job done but it never feels like it's the shortest path.
- pjmlp 10y ago
  No because UNIX requires C semantics, so even if someone writes a UNIX like OS in Rust, Ada whatever language it might be, for compatibility with UNIX software it would require a POSIX API to be available. POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures. Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code. This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes. As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.
  - mjw1007 10y ago
    There used to be POSIX standards for both Ada and Fortran as well a C (POSIX.5 and POSIX.12). Though I don't think they can be described as successful. If I remember right, the Fortran one was defined in terms of the C one, but the Ada one was written as if it was an independent specification. I suppose this was only possible because POSIX misses out a lot of the fiddlier bits of Unix anyway (and the Ada one specified a spawn to use instead of fork+exec).
    - pjmlp 10y ago
      Yes I remember those, but you still have the safety problem. Let's say how does one make memcpy() safe in Ada? The very first step of converting the pointers + length into an access type must trust the caller did the right thing.
  - viraptor 10y ago
    I wouldn't say the OS requires unsafe POSIX compatibility. The whole system can be mostly unaware of POSIX if you can use the available APIs to create shims. Basically a wine equivalent - Linux didn't implement any windows APIs after all. So all the unsafe bits can exist only in the process which is based on them.
rocqua 10y ago
C and say, rust or c++ can interface. You don't need to rewrite, just stop writing extra stuff in C, maybe when you do a really big refactor in C, port it. In the end, we can migrate away from C gradually. That makes me wonder, is there any chance in hell we get some RUST in the Linux source code?
- viraptor 10y ago
  Upstream? Likely never. Out of tree? https://github.com/tsgates/rust.ko/blob/master/README.md https://github.com/tsgates/rust.ko/blob/master/README.md
  - majewsky 10y ago
    I recall that Linus once said on the LKML that he could see himself accepting Rust code into the kernel. But I cannot find the source right now.
- pjmlp 10y ago
  The problem isn't technical rather political. If you want to fix UNIX security issues related to C, first you need to convince kernel developers across all UNIX variants to move away from C. Then even a fully modernized UNIX kernel needs to provide support to unsafe POSIX APIs.
  - 0192380101 10y ago
    As we all know, Windows is totally secure, GUIs are awesome and the Burroughs architecture is unique.
    - pjmlp 10y ago
      See you already know, improving the world one person at a time.
- bluejekyll 10y ago
  One issue that would make Rust more likely in Linux would be a GCC toolchain for Rust. I personally don't want to see fragmented development of the language, though. Perhaps a backend for MIR for GCC could be done? But, Linus et al still love C...
voidlogic 10y ago
Maybe, I think it would be possible to take a BSD or Linux (tech not a UNIX) and port the kernel space to Rust and user space to Go? Not all UNIXs are closed source.
- jrobn 10y ago
  Might as well write it from scratch without POSIX and all the lessons we've learned since then. I think rust opens the door to designing kernels that are small and tight with most of the OS stuff that was traditionally in kernel space moved into user space.
  - cestith 10y ago
    Opens which door? Minix3 is microkernel based and userland compatible with NetBSD. XNU is originally based on the Mach microkernel and has part of FreeBSD bolted on. Both are open source, as are Mach proper and L4. Perhaps someone could start with Minix3 or Darwin rather than Linux or BSD or from scratch. Replace one component at a time in Rust, or D, or Ada...
    - jrobn 10y ago
      Easily machine verified kernels that have a high degree of having no security exploits because of buffer overruns or null pointer shenanigans etc...
  - bluejekyll 10y ago
    Checkout https://en.m.wikipedia.org/wiki/Redox_(operating_system) https://en.m.wikipedia.org/wiki/Redox_(operating_system)
- cestith 10y ago
  Or maybe Minix3, XNU, L4, or Mach? http://www.minix3.org/ http://www.minix3.org/ https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/L4_microkernel_family https://en.wikipedia.org/wiki/L4_microkernel_family

adrianN 10y ago

Or moving to C is something so exceptional nowadays that it warrants an explanation and thus gets included in this matrix, whereas everybody and their dog thinks moving away from C is the most natural thing in the world and doesn't blog about it.

tray5 10y ago
If that were true wouldn't we see greater results from C to X? Seems like people are moving away from C less often than Java or even Python strangely enough
- adrianN 10y ago
  Only if people using C are equally likely to blog as people using Java or Python.

peterwwillis 10y ago

C is a tadpole in the ocean of easily preventable bugs.

tempodox 10y ago
And when it grows up, it becomes the toad that is C++? I'm not sure I get your analogy. Besides, Real Programmers™ eat mutable state and NULL for breakfast.
- bluejekyll 10y ago
  NULL is just macro for Cheerios...
lmm 10y ago
Then why do we see a major internet security bug that would be simply impossible in any other language every couple of months?
- JustSomeNobody 10y ago
  Because the vast amount of C code running the internet. That's all. Rewrite everything in <language> and you'd see just as many security vulnerabilities.
  - lmm 10y ago
    I very much doubt that. Buffer overflows simply wouldn't happen in most languages, and those are the majority of the vulnerabilities we see.
    - f2f 10y ago
      XSS (cross-site scripting) replaced buffer overflows as the most common vulnerability in 2005. source: http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Years-of-Vulnerabilities-Research-Report.pdf http://maxedv.com/wp-content/uploads/2011/12/Sourcefire-25-Y...

JustSomeNobody 10y ago

All software has bugs. Any half arsed developer can create a lot of them in any language. C alone doesn't guarantee anything. Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back?

omginternets 10y ago
Yes, you're right. Tools don't matter at all. /s
- JustSomeNobody 10y ago
  Not as much as understanding what you're writing and taking the time to write it correctly.
tray5 10y ago
>Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back? You make the serious mistake of assuming all or the majority of C devs know how powerful the language is, or how to properly use a language like C. All software has bugs, true. It's just that C bugs tend to be a wee bit more dangerous than a lot of other bugs because of the raw power of low level languages like C. Writing secure code in low level languages is tough, and it requires knowledge of all the pitfalls and nasty corners of the language, which many devs don't have the time, interest or desire to learn.