3 ms·

Theo has addressed this directly. I cannot find the video at the moment - it is somewhere on YouTube - but his response essentially is okay, so where is 'cat'?

Theo has addressed this directly. I cannot find the video at the moment - it is somewhere on YouTube - but his response essentially is okay, so where is 'cat'? Where is 'grep'? Where is Korn Shell? Everyone is busy jumping up and down and bitching about reinventing the wheel in Rust but no one has even taken the time to rewrite the simplest of Unix tools in Rust. Not to mention OpenBSD has a rule that "base builds base" and the Rust compiler is a bloated monster that would fail that most basic task. So where is the benefit?

fc417fc802 2y ago
The worst part is when you come across something advertised as a replacement and it does something like 80% to 90% of what the original does with a WONTFIX for the rest. That can certainly be a valid choice in some cases, but for core tooling it's not realistic to expect widespread replacement to happen in that scenario.
ptman 2y ago
https://github.com/uutils/coreutils https://github.com/uutils/coreutils Parent wasn't about rust specifically. Just something safer than C
- oguz-ismail 2y ago
  > uutils Under development for longer than a decade and still unstable
  - tazjin 2y ago
    The website says "production ready" for their coreutils. Maybe catching up to 40+ years of development takes a little bit of time?
    - dpassens 2y ago
      > Maybe catching up to 40+ years of development takes a little bit of time? Sure. But that's not OpenBSD's problem, is it?
    - IcePic 2y ago
      Which is the point. 40 years of development is 40 years of development.
  - dijit 2y ago
    “put up or shut up” is a valid response. Someone is “putting up”, just need someone to merge uutils and the OpenBSD kernel to see what it starts to look like. Maybe this is the next part of the “put up or shut up” mantra- but we’re getting closer. The parents irony is not lost though. C and perl are both quite dangerous in their own ways, lots of implicit assumptions; its ironic that a safety focused operating system would lean in on those languages.
sillywalk 2y ago
>no one has even taken the time to rewrite the simplest of Unix tools in Rust. "The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities." https://uutils.github.io/ https://uutils.github.io/ https://github.com/uutils/coreutils https://github.com/uutils/coreutils
- dazzawazza 2y ago
  "We are planning to replace all essential Linux tools." It would be nice if they commit to replacing more than just Linux tools. There are numerous quirks/additions to the GNU utils that the BSDs don't want or need.
saagarjha 2y ago
lol? These have been rewritten several times by various people, it's almost a meme at this point to make "x utility but in Rust".
radiator 2y ago
It will not be Rust, since this has not happened after so many years of Rust existing. It will be some other language.
LAC-Tech 2y ago
so where is 'cat'? https://github.com/sharkdp/bat https://github.com/sharkdp/bat (Haven't used this one, but it's pretty popular) Where is 'grep'? https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep Use this one often. It's fast af to search a directory of source code. Where is Korn Shell? https://fishshell.com/blog/fish-4b/ https://fishshell.com/blog/fish-4b/ Fish is now entirely in Rust, very popular, and to be frank basically a step above bash or ksh.
- oguz-ismail 2y ago
  None of these is a 1:1 replacement.
- j16sdiz 2y ago
  Are they posix compliant? (Hints: no)
  - LAC-Tech 2y ago
    Fair. I'm not an OS dev, so I don't really know what POSIX compliance with cat or whatever gets you. All I know is that I'm increasingly replacing classic unix cli tools with rust ones that are just better and faster.
    - tcmart14 2y ago
      Here is the other part. For the BSD's, it's not as simple as, "someone implement them, then we include them." You can package it in the ports trees, but they won't be apart of the base system. Because BSD and Linux are similar in a lot of ways, they differ in a lot. The BSDs are designed with the idea that each BSD makes a completed "base system". The same team writing kernel code is the same team writing user land. So each BSD's core utils is developed and maintained by their respective development team. It is not like Linux, which is really more like smashing different projects from different teams together. At least for what is considered the "base" system. Then mentioned elsewhere, but this isn't as big of a problem on OpenBSD, but would be fore NetBSD. The Rust tools don't support all the supported architectures. This is where BSD philosophy diverges. With NetBSD, if you got a PDP-11 or a toaster with a chip, they are more than happy to make NetBSD run on it, and the NetBSD team also don't necessarily have a requirement for physical hardware, if there is an esoteric chip with QEMU support, they will happily try to support it. OpenBSD will maintain support for an architecture so long as someone is willing to maintain it and owns the physical hardware (which is why it supports less than NetBSD). This is also why NetBSD is sort of "stuck on " gcc. I believe they would like to move to clang, but can't due to architecture support. Some more addition to the first paragraph: OpenBSD to a degree takes this to a whole other level than the other BSDs. OpenBSD maintains their own fork of X11 called xenocara and window manager, cwm. In theory, you can have a pretty basic and functional system from boot code to window manager with all of that code being code maintained by the same team, the OpenBSD developers. They even have their own version control system called got.

fc417fc802 2y ago

The worst part is when you come across something advertised as a replacement and it does something like 80% to 90% of what the original does with a WONTFIX for the rest. That can certainly be a valid choice in some cases, but for core tooling it's not realistic to expect widespread replacement to happen in that scenario.

ptman 2y ago

https://github.com/uutils/coreutils https://github.com/uutils/coreutils Parent wasn't about rust specifically. Just something safer than C

oguz-ismail 2y ago
> uutils Under development for longer than a decade and still unstable
- tazjin 2y ago
  The website says "production ready" for their coreutils. Maybe catching up to 40+ years of development takes a little bit of time?
  - dpassens 2y ago
    > Maybe catching up to 40+ years of development takes a little bit of time? Sure. But that's not OpenBSD's problem, is it?
  - IcePic 2y ago
    Which is the point. 40 years of development is 40 years of development.
- dijit 2y ago
  “put up or shut up” is a valid response. Someone is “putting up”, just need someone to merge uutils and the OpenBSD kernel to see what it starts to look like. Maybe this is the next part of the “put up or shut up” mantra- but we’re getting closer. The parents irony is not lost though. C and perl are both quite dangerous in their own ways, lots of implicit assumptions; its ironic that a safety focused operating system would lean in on those languages.

sillywalk 2y ago

>no one has even taken the time to rewrite the simplest of Unix tools in Rust. "The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities." https://uutils.github.io/ https://uutils.github.io/ https://github.com/uutils/coreutils https://github.com/uutils/coreutils

dazzawazza 2y ago
"We are planning to replace all essential Linux tools." It would be nice if they commit to replacing more than just Linux tools. There are numerous quirks/additions to the GNU utils that the BSDs don't want or need.

saagarjha 2y ago

lol? These have been rewritten several times by various people, it's almost a meme at this point to make "x utility but in Rust".

radiator 2y ago

It will not be Rust, since this has not happened after so many years of Rust existing. It will be some other language.

LAC-Tech 2y ago

so where is 'cat'? https://github.com/sharkdp/bat https://github.com/sharkdp/bat (Haven't used this one, but it's pretty popular) Where is 'grep'? https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep Use this one often. It's fast af to search a directory of source code. Where is Korn Shell? https://fishshell.com/blog/fish-4b/ https://fishshell.com/blog/fish-4b/ Fish is now entirely in Rust, very popular, and to be frank basically a step above bash or ksh.

oguz-ismail 2y ago
None of these is a 1:1 replacement.
j16sdiz 2y ago
Are they posix compliant? (Hints: no)
- LAC-Tech 2y ago
  Fair. I'm not an OS dev, so I don't really know what POSIX compliance with cat or whatever gets you. All I know is that I'm increasingly replacing classic unix cli tools with rust ones that are just better and faster.
  - tcmart14 2y ago
    Here is the other part. For the BSD's, it's not as simple as, "someone implement them, then we include them." You can package it in the ports trees, but they won't be apart of the base system. Because BSD and Linux are similar in a lot of ways, they differ in a lot. The BSDs are designed with the idea that each BSD makes a completed "base system". The same team writing kernel code is the same team writing user land. So each BSD's core utils is developed and maintained by their respective development team. It is not like Linux, which is really more like smashing different projects from different teams together. At least for what is considered the "base" system. Then mentioned elsewhere, but this isn't as big of a problem on OpenBSD, but would be fore NetBSD. The Rust tools don't support all the supported architectures. This is where BSD philosophy diverges. With NetBSD, if you got a PDP-11 or a toaster with a chip, they are more than happy to make NetBSD run on it, and the NetBSD team also don't necessarily have a requirement for physical hardware, if there is an esoteric chip with QEMU support, they will happily try to support it. OpenBSD will maintain support for an architecture so long as someone is willing to maintain it and owns the physical hardware (which is why it supports less than NetBSD). This is also why NetBSD is sort of "stuck on " gcc. I believe they would like to move to clang, but can't due to architecture support. Some more addition to the first paragraph: OpenBSD to a degree takes this to a whole other level than the other BSDs. OpenBSD maintains their own fork of X11 called xenocara and window manager, cwm. In theory, you can have a pretty basic and functional system from boot code to window manager with all of that code being code maintained by the same team, the OpenBSD developers. They even have their own version control system called got.