6 ms·

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether i

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors. Go's GC makes it a show stopper for use in many places as for haskell I would be very interested to see more low level embedded programming going on in it.

masklinn 9y ago
> He has a point though… Does he? He "stat[es as] fact" that > There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?
- _jal 9y ago
  He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.
  - HelloNurse 9y ago
    And if the end user is unable to compile everything, i386 would be only half-supported (or maybe, for the austere OpenBSD maintainers, not supported at all).
  - masklinn 9y ago
    > He's talking specifically about OpenBSD base. No, he is very explicitly saying that > There has been no attempt […] provide replacements for base POSIX utilities. Which once again is categorically false, a github repository purporting to do exactly that has been provided. > i386 is relevant because OpenBSD supports i386. i386 is supported, the issue is compiling the compiler on i386.
    - cat199 9y ago
      > i386 is supported, the issue is compiling the compiler on i386. which is required for the system to be self hosting seriously - what is being said is this: " oh hey lets throw away the functional and perfectly good entire base set of utilities for this 1/2 complete project on github using a language that doesn't even natively build on all of our supported platforms and wouldn't even remove the need for a C compliler in base, and further complicate the base toolchain, not to mention breaking all kinds of other builds which use shell utilities expecting certain behavior, etc ,etc, etc, because somone thought it would be 'neat' to do this. And whyyyy aren't you taking me serously??? " every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted.
      - _jal 9y ago
        Thank you for saving me the trouble of writing that.
      - rrix2 9y ago
        > every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted. this sort of attitude is astoundingly hostile and toxic for an open source community to hold.
        kelnos 9y ago
        I agree, but understand how tiresome it can get when people who -- understandably -- don't know any better do a drive-by of your project and suggest things, things which have often already been discussed to death, or don't even need to be discussed because anyone knowledgeable about the project would immediately see there's no need for discussion. Now, that doesn't mean that a hostile rebuff is required or good policy, but random people who actually do not know what they are talking about, and haven't taken the time to learn enough to know what they're talking about, don't really deserve a long, in-depth, drawn out rebuttal or discussion.
- asveikau 9y ago
  > then points out that rustc can't compile itself on i386, which is relevant… how? Remember he is speaking as the leader of an operating system project. As in, a basic part of the project functioning normally is compiling the whole thing from scratch. If something needs cross-compilation to even get started it won't end up in OpenBSD base. I seem to recall when it supported more architectures they made a public show about how they weren't going to cross compile even for targeting wimpy/sluggish machines, because recompiling the OS was a good stress test for the kernel itself.
  - sitkack 9y ago
    And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater.
    - asveikau 9y ago
      Do you use it? I have had it on one machine or another since around 2000, and I have by and large been pretty happy with it. Not every personality type will like it, and sometimes they do make odd decisions, but it is pretty well put together. Another point about the *BSDs, something doesn't have to be in base for you to use it. The base system is supposed to be small and not have a lot of dependencies. You are free to use things in ports and packages or compile them yourself. So this is not the same as never being able to use rust.
    - mitchty 9y ago
      > And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater. Those lowest common denominator systems tend to find bugs not present elsewhere. And stating that openbsd looks like performance art and security theater seems to indicate you haven't looked at what openbsd has done for security.
      - sitkack 9y ago
        OpenBSD can be security theater and still do great things. But at some point sticking to an 90s Unix/C aesthetic looks deeply anachronistic. Yes, bugs are found at boundaries and interfaces, large or small. Something has to be different for the output to be different. If someone writes a bug proof TLS implementation while at the bottom of the pool wearing SCUBA gear, it is still security theater.
- npsimons 9y ago
  > then points out that rustc can't compile itself on i386, which is relevant… how? I'm actually gobsmacked this is the case. There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go.
  - masklinn 9y ago
    > I'm actually gobsmacked this is the case. So gobsmacked you apparently couldn't even begin to attempt answering the question but felt you just had to go on a rant as irrelevant as you believe it's righteous, uh? > There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go. Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011.
    - 2trill2spill 9y ago
      > Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011. Not on x86 which is what this whole conversation is talking about. So if OpenBSD used rust in base they would have to drop support for x86.
      - sverige 9y ago
        We haven't even gotten to alpha, hppa, loongson, luna88k, macppc, octeon, sgi, or that backwards beauty of big-endianness, sparc64. But hey, it compiles on amd64! That should be good enough, right?
  - ansible 9y ago
    Eh, 64-bit desktops were becoming common a decade ago. Considering the small minority of developers using a 32-bit machine for development, I don't see that it is worthwhile to spend effort on that. Note that Rust can (and does) target various 32-bit platforms (ARM and maybe RISC-V, not sure) for cross-compile. Self-hosting on a 32-bit platform is such a minor drawback these days. 64-bit ARM processors are becoming more common these days as well.
SomeStupidPoint 9y ago
I run full Windows 10 on a tablet (dual core, 2GB RAM), and it's pretty amazing to me how many websites that have no reason to run slow completely fail on it. I can only imagine it works fine on dev machines with much faster quad+ cores and 64GB of RAM or whatever. Just as an aside, it's done a lot to have the tablet be my primary "fiddle-at-home" machine: keeps me really conscious of resource limits, including ones I normally don't think of like screen size. (Most websites render terribly in landscape on a 10" tablet.)
- kevin_thibedeau 9y ago
  Win10 just doesn't work well on 2GiB. Compressed pages are nice but not enough to prevent swapping. It also doesn't help that MS prevents you from running 32-bit on modern hardware to alleviate some of the memory pressure. The solution is to install 32-bit Linux on it. Then it won't suck.
  - Paianni 9y ago
    Or i386 OpenBSD.
  - SomeStupidPoint 9y ago
    Firstly, shut your mouth -- you have no business telling me that my computers "suck" when they serve my needs. It doesn't suck and is one of the most pleasant machines I own due to small size and low upkeep of the OS. 32-bit Win10 works fine on dual-core 2GB of RAM for almost all of my uses (and is the one that shipped with it -- so perhaps check your sources before posting), with notable exceptions being Electron apps and bloated webpages. Your comment is absolutely bad: You're factually wrong about 32bit Win10; your opinion that it doesnt work well is useless when I clearly feel it works fine for me in general, modulo a few uses I called out; your recommendation of what to do is beyond offensive -- just run a different OS that won't solve the issue because it'll meet your pretentious standard? The issue is that certain websites are bloated and always going to overwhelm a dual-core Atom processor, regardless of OS. You should refrain from posting comments like you did here -- they make the community worse. You should also reconsider how you provide tech support, in general.
pecg 9y ago
I think it is important for us to think more on the resources, for programs we write consume, when: they are compiling, they are executing and when they are just "dormant" on persistent memory. Experience and history shows that the bigger the program is, the more resources it needs to function, the more bugs it has, which consequently makes it more difficult to debug and prone to failure.

masklinn 9y ago

> He has a point though… Does he? He "stat[es as] fact" that > There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?

_jal 9y ago
He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.
- HelloNurse 9y ago
  And if the end user is unable to compile everything, i386 would be only half-supported (or maybe, for the austere OpenBSD maintainers, not supported at all).
- masklinn 9y ago
  > He's talking specifically about OpenBSD base. No, he is very explicitly saying that > There has been no attempt […] provide replacements for base POSIX utilities. Which once again is categorically false, a github repository purporting to do exactly that has been provided. > i386 is relevant because OpenBSD supports i386. i386 is supported, the issue is compiling the compiler on i386.
  - cat199 9y ago
    > i386 is supported, the issue is compiling the compiler on i386. which is required for the system to be self hosting seriously - what is being said is this: " oh hey lets throw away the functional and perfectly good entire base set of utilities for this 1/2 complete project on github using a language that doesn't even natively build on all of our supported platforms and wouldn't even remove the need for a C compliler in base, and further complicate the base toolchain, not to mention breaking all kinds of other builds which use shell utilities expecting certain behavior, etc ,etc, etc, because somone thought it would be 'neat' to do this. And whyyyy aren't you taking me serously??? " every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted.
    - _jal 9y ago
      Thank you for saving me the trouble of writing that.
    - rrix2 9y ago
      > every few days (hours?) some noobish person desides to ask some fantasy question about whatever topic of interest they are noobing about on openbsd (and other OS) discussion lists, and then gets whiny when they are being called out for being 'green' about life itself. this is another of those cases, and I have no idea why it got crossposted here or upvoted. this sort of attitude is astoundingly hostile and toxic for an open source community to hold.
      - kelnos 9y ago
        I agree, but understand how tiresome it can get when people who -- understandably -- don't know any better do a drive-by of your project and suggest things, things which have often already been discussed to death, or don't even need to be discussed because anyone knowledgeable about the project would immediately see there's no need for discussion. Now, that doesn't mean that a hostile rebuff is required or good policy, but random people who actually do not know what they are talking about, and haven't taken the time to learn enough to know what they're talking about, don't really deserve a long, in-depth, drawn out rebuttal or discussion.
asveikau 9y ago
> then points out that rustc can't compile itself on i386, which is relevant… how? Remember he is speaking as the leader of an operating system project. As in, a basic part of the project functioning normally is compiling the whole thing from scratch. If something needs cross-compilation to even get started it won't end up in OpenBSD base. I seem to recall when it supported more architectures they made a public show about how they weren't going to cross compile even for targeting wimpy/sluggish machines, because recompiling the OS was a good stress test for the kernel itself.
- sitkack 9y ago
  And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater.
  - asveikau 9y ago
    Do you use it? I have had it on one machine or another since around 2000, and I have by and large been pretty happy with it. Not every personality type will like it, and sometimes they do make odd decisions, but it is pretty well put together. Another point about the *BSDs, something doesn't have to be in base for you to use it. The base system is supposed to be small and not have a lot of dependencies. You are free to use things in ports and packages or compile them yourself. So this is not the same as never being able to use rust.
  - mitchty 9y ago
    > And thus they lock themselves into the lowest common denominator as they target smaller systems. This is ridiculous. OpenBSD looks like performance art, literal security theater. Those lowest common denominator systems tend to find bugs not present elsewhere. And stating that openbsd looks like performance art and security theater seems to indicate you haven't looked at what openbsd has done for security.
    - sitkack 9y ago
      OpenBSD can be security theater and still do great things. But at some point sticking to an 90s Unix/C aesthetic looks deeply anachronistic. Yes, bugs are found at boundaries and interfaces, large or small. Something has to be different for the output to be different. If someone writes a bug proof TLS implementation while at the bottom of the pool wearing SCUBA gear, it is still security theater.
npsimons 9y ago
> then points out that rustc can't compile itself on i386, which is relevant… how? I'm actually gobsmacked this is the case. There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go.
- masklinn 9y ago
  > I'm actually gobsmacked this is the case. So gobsmacked you apparently couldn't even begin to attempt answering the question but felt you just had to go on a rant as irrelevant as you believe it's righteous, uh? > There used to be a saying, only half-joking, that a language that can't host/compile/bootstrap itself is nothing more than a toy. As others have more eloquently pointed out, it shouldn't have to be explained why people who write operating systems and compilers would consider that a no-go. Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011.
  - 2trill2spill 9y ago
    > Rust has been self-hosted for almost as long as it's existed. The boostrapping OCaml compiler was left behind back in 2011. Not on x86 which is what this whole conversation is talking about. So if OpenBSD used rust in base they would have to drop support for x86.
    - sverige 9y ago
      We haven't even gotten to alpha, hppa, loongson, luna88k, macppc, octeon, sgi, or that backwards beauty of big-endianness, sparc64. But hey, it compiles on amd64! That should be good enough, right?
- ansible 9y ago
  Eh, 64-bit desktops were becoming common a decade ago. Considering the small minority of developers using a 32-bit machine for development, I don't see that it is worthwhile to spend effort on that. Note that Rust can (and does) target various 32-bit platforms (ARM and maybe RISC-V, not sure) for cross-compile. Self-hosting on a 32-bit platform is such a minor drawback these days. 64-bit ARM processors are becoming more common these days as well.

SomeStupidPoint 9y ago

I run full Windows 10 on a tablet (dual core, 2GB RAM), and it's pretty amazing to me how many websites that have no reason to run slow completely fail on it. I can only imagine it works fine on dev machines with much faster quad+ cores and 64GB of RAM or whatever. Just as an aside, it's done a lot to have the tablet be my primary "fiddle-at-home" machine: keeps me really conscious of resource limits, including ones I normally don't think of like screen size. (Most websites render terribly in landscape on a 10" tablet.)

kevin_thibedeau 9y ago
Win10 just doesn't work well on 2GiB. Compressed pages are nice but not enough to prevent swapping. It also doesn't help that MS prevents you from running 32-bit on modern hardware to alleviate some of the memory pressure. The solution is to install 32-bit Linux on it. Then it won't suck.
- Paianni 9y ago
  Or i386 OpenBSD.
- SomeStupidPoint 9y ago
  Firstly, shut your mouth -- you have no business telling me that my computers "suck" when they serve my needs. It doesn't suck and is one of the most pleasant machines I own due to small size and low upkeep of the OS. 32-bit Win10 works fine on dual-core 2GB of RAM for almost all of my uses (and is the one that shipped with it -- so perhaps check your sources before posting), with notable exceptions being Electron apps and bloated webpages. Your comment is absolutely bad: You're factually wrong about 32bit Win10; your opinion that it doesnt work well is useless when I clearly feel it works fine for me in general, modulo a few uses I called out; your recommendation of what to do is beyond offensive -- just run a different OS that won't solve the issue because it'll meet your pretentious standard? The issue is that certain websites are bloated and always going to overwhelm a dual-core Atom processor, regardless of OS. You should refrain from posting comments like you did here -- they make the community worse. You should also reconsider how you provide tech support, in general.

pecg 9y ago

I think it is important for us to think more on the resources, for programs we write consume, when: they are compiling, they are executing and when they are just "dormant" on persistent memory. Experience and history shows that the bigger the program is, the more resources it needs to function, the more bugs it has, which consequently makes it more difficult to debug and prone to failure.