5 ms·

>Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor You're reading way too far into this. Linus has been publicly posit

• gauge_field 2y ago
  Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
• gary_0 2y ago
  Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.
  • starspangled 2y ago
    Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.
    • threatofrain 2y ago
      Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.
      • pjmlp 2y ago
        Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly. There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones. All gone. Also note that POSIX/UNIX certification requires a C compiler presence.
        • p_l 2y ago
          Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all. As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
          • pjmlp 2y ago
            Are you sure? https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ https://pubs.opengroup.org/onlinepubs/9699919799.2018edition... https://pubs.opengroup.org/onlinepubs/015967575/toc.htm https://pubs.opengroup.org/onlinepubs/015967575/toc.htm And copying this from UNIX 03, the most widespread certification, "A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards: Internationalized System Calls and Libraries Extended V3 Commands and Utilities V4 C Language V2 Internationalized Terminal Interfaces The product must be registered as conformant to the Product Standards prior to, or concurrent with, the UNIX 03 Product Standard registration."
            • deleted 2y ago
              [deleted]
            • p_l 2y ago
              Depends on exact level of conformance and options chosen: From POSIX 2017 edition https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ https://pubs.opengroup.org/onlinepubs/9699919799.2018edition... > On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99. If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional, 2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment. Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.
      • PedroBatista 2y ago
        That's my overall point of view too. Regardless of infinite technical discussions about one or another, if Alice and Bob can't live together than just don't get married. Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path. I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
        • d3Xt3r 2y ago
          I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS. If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
          • snvzz 2y ago
            Redox has stayed drama free so far. I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there. OTOH, please don't let Redox be taken over by problematic people.
            • gkbrk 2y ago
              Redox is drama-free because Redox has very few developers working on it. In the last 12 months, Redox had 7 contributors that touched more than 100 lines of code. Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.
        • scj 2y ago
          "In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd https://en.wikipedia.org/wiki/GNU_Hurd
      • starspangled 2y ago
        Yes, perhaps a C-only Linux would do that and die, and perhaps it would continue its customization of C flavor and runtime it uses (e.g., the various static and dynamic memory limitations and checkers) and closes the gap with Rust to a point where the incremental benefit of using it is not significant enough that it makes a Rust based competitor an inevitability. We may already be beyond that point, even.
        • Philpax 2y ago
          The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart. Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined. [0]: https://lwn.net/Articles/978738/ https://lwn.net/Articles/978738/
          • starspangled 2y ago
            > The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end. > Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart. Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC. > Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined. Yeah, it's not only safety improvements that are in Linux-C.
          • hulitu 2y ago
            > The changes required to bring C to a Rust level of safety cough* Cargo cough* /s You cannot have safety or security when you download your code from the internet and this code is a moving target.
      • coliveira 2y ago
        This is inevitable: Rust is proposed as a safe language, but there is no way to have a "half-secure" kernel. The only option for people who believe in Rust is to have its own kernel, and Linux should have no part on this.
        • whytevuhuni 2y ago
          > there is no way to have a "half-secure" kernel. There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces. In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code). Rust is used to make kernel drivers secure by providing a safe interface for them to use.
      • account42 2y ago
        Keeping the project single language doesn't mean that the project can't change. The C used today is not the same C used when when the project was started. Changing language is also possible. Using two different languages long-term however means that everyone effectively needs to be proficient in both languages and a lot of work is duplicated.
    • mort96 2y ago
      Would you say that C is "here to stay" in Linux? I would say so. I think you understood what was meant.
      • mu53 2y ago
        The drama is the problem, not rust. I don't know why, but either zealots choose rust or rust induces zealotry. Its exactly what Linus said.
        • mort96 2y ago
          I don't understand how this is related to what I said.
        • Aeolun 2y ago
          Of perfectly moderate Rust users get annoyed with C zealots?
          • account42 2y ago
            That might be an argument if those C zealots were trying to add their language to a Rust project. Don't play in someone else's back yard and then complain that their are not pampering you enough.
        • ksec 2y ago
          >. I don't know why, but either zealots choose rust or rust induces zealotry. That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots. However that doesn't happen with Ada. So that cant be the full explanation.
      • starspangled 2y ago
        No I wouldn't say that. If Rust or another language eventually proved itself more value than C and things were eventually all rewritten, C would go away. For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.
    • winocm 2y ago
      DEC Alpha support is somehow still in the mainline Linux kernel...
      • sho_hn 2y ago
        Slowly getting removed: https://lore.kernel.org/lkml/e8612e21-4ea4-4e6f-8c73-9fbee11bf289@app.fastmail.com/T/#m48242a03ae584715edb4274247b2fbcd3d104ef3 https://lore.kernel.org/lkml/e8612e21-4ea4-4e6f-8c73-9fbee11...
        • winocm 2y ago
          To be fair, anything that does not support BWX is really painful to deal with. Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like: bic a0, #3, t1 and a0, #3, t4 ldl t2, (t1) insbl a1, t4, t3 mskbl t2, t4, t2 bis t2, t3, t2 stl t2, (t1) ret zero, (ra) But with BWX, it becomes: stb a1, 0(a0) ret zero, (ra)
      • starspangled 2y ago
        Yeah m68k is still around too and it has more than a decade on alpha. People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.
        • winocm 2y ago
          I guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66). I'm not sure if Alphas are even being made anymore, even 15-20 years ago.
        • Locutus_ 2y ago
          M68k has the advantage that it has a fairly typical memory model. Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-) And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive. Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
• cycomanic 2y ago
  The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.
  • gary_0 2y ago
    > by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.
    • chikere232 2y ago
      This seems like black and white thinking. There's a huge spectrum between > "suck it up, buttercup" or "I hear you; rust is gone". where various levels of compromise happens. Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting
  • tomnipotent 2y ago
    > that's a strategy decision that should not be up to any subsystem maintainer So people are not allowed to hold positions and argue for them in public, or take actions that align with that position? > I don't believe that was what the rust guys thought they'd be signing up for It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.