Hacker News new | past | comments | ask | show | jobs | submit login

As others have mentioned, a bloat-free web browser is impossible currently because the web itself is far too bloated.

However, I'm not convinced that our OSs can't be much, much simpler. You can, almost reasonably, use DOS as a daily driver still. I have very fond memories of DOS because it was simple. Even as late as the early 2000s, if you wanted something like a MAME cabinet you'd often use DOS. You just plop some application and data folders onto a disk with like 4 system files and you were pretty much done.

Where is today's DOS? I suppose it's Linux, which is orders of magnitude more complicated (especially once you start talking about a GUI) and even Linus admits it has become quite bloated. I personally think we can do a lot better and I've been toying with the idea of putting something together because I'm just so sick of modern computing's bullshit.

PS: If anyone is aware of an organized effort towards this goal that already exists, please let me know.




Interested. I have been stumbling around on this for years. Old comment, https://news.ycombinator.com/item?id=6972431

I like your rule-of-thumb that you should not need a package manager.

Muratori has a theory that USB has made the OS scene complex (https://www.youtube.com/watch?v=kZRE7HIO3vk&t=1350s).

Two other things - the browser and TCP/IP.

Goal: a system where you can fit the whole stack in your head, yet participate in a networked world.

Approach A. Outline a reference hardware platform. Port NetBSD or minix3 or plan9. Then simplify. e.g if unix, get rid of users and groups, get rid of x, get rid of package mgmt, get rid of nfs. You could bootstrap this in qemu.

Approach B. Establish an alternate browser. Something like gopher, but with async events between the 'page' and the user. This allows for chat and form manipulation. You can send non textual content through this async link - video, audio. Codecs are a trap, they lead to pkg management and complexity. How to stop proliferation?


I think Casey hit the nail on the head here. We used to have hardware with standardized ABIs, some of which had extensions (like Tandy graphics compared to CGA). That made it relatively trivial to make OSs, which is what PC booter games did really. DOS itself barely abstracted anything at all, because you didn't need drivers for standardized hardware ABIs.

Unfortunately the only way to deal with that is to give up on the idea of running on a majority of existing PC hardware and target only a small subset of commodity hardware. Ideally it would all be open, to ensure it isn't going anywhere for a while, but sadly there is no such system.

I'm glad to see I'm not the only one who thinks Users and Groups are the wrong abstraction for systems like this.


I've been playing around with this idea myself. My solution is to isolate the "stack of shit" that is still useful into VMs or separate processors entirely. The USB stack is already implemented on microcontrollers. If you only want mass storage and HID keyboards you can implement your own simple protocol. TCP/IP, again, plop it onto a microcontroller and create some simple file interface for it. The browser, um, well, put it in a VM running linux... or really want I would rather do, put it on a VM in the cloud and make the big computer in the cloud do all of the hard work and just send down a simple description of the page, maybe using a protocol like, well, I don't know, Postscript?


1. Package managers need not be complicated. I think a simple sandboxing app mgmt is possible.

2. about web: too bad that design-addict webdev community bloated it. But wish someone make a simpler, faster & straightforward web as portable app platform with few nice commercial qualities...

3. About OS: OS need not be bloated if it isn't running behind popularity by satisfying everyone's remote needs. ( source: plan9, suckless, busybox )...


1. Package managers only exist to manage complexity. If you want one, the system is already too complicated. You can sandbox applications without them.

2. No disagreement here.

3. Unfortunately it still kinda does, because drivers. Two of the ones you listed sit on top of the Linux kernel, which even Linus thinks has become bloated.


If you want use it as a desktop, then plan for a Linux above or below.

Linux above: You need a hypervisor. See L4 or Genode.

Linux below: See unikernels.


Unfortunately I have to agree with this precisely for the reasons outlined by Casey in the parent's linked video. The shift from standardized ABIs to driver-abstracted hardware has ballooned the code required to work on "a PC" geometrically. It's basically impossible to catch up to established OSs now.

An alternative would be targeting a single set of hardware that's likely to be around a really long time. I'd be ok with that and something like a Raspberry Pi, but only if all the hardware was open. Of course, then you're in more of a 68k Mac space where hardware choices are extremely limited.


Mainstream OSs are good at what they do.

I think we are talking about a different niche.

If so, no need to think in terms of catch-up. Rather: work out the design values of this niche.

Lots of ideas, but this thread is already deep. I have created #dinghy on irc.freenode.org, would be interested to discuss further.


As someone who had to develop a DOS application for a job within the last ten years, let me say emphatically, no, DOS is not even remotely suitable as a daily driver today.

If you want simple nowadays, boot a Linux kernel into busybox. It'll boot almost as fast as DOS but you'll have all the crazy modern amenities like 64 bit support and network drivers.

You don't even need a package manager. You could just unpack a GCC binary and compile all the junk you want yourself.


Compiling from source is even worse than a package manager.


Today's DOS is probably https://en.wikipedia.org/wiki/FreeDOS or one of the other OSs meant for embedded development. Minix maybe?


I don't think you could have missed my point more unless you were reading someone else's comment.


I'm curious what kind of use case you have in mind for this OS you're envisioning. I'll admit I can't really figure out either what you're trying to describe.


Me personally? Something I could use as a Desktop OS. In that sense it might be better to picture something like classic MacOS.


I'm not sure exactly what you have in mind, but have you considered OpenBSD?


Let me put it this way: if it has a package manager, it's not what I'm looking for.


That's weird, why wouldn't you want a package manager? That said I think 9front and Redox lack them. Have you considered those?


Because the purpose of a package manager is to hide complexity that shouldn't exist in the first place.


Sounds like you just want self-contained executables. Have you tried AppImages?


I actually like AppImage, even if it is slightly over-engineered compared to simple appdirs. It's a shame more developers don't actually publish them, and that not a single file manager that exists supports displaying their icons.

Still, AppImage is an attempt to bring sanity to the garbage fire of the Linux Desktop. I'd rather have a system that wasn't a garbage fire to begin with.


How does an AppImage handle shared library dependencies? Do multiple independent AppImages share the same mmap'ed library or do they each occupy their own in RAM? If there's no way to dedup the same dependency code between apps then memory usage can grow out of control pretty easily. Package-based distributions concern themselves with this a lot...


> If there's no way to dedup the same dependency code between apps then memory usage can grow out of control pretty easily.

You seriously say this in an era when Electron exists? You'd be hard pressed to waste more resources by simply not having deduped libraries.

> Package-based distributions concern themselves with this a lot

Yes, and they end up causing a lot more headache than they ever save because of it.


I don't disagree with you at all on principle here. What I'm genuinely curious about is if this approach is akin to "compile everything statically?" I'm assuming that, if so, the issue of memory use has obviously been raised and the response is akin to "memory is cheap now" so it's a bygone concern. That may all be true and totally worth it. I just feel compelled to ask having been accustomed to the shared memory mapping model for decades...


I still have no idea what the issue you have is.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: