The small Linux distributions are an interesting alternate universe. Very hobbyist in some respects, as often it's mostly repackaging standard distro stuff, getting older software to compile, writing simple GUI scripts -- not exactly developing a semi-embedded Linux subset with state of the art tools. Very hackish. And I mean that in a good way…
If you do the Linux From Scratch book and follow the embedded track, you should wind up with a busybox based distro around 33MB's on disk, plus you will learn a LOT about how a distro does what it does. I highly recommend it.
I can't speak for DSLR, but I can say why Puppy Linux runs as root without disaster. (Spent a couple of years writing utilities for them.)
Basically you design the system so that root has no special powers. Imagine if all of your storage was write-once, like a CD-R. What damage could root do? Almost none. Maybe there is a union file system for /usr and /home. Disregard all changes to /usr, when you reboot a fresh /usr is extracted from disk. Stuff like /home is incrementally saved. You can re-wind to any point in history. That is how Puppy (in CD-R mode) works.
About the only real threat that root poses is accidentally dd-ing over the OS boot partition. With some kernel patching you could simply hide the /dev node after the boot is done with it. Though that makes updating harder. Any threat can be neutralized, but the whole OS gets slightly more byzantine as a downside.
The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
> > DSLR's approach to security is different . It is possible to run as root without causing a global disaster.
> Is there any more information available on how this is achieved?
+1 to this remark, currently unanswered. Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s? After nearly four years of using Fedoras, I'm getting better about remembering what operations require root privileges, but I'll still grumble every time I have to enter the root password to do something as trivial as mounting a flash drive on someone else's computer. (I can't remember, offhand, where that setting is/what it's called that lets normal users mount drives)
While the floppy is justifiably dead, it is a little strange to see basic installs taking up so much space these days. Thankfully the core-os type projects (os for densly populated vm servers) are helping a bit -- even if deduplication/running root from /nfs etc -- is probably a more expedient (and permanent) way to reduce footprint per vm (1 Gig divided by 1024 vms is just 1Mb per vm after all...).
uLinux or picoLinux (I don't remember very well the name) -> Runs on one or two 3.5 floppies. There is a version with 3 or 4 floppies with an X-Windows included.
Too bad nearly every page is broken on it (CSS wise). The only error it detected on my site was that newfangled <doctype html> declaration... The entire layout was jumbled.
If you're a developer who doesn't know very well how Linux distributions (or operating systems in general) work, you should spend a weekend or two playing around with an embedded Linux distro like this. Unfortunately DSLR's build environment does not seem like the easiest to understand for first-timers.
For example, instead of Makefiles per package, there's a package-specific shell script which incorporates some magic from scripts/build_package and is then sourced by the same to add some functions, with references to patches in a separate directory, and build dependencies tracked by a Makefile.deps file that's included by the root Makefile before the build_package script is run, which incidentally has tons of package-specific logic built in. You'd be re-reading 10 files over and over any time you build or troubleshoot a package.
All of this inside of a chroot using a bootstrapped cross compiler, which lord knows most people have never dealt with before. And the dependencies for building the cross-compiler aren't built from source, meaning this isn't a fully bootstrapped build environment, to say nothing of tracking versions. The resulting packages will vary from system to system, and it will be more difficult to port to non-x86.
When I was in high school I had a 16mb flash drive, so I made a tiny Linux distro for it! It had X11 with blackbox, a web browser (dillo), a mail client (sylpheed), an IM client (ayttm), a VNC client, a music player (xmms), a terminal (rxvt), busybox with a lot of options set, and ssh (dropbear).
I just found the image of that flash drive, if anyone is interested. Keep in mind it is unchanged from its original form in 2006 :)
Back in 2008 when I was in high school I picked up computers that were thrown out by the school with 256 or less RAM. The smallest one only had 64mb of RAM! I managed to install Ubuntu 6 on it but I could feel the lag. I found DSL and I had no trouble running it on them at all. The iSO was only 50MB irrc. It was damn small.
I keep a copy of SuSE Linux from 1998. It have six CD-roms (in a time were Internet by dial-up was not cheap here), but I remember that I managed to install it on 200-300 MiB with a machine with less of 256 MiB of ram, and It could run GNOME 1.0 over KDE !!!! And it was running pretty soft.
This remains me about my own LFS/busybox based stuff http://freecode.com/projects/minili
"minili - miniMAL liNUX 3.8 MB size. You can download and burn it to CD/DVD or Try with virtual machines.If everything is fine,all you can do is,
to login to this linux and run few basic commands."
It was maybe about 5 years ago that I was still running DSL on a old Dell Pentium II laptop on the side of my desk. It made a decent ssh / x3270 terminal and acted as a digital photo frame most of the day. But it could do some light web browsing and stuff in a pinch. Booted from a mini CDR and used a 32 meg USB thumbdrive as storage.
My first linux that I managed to run on a vm. I only had access to dial up internet and thus could only download a very small package. The screenshots make me very nostalgic indeed.
I somehow doubt it. Sure, there's a lot less stuff running, so there are fewer wakeups. But on the other hand, it's missing some essential power-saving software like `acpid` that tells bits of hardware to take a rest in the first place.
[+] [-] mhd|11 years ago|reply
[+] [-] Alupis|11 years ago|reply
[+] [-] mcintyre1994|11 years ago|reply
> DSLR's approach to security is different . It is possible to run as root without causing a global disaster.
Is there any more information available on how this is achieved?
[+] [-] keenerd|11 years ago|reply
Basically you design the system so that root has no special powers. Imagine if all of your storage was write-once, like a CD-R. What damage could root do? Almost none. Maybe there is a union file system for /usr and /home. Disregard all changes to /usr, when you reboot a fresh /usr is extracted from disk. Stuff like /home is incrementally saved. You can re-wind to any point in history. That is how Puppy (in CD-R mode) works.
About the only real threat that root poses is accidentally dd-ing over the OS boot partition. With some kernel patching you could simply hide the /dev node after the boot is done with it. Though that makes updating harder. Any threat can be neutralized, but the whole OS gets slightly more byzantine as a downside.
The root/user distinction places all your faith in octal permission bits. In some ways a properly designed run-as-root system is less risky, because the safeties are baked into the OS at a much deeper level. It is the difference between a dangerous machine having physical safety interlocks and paper-thin "for your safety" policies.
[+] [-] Eiriksmal|11 years ago|reply
> Is there any more information available on how this is achieved? +1 to this remark, currently unanswered. Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s? After nearly four years of using Fedoras, I'm getting better about remembering what operations require root privileges, but I'll still grumble every time I have to enter the root password to do something as trivial as mounting a flash drive on someone else's computer. (I can't remember, offhand, where that setting is/what it's called that lets normal users mount drives)
[+] [-] e12e|11 years ago|reply
Obligatory mention, the QNX demo disk (1.44M floppy image with full gui):
http://toastytech.com/guis/qnxdemo.html
While the floppy is justifiably dead, it is a little strange to see basic installs taking up so much space these days. Thankfully the core-os type projects (os for densly populated vm servers) are helping a bit -- even if deduplication/running root from /nfs etc -- is probably a more expedient (and permanent) way to reduce footprint per vm (1 Gig divided by 1024 vms is just 1Mb per vm after all...).
[+] [-] userbinator|11 years ago|reply
Not a *nix-like but has a ton of functionality in the space of a single floppy.
[+] [-] Zardoz84|11 years ago|reply
[+] [-] guard-of-terra|11 years ago|reply
The forgotten feeling when computers responded immediately.
I guess I'll be using it for some web.
[+] [-] _pmf_|11 years ago|reply
This makes me feed sorry for the people dealing with the XUI/JS/CSS cesspit of Firefox plugins.
[+] [-] Eiriksmal|11 years ago|reply
Dillo looks to be a more interesting way to test websites' graceful fallbacks than hacking up Chrome or Firefox's settings.
[+] [-] aeflash|11 years ago|reply
[+] [-] walterbell|11 years ago|reply
http://alpinelinux.org/ is another minimal appliance distro.
[+] [-] justincormack|11 years ago|reply
[+] [-] userbinator|11 years ago|reply
[+] [-] mykhal|11 years ago|reply
[+] [-] peterwwillis|11 years ago|reply
For example, instead of Makefiles per package, there's a package-specific shell script which incorporates some magic from scripts/build_package and is then sourced by the same to add some functions, with references to patches in a separate directory, and build dependencies tracked by a Makefile.deps file that's included by the root Makefile before the build_package script is run, which incidentally has tons of package-specific logic built in. You'd be re-reading 10 files over and over any time you build or troubleshoot a package.
All of this inside of a chroot using a bootstrapped cross compiler, which lord knows most people have never dealt with before. And the dependencies for building the cross-compiler aren't built from source, meaning this isn't a fully bootstrapped build environment, to say nothing of tracking versions. The resulting packages will vary from system to system, and it will be more difficult to port to non-x86.
[+] [-] walterbell|11 years ago|reply
[+] [-] sroerick|11 years ago|reply
[+] [-] bonyt|11 years ago|reply
I just found the image of that flash drive, if anyone is interested. Keep in mind it is unchanged from its original form in 2006 :)
Image: https://www.dropbox.com/s/8lomxad7cqjn10w/nanolinux.img?dl=0
Virtualbox Image (identical, converted with qemu-img): https://www.dropbox.com/s/uo1huoawjkkqmj7/nanolinux.vdi?dl=0
Screenshot: https://www.dropbox.com/s/v7ijnd6b6688brz/Screenshot%202014-...
[+] [-] eCa|11 years ago|reply
https://duckduckgo.com/?q=dslr
[+] [-] Mahn|11 years ago|reply
[+] [-] tomswartz07|11 years ago|reply
More often than not, the vast majority of these awesome little projects flounder under the lack of documentation.
Making it available (and well done) allows for anyone to just jump in and help.
Kudos!
[+] [-] zem|11 years ago|reply
[+] [-] sarciszewski|11 years ago|reply
I wonder if we'll see a ZF02 remake for DSL? :]
[+] [-] yeukhon|11 years ago|reply
This was me: http://damnsmalllinux.org/static/act-Print/f-1/t-19848.html
[+] [-] Zardoz84|11 years ago|reply
[+] [-] giis|11 years ago|reply
[+] [-] ja27|11 years ago|reply
[+] [-] codygman|11 years ago|reply
[+] [-] thomasjudge|11 years ago|reply
[+] [-] cFire|11 years ago|reply
The md5sums for 3 of them don't seem to match what's on the DSLR page though. The one with a .md5sum file does match. Use others with caution for now.
[+] [-] cFire|11 years ago|reply
[+] [-] brassattax|11 years ago|reply
[+] [-] peterwwillis|11 years ago|reply
[+] [-] silveira|11 years ago|reply
[+] [-] cFire|11 years ago|reply
[+] [-] Newky|11 years ago|reply
[+] [-] codehero|11 years ago|reply
[+] [-] mhd|11 years ago|reply
[+] [-] terminado|11 years ago|reply
[+] [-] crapiola|11 years ago|reply
*Grammar Nazi alert - breathes
[+] [-] gpvos|11 years ago|reply