DSLR – Damn Small Linux Remake | Hacker News Reader

DSLR – Damn Small Linux Remake

dslr.dimakrasner.com

182 pointsnetworked84 comments

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.

Nice, I remember being shown DSL and being amazed someone could make an OS that small.

> 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?

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.

What's a floppy? Is it as small as an SD card?

</sarcasm>

I remember running a QNX demo off a single floppy on a 66MHz 486. Included a web browser, a game ,and an editor, all in 1.44MB

http://toastytech.com/guis/qnxdemo.html

and a kick-ass OS.

I remember that too. Very impressive, it was.

Do you mean muLinux (μLinux) ?

http://ftp.gwdg.de/linux/mulinux/ http://en.wikipedia.org/wiki/MuLinux

It was one of my first distro and it was awesome. A base system than ran in one floppy and then you could optionally add and combine more floppys depending of what you wanted (X system, IDE, games, latex, etc...) It was kind of the ancestor to Live CD

TomsRtBt runs off a floppy - http://www.toms.net/rb/

If you're into small but very functional OSs, also take a look at MenuetOS: http://www.menuetos.net/

Not a *nix-like but has a ton of functionality in the space of a single floppy.

> > 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)

Is the "NEVER RUN AS ROOT!" mantra from modern Linux practices, or has it been that way since the mid-90s?

I think that goes back all the way to Unix and its multiuser environment, where one admin's mistakes could affect everyone on the system - so people were naturally scared of root.

On the other hand, on the earliest personal computer OSs, which were basically single-user (many don't even have the concept of a "user account"), that only user has full control like root but that wasn't really perceived with as much apprehension since the only thing a mistake affects is the sole user.

With DSLR and all the other tiny Linux distros, I sense that the intention is these are to be used by a single user.

Ah... That is very insightful, thank you. I continually forget the days of timesharing, etc. For my entire life (born during the Tiannamen Square riots), personal computers have typically hosted one user at a time.

That statment is actually true for the entire existence of personal computers... you might even say it's the definition of a PC. However, Unix didn't start on PCs, it started on minicomputers.

Almost 20 years ago I typed "rm /lib" instead of "rm lib" by mistake. Kernel panic messages started to flash on the terminal and I felt butterflies on my stomach. It was a huge (at the time) Sun machine, took more than 12h to restore it.

That is why I avoid running as root.

lol, we should have a thread about famous typos.

The other late evening, I typed "sudo pip uninstall pip" instead of "sudo pip uninstall pil" Not that bad, but i was on an outdated distro (13.04) and I couldn't apt-get pip back. :< It was time to move to 13.10 anyway.

what? `sudo apt-get install python-pip --reinstall` wouldn't work?

Using Linux or OSX on a modern single user computer, the separation between root and non-root makes very little sense.

I don't care if I "rm -Rf /bin" because I can reinstall all of it in less than an hour. It's an inconvenience, but hardly the end of the world.

On the other hand, "rm $HOME/*" would be a huge pain in the ass, potentially losing personal data that I can't just "apt-get install _____" back.

It does make sense for shared computers, but not many people running OSX and desktop Linux are running on shared computers.

that's what time machines are for

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.

> With some kernel patching you could simply hide the /dev node after the boot is done with it.

At some point we have to make the call on diminishing returns. It will always be possible for root to bork a system (without a rewrite of many, many utilities that rely on root permissiveness), it's just a matter of how hard we can make it to do that accidentally. To be clear, I think this work is very useful and appreciated though. As someone that spends almost all of every working day in terminals on remote systems, often as root, I applaud any effort to reduce catastrophic mistakes. Every time I have to rm -rf as root there's that little after-I-hit-enter-panic, where I have to assure myself I double checked and didn't accidentally just delete /bin. The root is protected from the errant rm mistake, but there's oh so many more ways to reduce a perfectly fine system to an unbooting heap of hardware.

> 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.

Give me both. Please.

> Nice, I remember being shown DSL and being amazed someone could make an OS that small.

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...).

Dillo is so awesome! I urge you to apt-get install dillo

The forgotten feeling when computers responded immediately.

I guess I'll be using it for some web.

Dillo also has an easy, approachable plugin architecture: http://www.dillo.org/dpi1.html

This makes me feed sorry for the people dealing with the XUI/JS/CSS cesspit of Firefox plugins.

Do they plan to add a JavaScript engine?

It's graded low prio: http://www.dillo.org/Plans.html

Why would you ruin a perfectly good browser with JS support? :|

Probably because most users would prefer that the sites they visit actually work.

Supporting other embedded languages might be nice, but of course, unless all the major browsers also support the same, sites would have to provide an alternative in javascript for everybody else.

Not supporting javascript at all when it's integrated so deeply into the web, when you will doubtless be able to simply turn it off if you want, seems unreasonable.

For better or worse, the web is becoming a platform for distributing javascript binaries which execute in the browser. Unlike most other platforms, however, at least you can turn it off or view the source or block parts of it if you like.

Every site should be able to function normally without JS. Granted that doesn't necessarily hold true for web apps, but for regular sites they shouldn't lose functionality because somebody has JS disabled (or doesn't have it at all!)

I agree with you. I have js disabled by default and every time I run up against a site that uses client-side templating I find it incredibly annoying - I understand the rationale behind it but it's still annoying how many things tend to break without javascript.

However, you can't design a browser around an expectation of what the web should be like.

And anyway, it could be worse. If there were no javascript we would all be complaining about the dominance of VBScript in the browser.

> VBScript

shudder

JS itself isn't bad, it's the misuse which is bad. Subtle JS use should add _extra_ functionality, not _be_ the functionality.

It's funny, I was just having a conversation about JS in freenode #python the other day and we were complaining/discussing the same thing.

The worst is when my browser freezes because of some JS that's too over the top.

I really hope that people start installing and testing against minimal browsers.

Modern browsers are fucking huge. Obviously they do very much more than browsers used to, but most of the time I really am just reading text and I don't want a bad designer's idea of novel UI to get in the way.

Sadly it seems like hundreds of years of design iteration for the printed word are being weakened.

Dillo plugins use CSS (see the download manager source) and Firefox addons can use HTML instead of XUL (see the add-on SDK).

Wow. On FC20, Dillo is 1.4M installed. Chrome 37 is about 200M.

Dillo looks to be a more interesting way to test websites' graceful fallbacks than hacking up Chrome or Firefox's settings.

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.

No policy statement on systemd? :)

http://alpinelinux.org/ is another minimal appliance distro.

Yes Alpine is a nice distro that also uses Musl. Good way to try out Musl libc if you haven't yet.

The name would fit perfectly for a distro used on the embedded system in a digital camera. :-)

ADF (acronym design failure)

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.

What would be a good distribution for playing around like you described?

Linux From Scratch [1] is the de-facto standard in building a Linux system from the ground up, with more detail in CLFS [2]. You can look at Buildroot [3] as a model for embedded systems. SLAX [4] is a bootable embedded distro with tons of friendly documentation, and is a derivative of Slackware that also uses buildroot/busybox.

[1] http://www.linuxfromscratch.org/ [2] http://trac.cross-lfs.org/ [3] http://buildroot.uclibc.org/ [4] http://www.slax.org/

What do you think of https://www.yoctoproject.org/ as an alternative?

Yocto seems to be an attempt to make a standards body for embedded Linux development. It's neat and probably a huge boon for corporate-sponsored development, but overkill for the casual developer to learn more about Linux. All you need is a HOWTO to step you through building a toolchain and setting up the files needed to boot up with some programs running at start time, which LFS provides.

Here's a guide for 'old' Linux distros http://www.linuxfromscratch.org/lfs/view/stable/ and here's a guide using systemd http://www.linuxfromscratch.org/lfs/view/stable-systemd/

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 :)

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-...

They have an uphill battle, SEO-wise.

https://duckduckgo.com/?q=dslr

Why would they even care for SEO? It's not like it's a commercial project.

Why wouldn't they care just because it's not commercial?

Because their ability to work on this project does not depend on its accessibility from a search engine.

I greatly appreciate the fact that one of the tenents of the project is documentation.

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!

"tenets" (because you're likely pronouncing it wrong too)

http://www.gonullyourself.org/ezines/ZF0/zf0%202.txt

I wonder if we'll see a ZF02 remake for DSL? :]

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.

This was me: http://damnsmalllinux.org/static/act-Print/f-1/t-19848.html

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.

Does this come with tinyxserver by default? Anyone know how to start it? startx doesn't seem to work.

Are there any mirrors? The site is getting hn-dotted. It should not take 8hrs to download a 108M file

https://github.com/dimkr/dslr

binaries are also here https://archive.org/details/Puppy_Linux_DSLR_Linux

Thanks! This took the download from 8hrs to 3 min.

http://coolfire.insomnia247.nl/DSLR/

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.

Turns out the ones with incorrect md5sums are indeed older builds. All ISOs are being brought up to date as fast as it'll go.

Both 64 bit images are up to date now.

http://coolfire.insomnia247.nl/DSLR/ is now entirely up to date with the latest available ISOs.

For the ones having problem with slow speeds to download the iso, try here https://archive.org/details/Puppy_Linux_DSLR_Linux

There's current mirrors added on the site. The isos from archive.org are outdated.

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.

How does the power efficiency of DSLR compare to Ubuntu? Would I get longer battery life?

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.

> [...] like `acpid` that tells bits of hardware to take a rest

I believe that that stuff is mostly in the kernel. Man acpid:

> acpid is designed to notify user-space programs of ACPI events.

acpid being only one of the tools usually there to interface with power management, I'm not really up-to-date what Ubuntu uses nowadays. And yes, as with a lot of hardware stuff you're going to end up in the kernel in the end, but without any management/supervision software (never mind drivers), you usually won't get a quiet and cool laptop. Try starting a barebones arch installation on one these days, without acpid, tlp etc.…

Perhaps the project should aim to either integrate acpid or if deemed to heavy, write a lighter version of it.

Digital Single Lens Reflex?

"...comes pre-loaded with many useful applications and breaths* new life into..."

*Grammar Nazi alert - breathes

There are a few other mistakes (okay, at least one; I'm not enough of a grammar nazi to have counted them).

Sounds like a fun project.

I cannot even think of how many security vulnerabilities exists in these applications used for this "remake".

Mentioning one of these things you can't even think of would be useful. For example: I've used Ted for years; it's great.

To quote the DSLR's author Very often, new versions of applications are heavier than older ones (Wirth's Law). If the old version already solves the problem ... without any compromise in security or stability, why make the switch [to a bloated new version]?

The author SAYS that, but that's ALL he says. There's nothing to back up the claim that the older versions are not a compromise in security. Are all known vulnerabilities patched? Are security fixes backported?

Almost never: which may causes issues likes thoses! : From Wikipedia & OpenBSD: The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive). Later versions (1.0.1g and ulterior ) and previous versions (1.0.0 branch and older) are not vulnerable. Installations of the affected versions are vulnerable unless OpenSSL was compiled with -DOPENSSL_NO_HEARTBEATS.

same applies for : http://tools.cisco.com/security/center/content/CiscoSecurity...

same applies for : https://blog.mozilla.org/security/2010/03/18/update-on-secun...

same applies for : http://www.debian.org/security/2000/20001013

same applies for : https://kb.isc.org/article/AA-01015/0

sticking to early versions (lazingly will save you)

So just for starters... For those who downvoted my comment take a look: Dillo 0.8.6 (1) ; sylpheed (2) ; dhcpcd (3). According to the sources http://dslr.dimakrasner.com/i686

In Linux/FOSS distros using outdated software is really not good idea unless you know what you are doing or have support from the distro which have people that should be able to fix the security vulnerabilities. e.g. RedHat, Suse, Canonical, Debian.

Using software which is dead upstream often makes distro maintainers want to remove the software from the repository because they are not able/want to maintain. BTW... I'm curious about which version of GTK+1.x is he using. GNOME does not support GTK+-1.x for years how wonder who fixes the security vulnerabilities also.

1 - http://www.cvedetails.com/version/78795/Dillo-Dillo-0.8.6.ht...

2 - https://lists.debian.org/debian-security/2005/11/msg00120.ht...

3 - http://www.cvedetails.com/cve/CVE-2012-2152/

Reply on news.ycombinator.com