7 ms·

Judging by the comments, it seems like people haven't realized yet that the distribution is precisely this small so the entire thing can run in RAM. TinyCore wa

Judging by the comments, it seems like people haven't realized yet that the distribution is precisely this small so the entire thing can run in RAM. TinyCore wants to be super fast, so they try and got everything in RAM.

woliveirajr 9y ago
At 11MB, it could be located inside the L3 cache on some processors [0] :) [0]: https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29 https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%2...
- ReverseCold 9y ago
  Is that something that might be doable/useful? Or just a size comparison?
  - trisimix 9y ago
    Anythings doable. But you probably need the space for the processor. Itd be hella fast though
    - nickwanninger 9y ago
      Do you have to do anything special to load it all into the cache or is that just something that would happen by default?
- eliben 9y ago
  On disk size != memory footprint though. It may occupy 11MB as a binary but allocate way more than that at runtime. [nitpicking, of course :)]
feelin_googley 9y ago
Some people perhaps are missing this. Others surely understand. Personally, I have been running my computers this way for many years now. I do not use Linux kernel, but like "tinycore" everything fits in RAM. Size range is usually about 13-17MB for x86. The USB stick or other boot media with the kernel+bootloader can be removed after boot. Depending on how much free RAM I have to spare, I can overlay larger userlands on top of this, and chroot into them. With todays RAM sizes, I can hold an entire "default base" (BSD) in memory if desired. This filesystem on the media is not merely an "install" image. It has everything I need to do work, including custom applications. If I want distributions sets I download them; they are not stored on the media. In normal use, I do not use any disk. Therefore I do not use a swap file. Recently on HN a discussion of sorting came up, and I mentioned the issue of sorting large datasets using only RAM, no disk. Obviously BSD and other UNIX-like kernels date back to a time of severely constrained memory and are designed around space-saving concepts like "virtual memory" and "swap", "shared libraries", etc. When one runs from RAM with no disk, working with large files means "thrashing" is a real possibility. Aside: Did the architects of virtual memory contemplate a world where users are doing work without using HDDs or other writeable permanent storage. (Start a new thread if want to answer/debate this.) Sorting large files is something I do regularly so I am always open to new ideas. Currently I use k/kdb+ for large files instead of UNIX sort. Here's the reply I got: https://news.ycombinator.com/item?id=16086791 https://news.ycombinator.com/item?id=16086791
- breakingcups 9y ago
  What do you use? BSD?
  - feelin_googley 9y ago
    Yes, for me this has been the best balance between (a) the simplicity (size, 3rd party dependencies, etc.) and robustness of the system for building from source and (b) the hardware support in the source tree. No question Linux wins on (b) given all the corporate backing, but whenever I revisit systems like Buildroot or Yocto I feel the system I am using wins on (a). More likely than not I am just resistant to change and not wanting to invest the effort to master those systems. Purely subjective, but I suspect the system I devised for myself is simpler and more "stable" in the sense it is less reliant on third parties and thus less brittle. Those qualities are important to me. Not sure if anyone has mentioned VoidLinux yet in this thread. Probably well worth a look at least as an example if "small and simple" are design goals.
    - pritambaral 9y ago
      Buildroot and Yocto are terrible build systems, let alone build systems for distros. Gentoo and its Portage are IMO really good for distro building, though I would not say it is "small" or "simple". NixOS might also be a good distro builder, from the little I've read about it.
    - exikyut 9y ago
      Which BSD flavor? On the same note, I take it your systems are very "I'm using the [whichever]BSD kernel and userland, but this is my own creation" as opposed to stock [whichever]BSD. A related tangential question: I've been on the fence about BSD distributions for a really long time, specifically the viability of maintaining them. The few that exist seem to end up forking the entire system, as opposed to just running off with the stock kernel and maybe doing package management differently. That puts huge pressure+responsibility on the person doing the fork. My question is, are things the way they are because people wanted to fork the kernel for a specific reason and their fork naturally pulled userspace along, or is there a specific reticence toward forking userspaces in the *BSD world?
dozzie 9y ago
> [...]it seems like people haven't realized yet that the distribution is precisely this small so the entire thing can run in RAM. I do the same with stock Debian. Not an achievement to simply run from RAM only.

woliveirajr 9y ago

At 11MB, it could be located inside the L3 cache on some processors [0] :) [0]: https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29 https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%2...

ReverseCold 9y ago
Is that something that might be doable/useful? Or just a size comparison?
- trisimix 9y ago
  Anythings doable. But you probably need the space for the processor. Itd be hella fast though
  - nickwanninger 9y ago
    Do you have to do anything special to load it all into the cache or is that just something that would happen by default?
eliben 9y ago
On disk size != memory footprint though. It may occupy 11MB as a binary but allocate way more than that at runtime. [nitpicking, of course :)]

feelin_googley 9y ago

Some people perhaps are missing this. Others surely understand. Personally, I have been running my computers this way for many years now. I do not use Linux kernel, but like "tinycore" everything fits in RAM. Size range is usually about 13-17MB for x86. The USB stick or other boot media with the kernel+bootloader can be removed after boot. Depending on how much free RAM I have to spare, I can overlay larger userlands on top of this, and chroot into them. With todays RAM sizes, I can hold an entire "default base" (BSD) in memory if desired. This filesystem on the media is not merely an "install" image. It has everything I need to do work, including custom applications. If I want distributions sets I download them; they are not stored on the media. In normal use, I do not use any disk. Therefore I do not use a swap file. Recently on HN a discussion of sorting came up, and I mentioned the issue of sorting large datasets using only RAM, no disk. Obviously BSD and other UNIX-like kernels date back to a time of severely constrained memory and are designed around space-saving concepts like "virtual memory" and "swap", "shared libraries", etc. When one runs from RAM with no disk, working with large files means "thrashing" is a real possibility. Aside: Did the architects of virtual memory contemplate a world where users are doing work without using HDDs or other writeable permanent storage. (Start a new thread if want to answer/debate this.) Sorting large files is something I do regularly so I am always open to new ideas. Currently I use k/kdb+ for large files instead of UNIX sort. Here's the reply I got: https://news.ycombinator.com/item?id=16086791 https://news.ycombinator.com/item?id=16086791

breakingcups 9y ago
What do you use? BSD?
- feelin_googley 9y ago
  Yes, for me this has been the best balance between (a) the simplicity (size, 3rd party dependencies, etc.) and robustness of the system for building from source and (b) the hardware support in the source tree. No question Linux wins on (b) given all the corporate backing, but whenever I revisit systems like Buildroot or Yocto I feel the system I am using wins on (a). More likely than not I am just resistant to change and not wanting to invest the effort to master those systems. Purely subjective, but I suspect the system I devised for myself is simpler and more "stable" in the sense it is less reliant on third parties and thus less brittle. Those qualities are important to me. Not sure if anyone has mentioned VoidLinux yet in this thread. Probably well worth a look at least as an example if "small and simple" are design goals.
  - pritambaral 9y ago
    Buildroot and Yocto are terrible build systems, let alone build systems for distros. Gentoo and its Portage are IMO really good for distro building, though I would not say it is "small" or "simple". NixOS might also be a good distro builder, from the little I've read about it.
  - exikyut 9y ago
    Which BSD flavor? On the same note, I take it your systems are very "I'm using the [whichever]BSD kernel and userland, but this is my own creation" as opposed to stock [whichever]BSD. A related tangential question: I've been on the fence about BSD distributions for a really long time, specifically the viability of maintaining them. The few that exist seem to end up forking the entire system, as opposed to just running off with the stock kernel and maybe doing package management differently. That puts huge pressure+responsibility on the person doing the fork. My question is, are things the way they are because people wanted to fork the kernel for a specific reason and their fork naturally pulled userspace along, or is there a specific reticence toward forking userspaces in the *BSD world?

dozzie 9y ago

> [...]it seems like people haven't realized yet that the distribution is precisely this small so the entire thing can run in RAM. I do the same with stock Debian. Not an achievement to simply run from RAM only.