Live data from Hacker News

Damn Small Linux

damnsmalllinux.org

61–70 of 71 posts

Re: Damn Small Linux

#61

Every time I looked at DSL, I never understood the need to include 4 Web Browsers in a distro that supposedly prides itself on size.

This is an effort to preserve RAM more than disk while still having software that works.

Re: Damn Small Linux

#62

Distros like these help troubleshoot boxes that are old/slow but also not used as computers in the traditional sense. For example network boxes, NAS, video recording boxes etc that can't run the latest LTS ubuntu well but can boot a distro like DSL. getting a vga out on these things with a fast to boot distro helps you fix things like corrupt drives, bad partitioning, bad boot loaders etc which needs a few terminal c…

DSL uses the latest Debian kernel. It is not any smaller than Ubuntu.

Re: Damn Small Linux

#63

I didn't know it was revived, had some fun with it back in the day. I'm curious to see how it compares against Alpine which is also very compact because of musl.

Alpine is more company, not just because of musl but because of busybox.

DSL uses the Debian kernel, Glibc, and the GNU utils.

Re: Damn Small Linux

#64

Distros like these help troubleshoot boxes that are old/slow but also not used as computers in the traditional sense. For example network boxes, NAS, video recording boxes etc that can't run the latest LTS ubuntu well but can boot a distro like DSL. getting a vga out on these things with a fast to boot distro helps you fix things like corrupt drives, bad partitioning, bad boot loaders etc which needs a few terminal c…

DSL uses the latest Debian kernel. It is not any smaller than Ubuntu.

The GUI is usually the problem. I have booted Xubuntu and it's still slow. Slow systems with older GPUs simply can't keep up with newer desktops. Most of the times I need a terminal but a lightweight desktop can help if I quickly want to open a browser and search something so that I can copy past more complicated commands.

Re: Damn Small Linux

#65
post #18

I recently used it to boot a ~1996 Compaq Presario from CD-Rom to image the hard-drive to a USB stick before wiping it for my retro-computer fun :) It's kind of sad to hear "adult" people claim in all seriousness that it's reasonable that a kernel alone spends more memory than the minimum requirement for running Windows 95, the operating system with kernel, drivers, a graphical user interface and even a few graphical…

I mean why is that a problem? Win95 engineering reflects the hardware of the time, the same way today's software engineering reflects the hardware of our time. There's no ideal here, there's no "this is correct," etc its all constantly changing. This is like car guys today bemoaning the simpler carburetor age or the car guys before them bemoaning the model T age of simplicity. Its silly. There will never be a scenari…

> There will never be a scenario where you need all this lightweight stuff

I think there are many.

Some examples:

* The fastest code is the code you don't run.

Smaller = faster, and we all want faster. Moore's law is over, Dennard scaling isn't affordable any more, smaller feature sizes are getting absurdly difficult and therefore expensive to fab. So if we want our computers to keep getting faster as we've got used to over the last 40-50 years then the only way to keep delivering that will be to start ruthlessly optimising, shrinking, finding more efficient ways to implement what we've got used to.

Smaller systems are better for performance.

* The smaller the code, the less there is to go wrong.

Smaller doesn't just mean faster, it should mean simpler and cleaner too. Less to go wrong. Easier to debug. Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot. Part of the Unix philosophy is to embed the KISS principle.

So that's performance and troubleshooting. We aren't done.

* The less you run, the smaller the attack surface.

Smaller code and less code means fewer APIs, fewer interfaces, less points of failure. Look at djb's decades-long policy of offering rewards to people who find holes in qmail or djbdns. Look at OpenBSD. We all need better more secure code. Smaller simpler systems built from fewer layers means more security, less attack surface, less to audit.

Higher performance, and easier troubleshooting, and better security. There's 3 reasons.

Practical examples...

The Atom editor spawned an entire class of app: Electron apps, Javascript on Node, bundled with Chromium. Slack, Discord, VSCode: there are multiple apps used by tens to hundreds of millions of people now. Look at how vast they are. Balena Etcher is a, what, nearly 100 MB download to write an image to USB? Native apps like Rufus do it in a few megabytes. Smaller ones like USBimager do it in hundreds of kilobytes. A dd command in under 100 bytes.

Now some of the people behind Atom wrote Zed.

It's 10% of the size and 10x the speed, in part because it's a native Rust app.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it's smaller and faster and more customisable because it's native Rust code.

GNOME Shell is Javascript running on an embedded copy of Mozilla's Javascript runtime.

Just like dotcoms wanted to dis-intermediate business, remove middlemen and distributors for faster sales, we could use disintermediation in our software. Fewer runtimes, better smarter compiled languages so we can trap more errors and have faster and safer compiled native code.

Smaller, simpler, cleaner, fewer layers, less abstractions: these are all goods things which are desirable.

Dennis Ritchie and Ken Thompson knew this. That's why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything's in a container all the time, the filesystem abstracts the network and the GUI and more. Under 10% of the syscalls of Linux, the kernel is 5MB of source, and yet it has much of Kubernetes in there.

Then they went further, replaced C too, made a simpler safer language, embedded its runtime right into the kernel, and made binaries CPU-independent, and turned the entire network-aware OS into a runtime to compete with the JVM, so it could run as a browser plugin as well as a bare-metal OS. Now we have ubiquitous virtualisation so lean into it: separate domains. If your user-facing OS only runs in a VM then it doesn't need a filesystem or hardware drivers, because it won't see hardware, only virtualised facilities, so rip all that stuff out. Your container host doesn't need to have a console or manage disks.

This is what we should be doing. This is what we need to do. Hack away at the code complexity. Don't add functionality, remove it. Simplify it. Enforce standards by putting them in the kernel and removing dozens of overlapping implementations. Make codebases that are smaller and readable by humans.

Leave the vast bloated stuff to commercial companies and proprietary software where nobody gets to read it except LLM bots anyway.

Re: Damn Small Linux

#66

Distros like these help troubleshoot boxes that are old/slow but also not used as computers in the traditional sense. For example network boxes, NAS, video recording boxes etc that can't run the latest LTS ubuntu well but can boot a distro like DSL. getting a vga out on these things with a fast to boot distro helps you fix things like corrupt drives, bad partitioning, bad boot loaders etc which needs a few terminal c…

DSL uses the latest Debian kernel. It is not any smaller than Ubuntu.

Yeah it is.

It fits into under 700 MB and runs in well under 100 MB of RAM. The default Ubuntu image is about 6 GB now and takes a gig of RAM.

Have you not tried it? I have:

https://www.theregister.com/2024/02/14/damn_small_linux_retu...

Re: Damn Small Linux

#67

Earlier quoted context omitted.

DSL uses the latest Debian kernel. It is not any smaller than Ubuntu.

The GUI is usually the problem. I have booted Xubuntu and it's still slow. Slow systems with older GPUs simply can't keep up with newer desktops. Most of the times I need a terminal but a lightweight desktop can help if I quickly want to open a browser and search something so that I can copy past more complicated commands.

It is still slow.

Try Alpine. It's amazing.

Xubuntu 22.04 took nearly 10 GB of disk and half a gig of RAM. I measured it:

https://www.theregister.com/2022/08/18/ubuntu_remixes/

Alpine takes 1.1 GB of disk and under 200 MB of RAM.

https://www.theregister.com/2025/12/05/new_lts_kernel_and_al...

Both running a full Xfce $CURRENT desktop, in a Virtualbox VM.

Re: Damn Small Linux

#68
post #32

A great reason to try and support small distros is that older computers can still be used as long as they work. There are also some charities that ship old PCs to Africa, install a small Linux distro on them, e.g.: https://www.computers4charity.org/computers-for-africa https://worldcomputerexchange.org/

Excellent point.

When I lived in London I helped clients donate a lot of kit to ComputerAid International:

https://www.computeraid.org/

And what's now Computers4Charity:

https://www.computers4charity.org/

Re: Damn Small Linux

#69

Earlier quoted context omitted.

I mean why is that a problem? Win95 engineering reflects the hardware of the time, the same way today's software engineering reflects the hardware of our time. There's no ideal here, there's no "this is correct," etc its all constantly changing. This is like car guys today bemoaning the simpler carburetor age or the car guys before them bemoaning the model T age of simplicity. Its silly. There will never be a scenari…

I agree with this take. Win95's 4MB minimum/8MB recommended memory requirement and a 20MHz processor is seen as the acceptable place to draw the line but there were graphical desktops on the market before that on systems with 128K of RAM and 8MHz processors. Why aren't we considering Win95's requirements as ridiculously bloated?

Yep, at the time the Amiga crowd was laughing at the bloat. But now its suddenly the gold standard on efficiency? I think a lot of people like to be argumentative because they refuse to understand they are engaging in mere nostalgia and not actually anything factual or logical.

Re: Damn Small Linux

#70
post #18

I recently used it to boot a ~1996 Compaq Presario from CD-Rom to image the hard-drive to a USB stick before wiping it for my retro-computer fun :) It's kind of sad to hear "adult" people claim in all seriousness that it's reasonable that a kernel alone spends more memory than the minimum requirement for running Windows 95, the operating system with kernel, drivers, a graphical user interface and even a few graphical…

I mean why is that a problem? Win95 engineering reflects the hardware of the time, the same way today's software engineering reflects the hardware of our time. There's no ideal here, there's no "this is correct," etc its all constantly changing. This is like car guys today bemoaning the simpler carburetor age or the car guys before them bemoaning the model T age of simplicity. Its silly. There will never be a scenari…

if you can compile the kernel though, there is no reason that W95 should be any smaller than your specifically compiled kernel - in fact it should be much bigger

however this is of course easier said than done

Post reply on HN