4 ms·

A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to

by fsloth 9y ago

A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to be enable writing of new things? Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?

geggam 9y ago
Made me chuckle to think of writing systemd in rust
cesarb 9y ago
> I fail to see what advantage rewriting existing and proven tools with a new language would bring. This is not the first rewrite, and won't be the last one. Earlier environments were very memory-constrained, which led to optimizing for memory usage; a rewrite with less memory constraints can focus on speed (as mentioned in the GNU coding standards: "For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. [...]"). The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help. > Shouldn't the main value new tools bring to be enable writing of new things? Or writing old things in a new way. > Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value? These tools are the base over which your system is built (their GNU version isn't named "coreutils" for nothing). Focusing more effort on them makes sense.
- bad_user 9y ago
  > The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help. Moore's law is indeed nearing its end, but this also ends the multiple core trend. If you're betting on multiple CPU cores taking off more than they did already, don't.
vog 9y ago
> Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value? OpenSSL is a classic counter-example. Interestingly, there are two different approaches actually happening to fix OpenSSL: - Taking the existing C code base, throwing a lot away and cleaning up the rest, e.g. LibreSSL (developed by the OpenBSD people) - Taking the TLS spec and rewriting the library from scratch in a safe languange, e.g. ocaml-tls.
progman 9y ago
> I fail to see what advantage rewriting existing and proven tools with a new language would bring I think code safety is not an issue here because the Posix tools (and Unix/Linux as a whole) have already proven their extreme reliability. The only real advantage to rewrite the Posix tools is motivation. A rewrite in a modern language like Rust will likely keep maintainance longer alive than old C code that no one likes to maintain. It's the same reason why a new display manager (Wayland) is wanted instead of X11. There is basically no technical reason to replace the X server which works very well to this day. However, there are not much people anymore who like to maintain the old X code, or to support new graphics cards in X.
- danieldk 9y ago
  There is basically no technical reason to replace the X server which works very well to this day. There is, the architecture is not made with the modern-day world in mind: an X11 application can read all keystrokes, mouse event, and do screen grabs of other windows. An X11 application can emulate your screen locker to grab your credentials. X11 does not support different scaling on different monitors that are connected to your computer.
  - progman 9y ago
    > an X11 application can read all keystrokes I like that because I use key desktop macros heavily. > and do screen grabs of other windows. I like that since it enables me to make screen shots of any application. > X11 does not support different scaling on different monitors that are connected to your computer. I use two monitors with different resolutions, one horizontal, and one in portrait mode. They work perfectly, also with virtual screens. What you possibly mean is that X doesn't support that by default. Nevertheless, it's possible if the graphics vendor provides appropriate drivers.
cestith 9y ago
So does Theo. Base is where the core of the OS that's used to build everything (including base itself) lives. People are more than welcome to have Rust, Go, Java, Erlang, or whatever in the ports tree. There's no reason those are needed in base because they don't build what's in base now. If parts of base required one of those languages to build, that would be an argument for including that language. It ends up being a bit chicken and egg, right? Don't put a language into base because base doesn't use it. Packages in base can't use it because the compiler's not in base. So effectively someone needs to recreate enough core tools in base in the new language that it's worthwhile pulling in the language tools themselves. And then one must justify any compiler performance and platform limitations before the PR is approved, too, potentially solving those upstream in the language community. It's a major undertaking, and people keep asking why someone else doesn't do the work. That's why Theo wants people to show progress on code before asking for the tools to be put into base.

by fsloth 9y ago

geggam 9y ago

Made me chuckle to think of writing systemd in rust

cesarb 9y ago

> I fail to see what advantage rewriting existing and proven tools with a new language would bring. This is not the first rewrite, and won't be the last one. Earlier environments were very memory-constrained, which led to optimizing for memory usage; a rewrite with less memory constraints can focus on speed (as mentioned in the GNU coding standards: "For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. [...]"). The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help. > Shouldn't the main value new tools bring to be enable writing of new things? Or writing old things in a new way. > Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value? These tools are the base over which your system is built (their GNU version isn't named "coreutils" for nothing). Focusing more effort on them makes sense.

bad_user 9y ago
> The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help. Moore's law is indeed nearing its end, but this also ends the multiple core trend. If you're betting on multiple CPU cores taking off more than they did already, don't.

vog 9y ago

> Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value? OpenSSL is a classic counter-example. Interestingly, there are two different approaches actually happening to fix OpenSSL: - Taking the existing C code base, throwing a lot away and cleaning up the rest, e.g. LibreSSL (developed by the OpenBSD people) - Taking the TLS spec and rewriting the library from scratch in a safe languange, e.g. ocaml-tls.

progman 9y ago

> I fail to see what advantage rewriting existing and proven tools with a new language would bring I think code safety is not an issue here because the Posix tools (and Unix/Linux as a whole) have already proven their extreme reliability. The only real advantage to rewrite the Posix tools is motivation. A rewrite in a modern language like Rust will likely keep maintainance longer alive than old C code that no one likes to maintain. It's the same reason why a new display manager (Wayland) is wanted instead of X11. There is basically no technical reason to replace the X server which works very well to this day. However, there are not much people anymore who like to maintain the old X code, or to support new graphics cards in X.

danieldk 9y ago
There is basically no technical reason to replace the X server which works very well to this day. There is, the architecture is not made with the modern-day world in mind: an X11 application can read all keystrokes, mouse event, and do screen grabs of other windows. An X11 application can emulate your screen locker to grab your credentials. X11 does not support different scaling on different monitors that are connected to your computer.
- progman 9y ago
  > an X11 application can read all keystrokes I like that because I use key desktop macros heavily. > and do screen grabs of other windows. I like that since it enables me to make screen shots of any application. > X11 does not support different scaling on different monitors that are connected to your computer. I use two monitors with different resolutions, one horizontal, and one in portrait mode. They work perfectly, also with virtual screens. What you possibly mean is that X doesn't support that by default. Nevertheless, it's possible if the graphics vendor provides appropriate drivers.

cestith 9y ago

So does Theo. Base is where the core of the OS that's used to build everything (including base itself) lives. People are more than welcome to have Rust, Go, Java, Erlang, or whatever in the ports tree. There's no reason those are needed in base because they don't build what's in base now. If parts of base required one of those languages to build, that would be an argument for including that language. It ends up being a bit chicken and egg, right? Don't put a language into base because base doesn't use it. Packages in base can't use it because the compiler's not in base. So effectively someone needs to recreate enough core tools in base in the new language that it's worthwhile pulling in the language tools themselves. And then one must justify any compiler performance and platform limitations before the PR is approved, too, potentially solving those upstream in the language community. It's a major undertaking, and people keep asking why someone else doesn't do the work. That's why Theo wants people to show progress on code before asking for the tools to be put into base.