NomadBSD | Hacker News Reader

NomadBSD

nomadbsd.org

122 points1MachineElf49 comments

It is a bit interesting for the future of the product that most of the comments aren't about the actual functionality that this BSD provides. The cool thing here is that you can plug it into any computer like TAILS or a few other Linux distros and use it like your own computer. Most comments seem to focus on the unconventionality of BSD's. A BSD in general is like a linux distro in that they package a kernel and userland together, usually with a package manager or a port system. The great advantage of a BSD is that usually the kernel-libc interface is designed better. For instance FreeBSD used to have a much faster writev implementation compared with Linux(from personal experience and the Advanced Unix Programming Book's test).

Edit: I tried using a \star character before BSD which apparently is italics in this editor.

The main differentiating feature vs. (free,net,open,whatever)BSD seems to be that it boots from a pluggable external device like a USB flash drive and doesn't perturb the system it's booting on.

Seems like something that should just be added to FreeBSD.

So adding that is hard. I mentioned that a bit by alluding to TAILS, storage on USB is interesting since most users just yank it at some point. FSCK and making sure writes complete in nontrivial. Feature detection on boot is interesting as well. Those two points are not things you regularly want. I would prefer my modules compiled into the kernel in Linux terminology.

FreeBSD has that with mfsBSD, but it's extremely minimal compared to this NomadBSD project, albeit still quite useful.

OpenBSD has that with Fuguita.

This is great, now I can check if my cheap fringe laptop is usable with BSD. Been itching to switch for a while, but haven’t dared.

The major BSD derived operating systems all have 'live' boot media for installs - however this usually means CLI. That said, this should be enough to verify most HW compatibility. I say this because this is FreeBSD based, so you're not going to find out about OpenBSD or NetBSD compatibility this way.

I'm excited too. Up until now, I've been relying on mfsBSD for this - and it only solves the problem for server-like platforms with nothing but the bare CLI. It's still great for SuperMicro's virtual CD-ROM over IPMI.

FuryBSD also made it to the HN frontpage yesterday.

Both FuryBSD and NomadBSD are based on FreeBSD.

Is FreeBSD just generally a better desktop OS than OpenBSD? I've never used any *BSD in my life, so I honestly don't know.

I used to be able to run Matlab on FreeBSD(linux only since ~2016), so that made it much more desktop friendly as far as I was concerned. Currently OpenBSD can't run Wine and doesn't have any Linux compatibility layer. NetBSD had a youngin work on fixing Wine, but that hasn't been merged in to a release.

Did you try Octave?

FreeBSD is an easier desktop OS than OpenBSD. Supports lot's more out of the box, more 'modern' desktop environment, etc. Whether or not it's a better desktop environment is a matter of taste. OpenBSD is lighter weight, more uniform and more minimal. Old school. For some, that's better. I run OpenBSD on lower-end/older hardware (it runs awesome on a Thinkbook 42T or 43T), and FreeBSD on modern stuff.

Yes FreeBSD tends to be the better desktop BSD due to many devs/users using it as a daily driver and fixing many of the pain points... of course I haven't used FreeBSD as my daily driver since ~2003 so I could be operating off totally stale information. I do have to say sometimes I get pangs of missing the much more unified tooling in BSD land, but GNU is my home now (sometimes exceptions are made in the case of pfsense, freenas, etc).

There was a point in time... and 2003 was probably about it, where FreeBSD on the desktop was just a dream... this would have been like 4.7 or thereabouts...

* Working NVidia driver * Working OSS sound with mixing/multi access (Like modern ALSA, except, ya know, not blowing chunks) * WOrking Java * Nice fonts

I think even FlashPlayer worked.

And there was linux binary compat so you could run whatever.

Yep 4.5 ish to about 4.9 were very nice and about the range when it was my main system.

I'd say that it largely depends on what you consider table stakes for "desktop" these days. OpenBSD has a surprisingly credible and coherent desktop story as far as it goes, though at this point you'll probably be disappointed if you expect anything resembling cutting-edge GPU or Wi-Fi support (they're not sitting still on those fronts, it's just a lot of work to keep up). Gaming in general will be a challenge outside of emulators and other open-source runtimes (ScummVM, fnaify, LWJGL, Ren'Py, etc.).

Most wireless devices will work fine under OpenBSD, and so will do Intel/AMD cards. No Nvidia.

I think I overstated the gap in GPU support. I was under the impression that the amdgpu driver was still not in the default kernel (which in OpenBSD implies not really being supported), but it looks like they added it for 6.6. It's reportedly from Linux 4.19, which is reasonably recent. This should support the RX 500 series, which is the sort of thing that one might actually pick up at Best Buy today.

For graphics and desktop related it's better to run -current. Sometimes it may break inbetween, but it's solved fast over getting a new snapshot and upgrading the packages. OFC if you are like me being paranoid over stability, get -release.

Oooo, I kind of want to get that $200 Pinebook to play with this on.

I have a nostalgia for posix like systems on older hardware, I remember when my daily was Ubuntu on a PIII.

I would love to boot something like this on a Pinebook. Unfortunately, the releases are only for amd64 and Apple-specific amd64 hardware. For the Pinebook, maybe a GitHub issue for aarch64 is a good place to start.

This is pretty much exactly what I wanted in an OS. Decent lite-weight desktop BSD with a Graphical installer that isn't TrueOS (I don't like it).

Why is the graphical installer important to you? Is it to check the GPU is supported? You can usually install a DE after the initial install of the OS easily, and FreeBSD and OpenBSD at least have very nice user friendly installers.

Yes I know. I can install it fine. Do I particularly want to use a text based installer than looks like something from the 80s? Nope. I have an Amiga 1200 on my desk and that has a better installer than most BSDs. This is essentially a dead OS that fits on 5 floppy disks has a proper graphical installer and BSD doesn't. Icaros (Amiga clone OS) has a better installer than most BSDs.

Like it or not Windows with its spyware is the only Desktop OS that isn't tied to expensive hardware or has the problems of Linux (which will get worse as things become more corporate) and has decent software and hardware support i.e. my Nvidia card is supported (No Radeon cards aren't an option mainly because they tend to be garbage IMO and every card I've owned that been a Radeon has had problems). Also Windows is pretty stable for the most part even with the forced updates and annoyances of having to turn all the garbage off.

> You can usually install a DE after the initial install of the OS easily, and FreeBSD and OpenBSD at least have very nice user friendly installers.

The partitioning for OpenBSD the last time I bothered looking at it was asking me to work out cylinders and all sorts of other crap. When I was at uni and had free time I didn't mind getting the calculator out and working it all out, now I just do A for auto partition and hope it is okay (which isn't good).

I have a ISO somewhere where I scripted everything up and then one of the released broke it and I just gave up and stuck CentOS on the machine and only use OpenBSD now in VMs for hosting.

What's window manager they are using? It must be light weight to run on just on 1G of RAM.

Oh wow, now I feel old. I remember compiling and running Java course work on a laptop with 8MB of RAM. The display was monochrome, and the compiler literally took ten minutes to spin up (as go get, and drink a cup of coffee before it's done - probably swapping like mad). But it worked well enough with x11 and fvwm.

I see i was on a supercharged "pro" workstation with that much ram, though:

http://www.fvwm.org/history/

> There were two or three reasons for starting FVWM and RXVT. First, I had a need 33 MHZ 486 laptop PC with only 4 MB of RAM, and I thought linux and X11 were way better than the windows versions of the day. X11 with TWM and xterm would run on my PC, but just barely.

That's funny, because fvwm is much more usable than twm. I would have guessed it would be heavier on reasources because twm didn't do much.

I got on a nostalgia kick recently and switched back to fvwm on one of my machines. (Which incidentally runs FreeBSD.)

Wow. Looks like a lot of old computer can be put to good use.

fvwm was always faster than TWM, even if at a first TWM runs faster. Also, TCL would be faster than Java :)

Maybe back then, but nowadays I'm pretty sure java is a lot faster than tcl.

Actually the small Java gui app (tick tack toe, or something like it, I think) ran fine. And I think the startup problems with javac might have been solved too (use less ram) - but I never did get around to it. I think I tried IBMs "jikes" compiler, which I think was (at least partially) implemented in c++.

But mostly I was just shocked anyone could think running a wm could reasonablyrrequire a gig of ram...

>But mostly I was just shocked anyone could think running a wm could reasonablyrrequire a gig of ram...

Eh, most people run Fvwm/Blackbox/WMaker with 16MB/32MB of RAM. 8... well. To be confortable enough, maybe with NetBSD, FVWM, URxvt, a ultraslimmed kernel and jikes/any tiny Java compatible VM.

To be fair, WMs do not use much RAM, it’s DEs that do.

What is the distinction between DEs and WMs?

wm just manages windows, DE is usually this + a full application suite e.g. preferences UI, File Browser, web browser, photo viewer, etc, etc, etc and some kind of 'component' mechanism so that those pieces can interoperate better (e.g. file browser reads from some settings application to determine what photo app to open things with)

A DE manages user’s view of applications and, in general, the overall user experience (usually in the GUI setting); it also provides an API for applications to seamlessly fit that experience. Window management is but a small part of this.

A DE is a desktop environment and includes niceties like text editors, settings applications, music playered, and things that make an ecosystem. Gnome and KDE are the two most popular DEs. WM is a window manager and just handles well, window management. Sometimes that included decoration and styling, usually it includes moving and closing and minimizing them. Think, Mutter, Sway, or fvwm. A WM is a subset of a DE.

I'm pretty sure regular Ubuntu would even run fine on 1gb! Would probably eat half your ram at idle though.

...huh?

My window manager is currently taking about 65K of RAM, and X is using ~800K.

Granted, I run a pretty lightweight setup, but a 'normal' ship can't be 4 orders of magnitude higher, can it?

I cannot believe those numbers. I've never known X to use 800KB of RAM.

IIUC it needs to hold at own one screen-sized framebuffer in memory, which is ~5MB on my system.

Practically speaking Xorg right now is using 460MB of virtual memory, 39MB resident, and 22MB shared (and that's _without_ Chromium running, ha).

And i3 is using 56MB virtual, 33MB resident, 32MB shared.

Also, for reference, "sleep infinity" uses 2324K virtual, 704K resident, and 640K shared. You might be able to beat that by working entirely in assembly language and using hair-raising allocation tricks like using the few KB of stackspace kernel gives you as your heap...? I'm not sure.

Won't the screen-framebuffer be on gpu? Also, virtual memory shouldn't really matter.

Anyway:

    $ ps aux|egrep -i '(xorg|fvwm)'|awk -c '{print $2}'|xargs sudo pmap -x|grep 'total kB'
    total kB          808332  124808   86204
    total kB           64920   15724    2984
    total kB           61656   14428    2400

> Won't the screen-framebuffer be on gpu?

Not in X11. The front buffer needs to be in memory because it gets populated on-the-fly from windows via the Expose event, and the processes that those windows belong to need to be able to draw to it as a result. The protocol was also designed before there was any modern concept of "GPU memory", and couldn't assume the presence of anything more than very primitive 2D drawing hardware.

Another thing that can cause some extra memory use is applications caching pixmaps in the X server. X11 lets you register pixmaps server-side so that they don't have to be repeatedly transmitted across a network. This is great for X forwarding over networks, but largely unnecessary on modern hardware where both the server and clients reside on the same machine, and can cause the server's memory usage to balloon, especially with applications like web browsers.

That's 800 MB, not kB. Even the smallest process in your example is 14 MB.

OpenBSD:

SIZE RES

47M 41MB Xorg

2324K 9328K cwm

Maybe for "normal = GNOME/KDE"?

It looks like Openbox. I see openbox and xfce in the packages listing.

Reply on news.ycombinator.com