5 ms·

"Windows, Linux, Mac OS X, and the BSDs we have today are still built using the architecture developed when computing resources were limited even though it is n

"Windows, Linux, Mac OS X, and the BSDs we have today are still built using the architecture developed when computing resources were limited even though it is no longer technically necessary." Nonsense! Why would you waste any resources on infrastructure when you could use them for applications. Every cycle that your garbage collector runs is a cycle that the cpu could have been sleeping and saving battery life. This concept that we don't need to care about resources anymore is absolute poppycock.

chipsy 11y ago
The advantage isn't really in that resources can be wasted by adding a feature like garbage collection, but that if you are going to have features like that in your programs, building it in at the OS level is a better way to go about it, as it aggregates the resulting issues in one place, where it can be better managed(at a whole-system level).
nlawalker 11y ago
>> Why would you waste any resources on infrastructure when you could use them for applications. For the same reason we waste them on application frameworks instead of more interesting computations - because applications are written by humans, who take a long time to do it and are notoriously bad at it. Every cycle your garbage collector runs supports the existence of software that might not exist yet, or ever, without it.
- unsatchmo 11y ago
  I am all for advanced memory management in application frameworks. The OS however isn't something you're going to rewrite very often so work harder and squeeze out efficiency so that your apps get them.
  - rickycook 11y ago
    why not? if it's all hot swappable and development at that level is as easy as in user space
  - thecombjelly 11y ago
    OSes are constantly in development. Making development faster and easier could very well lead to a more efficient system. Faster and easier development makes it easier to test out new ideas and spend more time on optimization since it took less time to make the actual feature. Sure, if hardware never changed and the feature set never changed then you could just write the whole thing in assembly and make it as efficient as possible but that isn't reality. When it comes to software requirements and limitations are always changing so making it easier to adapt to those may in the end be the more efficient solution.
cle 11y ago
Because the cost of achieving that level of efficiency is often not worth it.
- unsatchmo 11y ago
  This is an operating system. Efficiency is a feature, and this project is a bunch of hooey.
  - rickycook 11y ago
    the same argument could be had against languages like Python, ruby, and JavaScript. making things easier to develop against often means that complex things exist that make things faster. look at pypy for example: Python interpreter written in Python that's faster in many cases than cpython because they could build advanced features for optimising the underlying running code. writing an OS in C because efficiency seems like a load of hooey to me unless you have facts to back up your idea that for some reason the OS has to be the efficient thing. software development comes down to 1 thing: delivering features. who cares if you need twice the servers to run your product of the alternative is you run out of runway and your project gets canned. hardware is cheap, engineering time is not
    - roddux 11y ago
      >who cares if you need twice the servers to run your product I couldn't help but wince at this. I feel like this isn't a healthy attitude with respect to programming.
      - erichocean 11y ago
        Okay, how about this hypothetical? Ask yourself if the service you're trying to create would have been valuable, say, 4 years ago. Yes? Okay, suppose you wrote it in C++ 4 years ago on four year old hardware? Is it still valuable? Yes? Okay, now write it today in Node and run it on modern hardware. The hardware cost is the same, the service exists, and it was presumably cheaper to write and maintain in Node. Is it still valuable? Yes? That's why it's reasonable to write apps in Node.js today: the performance and cost are the same as doing it in some "more efficient" language 4 years ago, except the cost to actually build the thing now in Node is (much?) lower. If you were okay with the hardware costs for the service 4 years ago written in C++, you should be okay with the hardware costs for the service today written in Node. You can use this argument to support "slow, inefficient" languages for many different kinds of projects (though not all, obviously). And I'm an efficiency nut.
thecombjelly 11y ago
> Nonsense! Why would you waste any resources on infrastructure when you could use them for applications. Every cycle that your garbage collector runs is a cycle that the cpu could have been sleeping and saving battery life. This concept that we don't need to care about resources anymore is absolute poppycock. It isn't that simple. Depending on your program it can actually be slower to do manual memory management. malloc isn't free. In some cases allocating memory and performing GC is actually faster. It's not that we don't have to care about resources at all just that we can sacrifice some of the resources to improve the situation for users and programmers. If that isn't your thing then feel free to write everything in assembly.
- unsatchmo 11y ago
  This isn't an either or. The reason your phone gets all day battery life is because the kernel was designed to run well on an i386. Let the app frameworks have cushy memory management but implement the OS in C.
  - thecombjelly 11y ago
    > The reason your phone gets all day battery life is because the kernel was designed to run well on an i386 This is false. The reason your phone has the battery life it does is because the OS and libraries and applications have been written to allow the hardware of the phone to drop in to lower power states as much as possible. Unless the language you have written your OS in has some bizarre requirement to wake up all the hardware constantly then the language doesn't matter a ton when it comes to battery life. What matters is writing programs that wakeup the hardware as infrequently as possible.
  - agumonkey 11y ago
    CPU deep sleep states ?
- capitalsigma 11y ago
  > it can actually be slower to do manual memory management > we can sacrifice some of the resources Which one is it?

chipsy 11y ago

The advantage isn't really in that resources can be wasted by adding a feature like garbage collection, but that if you are going to have features like that in your programs, building it in at the OS level is a better way to go about it, as it aggregates the resulting issues in one place, where it can be better managed(at a whole-system level).

nlawalker 11y ago

>> Why would you waste any resources on infrastructure when you could use them for applications. For the same reason we waste them on application frameworks instead of more interesting computations - because applications are written by humans, who take a long time to do it and are notoriously bad at it. Every cycle your garbage collector runs supports the existence of software that might not exist yet, or ever, without it.

unsatchmo 11y ago
I am all for advanced memory management in application frameworks. The OS however isn't something you're going to rewrite very often so work harder and squeeze out efficiency so that your apps get them.
- rickycook 11y ago
  why not? if it's all hot swappable and development at that level is as easy as in user space
- thecombjelly 11y ago
  OSes are constantly in development. Making development faster and easier could very well lead to a more efficient system. Faster and easier development makes it easier to test out new ideas and spend more time on optimization since it took less time to make the actual feature. Sure, if hardware never changed and the feature set never changed then you could just write the whole thing in assembly and make it as efficient as possible but that isn't reality. When it comes to software requirements and limitations are always changing so making it easier to adapt to those may in the end be the more efficient solution.

cle 11y ago

Because the cost of achieving that level of efficiency is often not worth it.

unsatchmo 11y ago
This is an operating system. Efficiency is a feature, and this project is a bunch of hooey.
- rickycook 11y ago
  the same argument could be had against languages like Python, ruby, and JavaScript. making things easier to develop against often means that complex things exist that make things faster. look at pypy for example: Python interpreter written in Python that's faster in many cases than cpython because they could build advanced features for optimising the underlying running code. writing an OS in C because efficiency seems like a load of hooey to me unless you have facts to back up your idea that for some reason the OS has to be the efficient thing. software development comes down to 1 thing: delivering features. who cares if you need twice the servers to run your product of the alternative is you run out of runway and your project gets canned. hardware is cheap, engineering time is not
  - roddux 11y ago
    >who cares if you need twice the servers to run your product I couldn't help but wince at this. I feel like this isn't a healthy attitude with respect to programming.
    - erichocean 11y ago
      Okay, how about this hypothetical? Ask yourself if the service you're trying to create would have been valuable, say, 4 years ago. Yes? Okay, suppose you wrote it in C++ 4 years ago on four year old hardware? Is it still valuable? Yes? Okay, now write it today in Node and run it on modern hardware. The hardware cost is the same, the service exists, and it was presumably cheaper to write and maintain in Node. Is it still valuable? Yes? That's why it's reasonable to write apps in Node.js today: the performance and cost are the same as doing it in some "more efficient" language 4 years ago, except the cost to actually build the thing now in Node is (much?) lower. If you were okay with the hardware costs for the service 4 years ago written in C++, you should be okay with the hardware costs for the service today written in Node. You can use this argument to support "slow, inefficient" languages for many different kinds of projects (though not all, obviously). And I'm an efficiency nut.

thecombjelly 11y ago

> Nonsense! Why would you waste any resources on infrastructure when you could use them for applications. Every cycle that your garbage collector runs is a cycle that the cpu could have been sleeping and saving battery life. This concept that we don't need to care about resources anymore is absolute poppycock. It isn't that simple. Depending on your program it can actually be slower to do manual memory management. malloc isn't free. In some cases allocating memory and performing GC is actually faster. It's not that we don't have to care about resources at all just that we can sacrifice some of the resources to improve the situation for users and programmers. If that isn't your thing then feel free to write everything in assembly.

unsatchmo 11y ago
This isn't an either or. The reason your phone gets all day battery life is because the kernel was designed to run well on an i386. Let the app frameworks have cushy memory management but implement the OS in C.
- thecombjelly 11y ago
  > The reason your phone gets all day battery life is because the kernel was designed to run well on an i386 This is false. The reason your phone has the battery life it does is because the OS and libraries and applications have been written to allow the hardware of the phone to drop in to lower power states as much as possible. Unless the language you have written your OS in has some bizarre requirement to wake up all the hardware constantly then the language doesn't matter a ton when it comes to battery life. What matters is writing programs that wakeup the hardware as infrequently as possible.
- agumonkey 11y ago
  CPU deep sleep states ?
capitalsigma 11y ago
> it can actually be slower to do manual memory management > we can sacrifice some of the resources Which one is it?