Live data from Hacker News

BSD vs. Linux (2005)

over-yonder.net

71–80 of 371 posts

Re: BSD vs. Linux (2005)

#71

Earlier quoted context omitted.

If you need the portability of Linux coupled with a license that lets you freely redistribute in order to sell an appliance you will be hard pressed to get around NetBSD. It's perfectly legal to sell an appliance with Linux, people do it all the time.

You can't "freely redistribute" it though. You have to comply with the viral decidedly non-freeing provisions.

While I can appreciate that point of view (i.e. as a vendor), the definition does depend on whose POV you are looking at it from. From an end-user (individual or business) POV, the GPL is absolutely 'freely redistributable' what you're talking about is your inability to limit that ability. That's the GPL doing its job.

Re: BSD vs. Linux (2005)

#72
post #51

Earlier quoted context omitted.

You're talking about kernel vs userland. That's not base vs non-base. The BSD distributions unintentionally muddy the waters by calling what is an equivalent of a linux distribution a base system and so lose out on the distinction you are drawing.

No, I'm talking about the Operating System vs. Applications. Drawing the line at the kernel syscall ABI is arbitrary; no other major operating system other than Linux does so. Consider how difficult it is to ship 3rd-party applications for Linux and all its myriad of distributions; the only thing you can truly rely on is the anemic syscall ABI provided by the kernel (vs. userland).

Hmm, I've never had any problems running something on ubuntu, debian, gentoo, redhat, etc. If it works on one then it works on all the others. If push comes to shove I just install the libraries and compile from source but this is a rare occurence and I've only have had to do that when I've relied on a version of Ruby or Python that has not come pre-packaged with the distribution.

So I don't really know what you're getting at. If you're not talking about kernel vs userland and you're talking instead about ABI compatibility then the ABI is even more stable and requires even less work to port any piece of software from one distribution to another.

Re: BSD vs. Linux (2005)

#73
post #48

Earlier quoted context omitted.

This is an increasingly solved problem in the post-systemd world - /etc contains local configuration, system configuration is in /usr. We (CoreOS) support you doing mkfs on / in order to return to a default configuration built from the /usr config.

If that's your definition, then FreeBSD and Solaris solved this without paying the systemd tax, via ZFS-based boot environments. https://www.freebsd.org/cgi/man.cgi?query=beadm&sektion=&man... NeXt->Apple also avoided anything like systemd via a configuration system that supported inheritance across search domains (User, Local, Network, System): https://developer.apple.com/library/mac/documentation/Cocoa/...

Oh, there's certainly multiple ways to do this. My point is purely that this isn't an inherent Linux/*BSD thing - there are modern Linux distributions that have precisely this property.

Re: BSD vs. Linux (2005)

#74
post #30

Earlier quoted context omitted.

Too much. I've got a 700-800 MB system. It's unfortunate, as I'd love to have a versioned FS

Wow, with RAM costing something like $5 a gigabyte these days....do you want us to take up a collection to help you out? I'm not above a little charity, I'll send you a fiver to help you get a real computer!

[deleted]

Re: BSD vs. Linux (2005)

#75
I like FreeBSD, and I use it as a server OS and on a NAS box but you only need look at https://wiki.freebsd.org/Graphics to understand that if the "Linux Desktop" is a joke compared to MacOS and Windows then the "FreeBSD Desktop" is even more so.

From my experience of "old" computers, workstations, and then "PCs as Workstations", Windows won the desktop because the UNIX camp could never check their egos at the door and get their act together on a windowing system and graphics architecture. And while it was brilliant that you could do the "heavy lifting" on a server and do the display part on a less powerful machine, that architecture should have been taken out behind the barn and shot the moment 2D and 3D acceleration hit the framebuffer cards. Instead we have the crap that I have to put up with, which is a wonderfully compact and powerful system (A NUC5i7YRH) with a graphics architecture that is not supported at all on FreeBSD and has pretty egregious bugs on Linux, and runs beautifully on Windows 10.

For the conversation at hand though, the Linux graphics pipeline teams are much better at getting things working than the FreeBSD team, even though FreeBSD is much more "friendly" to non-open drivers.

I would love to have a nice, integrated, workstation type experience with a UNIX operating system but that music died when SGI and Sun through in the towel and tried to retreat to the machine room.

Re: BSD vs. Linux (2005)

#76
I'm a total linux user and have tried *Bsd from time to time. For some reason, the bsds have always taken a very long time to boot up and even to start X. The last time I tried FreeBsd (about 3-4 years ago), a friend asked me to help him debug why X windows didn't run. It was taking 15+ minutes to startx on his brand new server class PC that he built up himself. We didn't realize that it took so long to start up until we went out for dinner and came back, surprised to see X had started. Same with OpenBsd, it took 10+ minutes just to boot up. I thought I didn't install it correctly and re-installed it a couple of times. I'm guessing, the Bsds are meant to be run continuously and not shut down? I've asked a couple of other Bsd people, and they couldn't provide an answer, so I'm left up in the air about that.

Re: BSD vs. Linux (2005)

#77
Very informative article, thank you. This article is missing discussion on ArchLinux ( probably because it is very old ? ). Arch has a minimal base system ( no X etc ) and you can build the system you most like.

Also Linux now uses git for development.

> And normally, you do the whole rebuild process in four steps. You start with a make buildworld which compiles all of userland, then a make buildkernel which compiles the kernel. Then you take a deep breath and make installkernel to install the new kernel, and make installworld to install the new userland. Each step is automated by a target in the Makefile.

> Of course, I'm leaving out tons of detail here. Things like describing the kernel config, merging system config files, cleaning up includes... all those gritty details.

Wow, so painful. For me its as simple as :

$ pacman -Syu

and watch some movie. I bet the BSD way offers more opportunities to learn but I personally don't like learning for the sake of learning. Learning different ways to do the same thing does not make me a better person. So this is not interesting to me.

> Does Linux support hardware that BSD doesn't? Probably. Does it matter? Only if you have that hardware.

I could obtain that hardware at some point in the future.

> "But Linux has more programs than BSD!" > How do you figure? Most of these "programs" you're so hot about are things that are open source or source-available anyway.

Given an application, does the provider support it on your OS is an important consideration that people make before choosing to use an OS, as they should.

> Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.

Isn't this what NixOS ( https://nixos.org/nixos/about.html ) is supposed to be solving ( among other things ) ?

I might try a BSD for the novelty aspect of it, but so far I have seen no reason why it should be better.

Re: BSD vs. Linux (2005)

#78

I'm a total linux user and have tried *Bsd from time to time. For some reason, the bsds have always taken a very long time to boot up and even to start X. The last time I tried FreeBsd (about 3-4 years ago), a friend asked me to help him debug why X windows didn't run. It was taking 15+ minutes to startx on his brand new server class PC that he built up himself. We didn't realize that it took so long to start up unti…

I can't confirm that. By virtue of being very minimal out of the box I've found BSDs boot very quickly.

systemd has arguably made Linux bootup faster than before but I would expect a default BSD to be quicker than a bloated Ubuntu default install.

Re: BSD vs. Linux (2005)

#79
The only thing that's preventing me from switching my desktop (laptop) OS over to BSD is chipset support. I tried 11.0 ALPHA, but couldn't get anything other than VESA video going.

My setup scripts are all in Git:

https://gitlab.com/duncan-bayne/freebsd-setup/wikis/home

I've used a few different OSs on a daily basis for work and recreation: Windows (since 3.0), Linux (various distros since 1995), OSX (for a few years between 2009 and 2013), and FreeBSD.

I have found BSD to be the most comprehensible, simplest and the best 'cultural fit' for the way I think and work. I appreciate that the latter part is a bit vague, but that's because my understanding of it is vague :) BSD just feels ... more like home.

Those wanting to give it a go as a desktop OS should check out PC-BSD, which is built to be usable 'out of the box' for that purpose:

http://pcbsd.org/

Re: BSD vs. Linux (2005)

#80
post #37
post #5

I was a long-time FreeBSD user. Started using it in college and continued for a long time. I started using Linux because I had bought myself a new laptop and BSD didn't recognize the wifi card. I continued using FreeBSD at home for a few more years on my webserver before ultimately moving to dreamhost (I just didn't have the time to keep maintaining my own server). I like using Linux, but I still miss the predictabil…

> anything I install from source sits in /usr/local To be fair, this is the norm on Linux too. I have never used BSD as a desktop operating system, but everything I've installed from source also sits in /usr/local. It's the default install directory for most Linux build scripts and I feel dirty if I add anything directly to /usr that the package manager isn't aware of.

Right; the distinction isn't so much "installed from source" as "installed without the package-manager's knowledge." If you `apt-get source`a Debian package, apply a few patches, and `debuild` it, the resulting package should install to the /usr prefix like the rest—because it's being tracked like the rest.
Post reply on HN