Hacker News Reader

Comment by 2trill2spill | Hacker News Reader

After a year of trying Ubuntu as my at home dev machine, I'm going back to FreeBSD. FreeBSD is much more of a pain during initial setup, but then it just works. Where as my laptop with Ubuntu has the most finicky Wifi and freezes way too often, and I didnt have these problems with FreeBSD on the same hardware.

View on HN

I love FreeBSD. Been using it in a server context for going on 20 years now.

Trying to use it on a desktop takes me back to, well, trying to use Linux on the desktop 20 years ago.

Recently started shopping different distros because I’m not comfortable with the direction Ubuntu is going and rather than upgrade my 18.04 when it’s EOL’d, I’m looking at just hopping to something else for my work laptop.

Took hours to get X working with my laptop’s graphics card (though most resources I found online said it wouldn’t work at all, so that was a nice bonus). Not “get accelerated graphics working” just “get X to start”.

Spent another couple hours screwing around trying to get the trackpad working. And not just “get it working to my liking” but get it working at all. Turns out it’s entirely not supported as a lot of modern laptops uses a I2C connection rather than USB/PS2/etc, and there’s just no driver support for that. Never did get that resolved.

A lot of desktop apps that I use are either unavailable or require a lot of dicking around to use at all. There is no Slack desktop client. You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.

You’ll pry my FreeBSD servers from my cold dead hands, but it’s certainly not my go-to for a desktop OS.

I don't know what century you've tried freebsd, but trackpad works nearly otb and otb in new xorg. Accelerated graphics works fine with intel (YMMV depending on the chip), nvidia (if you install driver from nvidia and not opensource one), amd.

> There is no Slack desktop client.

There is no Slack desktop client for any platform. It's just a web browser. You can make "desktop client" yourself.

> You cannot run Docker natively, and instead I ended up setting up a Debian guest OS under bhyve, which harkens back to how Docker is run on Windows/OSX and all the caveats that entails.

Actually, this setup works MUCH better than Docker on Mac. Which is good enough for developer. Looking at 3 laptops right now: mac, windows and freebsd. Docker user experience goes linux (non-rhel based) > linux (rhel based ) > windows > freebsd > mac.

That being said, FreeBSD isn't "Oh, I will try running freebsd on this machine", FreeBSD is "I'm buying this specific machine because it runs FreeBSD". I use it both on my desktop and laptop.

I've had some success with running Linux binaries with the Linux emulation layer, that could possibly work for the Slack client? It tends to fall down with things that are native binaries mixed with shell scripts though, like I recently tried to run Steam and gave up, because I hit my (very low) limit of munging other people's shell scripts; they were calling a program and FreeBSD has the program, but the output is different, and the arguments are different, and I wasn't sure that I'd be able to run the thing I wanted to anyway, so I cut my losses early. It turns out, the thing I wanted to do doesn't (easily?) work on Linux Steam anyway, so I made a good choice. :)

The linux layer does not work for electron apps, sadly. I run a FreeBSD desktop, and I have a linux VM to run electron desktop apps.

My understanding is that the core issue is a lack of support for the linux sandboxing syscalls that chromium (the basis for electron) uses.

I agree that the DRM/i915/amdgpu experience leaves something to be desired. (?)Ironically, the nvidia drivers are rock solid and just get out of the way, which has also been my experience on Linux. The only real fault I have with nvidia on FreeBSD is that they don't ship CUDA/NVENC/NVDEC.

With a stable GPU, the desktop experience is more or less identical to Linux, IMO. (I've been using Linux desktop since the mid 2000s and FreeBSD desktop since mid 2010s.)

Just for information, this what everyone uses for I²C connected HID devices: https://www.freshports.org/sysutils/iichid Works perfectly well.

And ScudCloud (net-im/scudcloud) is a Slack client.

If you decide you need Linux due to drivers or whatever, I'd recommend giving Arch a try. Arch has a reputation of having a learning curve, but it's no worse than the FreeBSD and like the BSDs it has excellent documentation. In my experience, Arch has been very stable with few surprises, especially if you avoid unnecessarily complicated software like GNOME. I can't say the same for Ubuntu or Fedora.

If you're able to get your drivers and all working with FreeBSD then good for you! FreeBSD is awesome and I'm always happy to come across it.

Not related to the post itself nor to FreeBSD:

I personally feel sad when people state (indirectly) that Linux is NOK because their Ubuntu didn't work well :(

Ubuntu is probably the only Linux distro which I hate => I admit that it's a bit a mixed situation (Ubuntu seems to be a kind of "lighthouse" for the Linux world), but in the end I personally think that it's a pity that it acts as representative of the Linux distros.

I'm currently using Gentoo & Mint & Arch (depends on the usage), and in the past I liked as well at least Fedora and CentOS (not using them since a long time), but I never liked Ubuntu.

what do you mean by lighthouse?

Like a "point of reference"

I hear ya, but as a counterpoint to my above post I've yet to have a issue with Linux in a server context, although I tend to use FreeBSD on servers where ever possible. The only time I've had issues with either FreeBSD or Linux is using it as a desktop/dev machine. They are both awesome operating systems, I just prefer FreeBSD.

Do you actually get working wifi, suspend/resume and acceptable battery life under BSD?

Last time I tried (open)BSD, none of those things worked acceptably. The recommended way to connect to wifi was to manually edit wpa_supplicant.conf and battery life was a solid hour less than under linux.

I feel like BSD is a great "laptop OS" if you're the kind of user that leaves their thinkpad plugged in all the time, essentially using it as a small-form factor desktop.

Maybe it's better nowadays.

Suspend and Resume was the hard one, battery life is solid, although I haven't done a direct comparison with Linux. Wifi was easy but not as easy as Linux to setup. On Linux wifi worked out of the box but I would lose wifi a couple times a day. While on FreeBSD I had to edit a few config files to get wifi working but I dont lose wifi every day. To get the Suspend and Resume to work I had to use the drm-next-kmod port.

BSD isn’t like Linux where it’s the roughly the same kernel and user land but a different distribution of packages. OpenBSD and FreeBSD are entirely different operating systems albeit with a shared lineage.

> Last time I tried (open)BSD

Sorry, but OpenBSD and FreeBSD are very different operating systems, it's not just "different distros" like in the Linux world

Whatever you tried in OpenBSD has most likely no relation to FreeBSD

Speaking of the things you mentioned, I personally would expect suspend/resume to just work out of the box in the latest OpenBSD, but not necessary in FreeBSD (it was never a priority for the developers).

You also don't need wpa_supplicant in OpenBSD (unlike FreeBSD), ifconfig should be enough in most cases.

For the battery life, you certainly gonna need some tuning, as it's not a config priority by default, but generally (on mainstream hardware) you should be able to reach at least 80%-sh battery life comparing to Linux in OpenBSD, and comparable to Linux in FreeBSD

>For the battery life, you certainly gonna need some tuning, as it's not a config priority by default, but generally (on mainstream hardware) you should be able to reach at least 80%-sh battery life comparing to Linux in OpenBSD, and comparable to Linux in FreeBSD

Yeah, see, that's unacceptable to me in a laptop.

I have a small pcengines apu2 running openbsd but I don't enjoy tinkering with it. I find it cumbersome and unwieldy. The documentation seems to be mostly "complete" but it's definitely geared at someone who already has an in-depth understanding of openbsd, and lots of fundamentals are left unsaid, which makes it difficult to learn what the "proper" way to do something is. I end up with a patchwork of hacks and it's very unsatisfying.

It took me quite a long time to figure out how to get wireguard working on that box, for instance, whereas on linux and mac it "just works" pretty much out of the box.

> Yeah, see, that's unacceptable to me in a laptop.

I think you missed the last clause here:

> > comparable to Linux in FreeBSD

No, I didn't. Linux battery life is pretty darn close to windows on my hardware, out of the box.

Getting freebsd to the level of Linux only after significant tinkering just isn't a good ux. For my personal machine that's unacceptable.

You said above you were using OpenBSD not FreeBSD, they are completely different operating systems. Also getting the battery to last long on FreeBSD was a super simple config change, that took less than a minute to do.

>and lots of fundamentals are left unsaid, which makes it difficult to learn what the "proper" way to do something is

man afterboot

Suspend/resume is definitely a priority for everyone who uses FreeBSD on their laptop, which is - judging by various FreeBSD conferences - increasingly popular.

Editing wpa_supplicant.conf is rather user-unfriendly, but it's literally a four line copy/paste followed by adjusting two lines of config file; I suppose nobody could be bothered.

Do you need to edit wpa_supplicant.conf ? I recall just doing ifconfig ssid XXXX pass YYYY for wpa?

I'm not sure; I edit wpa_supplicant.conf, because I want the change to be persistant across reboots. Nothing like doing kernel development directly on your laptop; keeps you focused ;-)

/etc/hostname.if under OpenBSD

lladr random

join foo wpakey bar

dhcp

inet6 autoconf

Maybe that was for WEP? Pretty sure that wpa_supplicant is needed for WPA.

This is my life with FreeBSD:

> wifi

WiFI is working, but not `802.11n/ac`, so you're limited to `802.11g` which sucks, but I use it with ucb-c dongle, so not much of an issue for me. I don't use any GUIs for WiFi because I use the same 3 networks.

> suspend/resume Yeah, just like linux it doesn't support fancy states that windows does, but suspend to ram works. Works perfect with laptop lid, but you do need to change a sysctl thingy.

> Battery life

I can go entire work day on a single charge for my x1 carbon (gen 6). I know that because I forgot to plug it in multiple times.

I'm sure OpenBSD has it worse tho.

I've never edited or even had a wpa_supplicant.conf file under openbsd.

OpenBSD handles WPA2 thru ifconfig just fine.

ifconfig $IFACE join $ESSID wpakey $PASS

I tried NomadBSD in order to use RDP, but I couldn't get an earlier version of Remmina or xfreerdp.

It might be my lack of experience with BSD, but I got the impression that it is very hard to get a previous version of a package with BSD.

edit: corrected the name NomadBSD

I've never heard of MonadBSD, but installing a previous version of a package is straight forward on FreeBSD. Just specify the version when you use pkg or use portdowngrade.

Do you mean NomadBSD? Hearing MonadBSD and thinking about Haskell, I suddenly got really curious, but couldn’t find anything on Google...

> Hearing MonadBSD and thinking about Haskell, I suddenly got really curious, but couldn’t find anything on Google...

That would be a fun name for the BSD answer to nixos...

Heads-up: Nix is on its way to start working on FreeBSD: https://github.com/0mp/freebsd-ports-nix

My bad, it was NomadBSD.

The freezing is not an Ubuntu problem it's a GNOME problem.

Thanks for the heads up, is there a straight forward work around? Or don't use GNOME?

Any docs to this effect? I'm curious to check them out because I've had flawless wifi under GNOME across various work laptops since at least 2010. Maybe it's Ubuntu+GNOME specific, haven't run Ubuntu, but it certainly doesn't seem to be GNOME.

Ah, on re-read of the OP comment, it's "wifi issues and freezing", two different problems they had. Have never seen either from GNOME though.

Wifi in Linux distros is not handled by the DE. It's usually systemd-networkd and wpa_supplicant.

GNOME is very slow. The UI and animations are implemented in JavaScript. KDE Plasma isn't much better though. You should try using a tiling window manager.

> The UI and animations are implemented in JavaScript

This should be a criminal offence

> The UI and animations are implemented in JavaScript

Can you point me to the code implementing an animation in JavaScript?

Here, took me less than 30 seconds to find one:

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/0db41a3773...

It's everywhere

My confusion stems from the fact that when you say "implementing" animations, I think of shuffling pixels around. By your logic, every HTML marquee tag "implements" an animation.

>You should try using a tiling window manager.

Or just a sane floating one like Fluxbox. Taskbar, systray, window merging by title, Zukitre themes to match the GTK ones and dead simple to setup, with no XML such as the "other one".

Reply on news.ycombinator.com