3 ms·

> wait till you find out about the linux kernel Check the extent to which this is true. Also are we rewriting good kernel code that works?

by groundzeros2015 11mo ago

IshKebab 11mo ago
> good kernel code that works The fallacy here is that code is either "good code that works" or "bad code that needs to be rewritten". It doesn't work like that. "If it aint broke don't fix it" is actually terrible advice.
- burnt-resistor 11mo ago
  Yep, nuance is definitely needed. The greater issue is orthogonal: pushing out unfinished and incompatible code as production-usable rather code written in another language. Rust, by itself, isn't a panacea to add formal verification but one leg on the footstool of formal verification methodologies to produce safe(r/ish) software rather than subtly buggy software that's difficult to prove correct and more expensive to maintain. "If it aint broke don't fix it" =~= "I've never gotten into an accident until now, so airbags and seatbelts are pointless." ==> reactive methodology / failure / hubris
  - groundzeros2015 11mo ago
    The seat belt analogy makes no sense. The new tools have entirely new vulnerability and problems.
- groundzeros2015 11mo ago
  > If it aint broke don't fix it" is actually terrible advice. We want to give up good things to get better things. What is the vision for improving these tools with rust? What user benefit are they promising? I’ve heard nothing but nebulous arguments about memory or security purity. There is no insight into how to do them better or faster; and in most cases they have demonstrated they didn’t even understand them fully to begin with, such as missing locales. There isn’t even subjective value for users demanding it, it’s driven by rust developers.
  - estebank 11mo ago
    > What user benefit are they promising? From their README, they promise better error messages, extensions when relevant (example: --progress), and Linux, macOS, Windows and other platforms support. It is my understanding that the GnuWin32 coreutils were last updated in 2017 and had some subtle differences to regular GNU coreutils, so that's one set of users for whom there's clear benefit. Faster speed could be accomplished if architectural changes are viable, but for many of these tools they are IO-bound.
kachapopopow 11mo ago
this has nothing to do with rust, kernel regulary ships rather experiemental features in some of the releases, there is a reason why only specific kernel versions become LTS
- pseudalopex 11mo ago
  > kernel regulary ships rather experiemental features in some of the releases Does the Linux kernel ship with rather experimental features as default? When was the rule not to break user space revoked?
  - kachapopopow 11mo ago
    userspace doesn't get broken, you just kernel panic or experience severe slowdown due to some bug (like the one that existed on 6.18 and was fixed in 6.18.1 - not sure what the exact bug was, but updating to 6.18.1 made it go away.
    - pseudalopex 11mo ago
      > Does the Linux kernel ship with rather experimental features as default?

> wait till you find out about the linux kernel Check the extent to which this is true. Also are we rewriting good kernel code that works?

IshKebab 11mo ago

> good kernel code that works The fallacy here is that code is either "good code that works" or "bad code that needs to be rewritten". It doesn't work like that. "If it aint broke don't fix it" is actually terrible advice.

burnt-resistor 11mo ago
Yep, nuance is definitely needed. The greater issue is orthogonal: pushing out unfinished and incompatible code as production-usable rather code written in another language. Rust, by itself, isn't a panacea to add formal verification but one leg on the footstool of formal verification methodologies to produce safe(r/ish) software rather than subtly buggy software that's difficult to prove correct and more expensive to maintain. "If it aint broke don't fix it" =~= "I've never gotten into an accident until now, so airbags and seatbelts are pointless." ==> reactive methodology / failure / hubris
- groundzeros2015 11mo ago
  The seat belt analogy makes no sense. The new tools have entirely new vulnerability and problems.
groundzeros2015 11mo ago
> If it aint broke don't fix it" is actually terrible advice. We want to give up good things to get better things. What is the vision for improving these tools with rust? What user benefit are they promising? I’ve heard nothing but nebulous arguments about memory or security purity. There is no insight into how to do them better or faster; and in most cases they have demonstrated they didn’t even understand them fully to begin with, such as missing locales. There isn’t even subjective value for users demanding it, it’s driven by rust developers.
- estebank 11mo ago
  > What user benefit are they promising? From their README, they promise better error messages, extensions when relevant (example: --progress), and Linux, macOS, Windows and other platforms support. It is my understanding that the GnuWin32 coreutils were last updated in 2017 and had some subtle differences to regular GNU coreutils, so that's one set of users for whom there's clear benefit. Faster speed could be accomplished if architectural changes are viable, but for many of these tools they are IO-bound.

kachapopopow 11mo ago

this has nothing to do with rust, kernel regulary ships rather experiemental features in some of the releases, there is a reason why only specific kernel versions become LTS

pseudalopex 11mo ago
> kernel regulary ships rather experiemental features in some of the releases Does the Linux kernel ship with rather experimental features as default? When was the rule not to break user space revoked?
- kachapopopow 11mo ago
  userspace doesn't get broken, you just kernel panic or experience severe slowdown due to some bug (like the one that existed on 6.18 and was fixed in 6.18.1 - not sure what the exact bug was, but updating to 6.18.1 made it go away.
  - pseudalopex 11mo ago
    > Does the Linux kernel ship with rather experimental features as default?