Current version clocks in ~700MB, again very small when compared to any modern Linux installation media.

On the other hand, it seems like DSL takes a more extreme approach to slimming down i3/XFCE route, plus DSL contains Dillo which is arguably the latest modern-ish (to the most extent possible) and lightest browser in existence.

Edit: https://www.brow.sh/

Cookies setup for HN:

       ~/.dillo/cookiesrc

       news.ycombinator.com ACCEPT
       .news.ycombinator.com ACCEPT_SESSION
       hn.algolia.net ACCEPT
       .hn.algolia.net ACCEPT_SESSION
       hn.algonia.net ACCEPT
       .hn.algonia.net ACCEPT_SESSION

      sudo modprobe zram

      sudo zramctl --find-size 64MB

      sudo swapon /dev/zram0 -p 99

- XTerm it's very small and works fine. I can posts Xresorces there.

"Back in the day" people were running HP technical workstations, with X11 with CDE, with 128MB RAM, on Pentium-II equivalent speed CPUs - and they liked it!

Server side rendering will collect(steal) personal info, it is a no go. The only right solution is online services to provide a web site on the side of a whatng cartel web app, if the online service does fit ofc. No other way, and hardcore regulation is very probably required.

I remember having tested it, but can't remember what it was like :) -- at least it didn't make me switch from Tiny Core Linux, which I've used extensively. From a superficial, distro-hopper view, DSL, Puppy, EasyOS and Tiny Core all feel quite similar, I guess.

As a side note, it is interesting to see DSL and TC on the HN front page in two consecutive days of 2025. Both are very old projects; I wonder what's the impulse behind this current interest.

I was going to comment that it must have been posted multiple times before 2024, but this is a refresh of the older distro, there are probably different URLs. I'm not sure what's new about it to warrant a post today, the last release is rc7 from June 2024 and the webpage is full of popup ads that are really annoying.

Perhaps someone discovered it for the first time today? If so, this used to be much smaller. 50MB vs 700MB today. I mean, it's a damn small linux that includes Firefox... that doesn't seem quite right to me.

I think the spiritual (and actual) successor to DSL is http://tinycorelinux.net . Which was also discussed here two days ago: https://news.ycombinator.com/item?id=46173547 .

Well, technically the eee is '07. But it is 32bit and everything that entails.

It's Firefox, Dillo, Links2 and Netsurf GTK :)

Dillo is something I'd love to daily drive like I did 20 years ago, but it would just fail on most modern websites. But it's what, 2MB in total (binary+libraries)?

Links2 is text terminal oriented. No modern browser can do that natively at all. All competition is even smaller (w3m, lynx). Plus links2 can run in graphics mode, even on a framebuffer, so you can run it without X server at all.

So Fx is the only "general purpose" browser on that list, but is just too big for old hardware.

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/

Those were some… painful times.

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

“TinyCore” is 23MB. It includes a minimal GUI desktop.

“CorePlus” at 243 MB is internationalized, has a half dozen more window managers to choose, has wireless networking tools, and a remastering tool to spin your own.

http://tinycorelinux.net/downloads.html

i3 and NetSurf made that extremely possible. Mind you, the only things that didn't work well were Firefox (wouldn't launch due to OOM) and compiling Rust projects. Single translation units in Rust would immediately OOM the system, whereas C, C++, etc. worked fine.

It is not one factor but the size of a single bitmap of the screen is certainly an issue.

however this is of course easier said than done

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.