211–220 of 221 posts
Earlier quoted context omitted.
> FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works). A ZFS-aware loader hit CURRENT in late 2008, and a dedicated zfsloader for use from (gpt)zfsboot hit the stable branches in late 2009.
AFAIK it's not in RELEASE yet though.
Earlier quoted context omitted.
AFAIK it's not in RELEASE yet though.
They were in 7.3-RELEASE, March 2010. https://www.freebsd.org/releases/7.3R/announce.html
Anyhow, thank you for the correction :)
Because I have a FreeBSD box with this: $ uptime 11:23PM up 835 days, 5:33, 1 user, load averages: 0.07, 0.02, 0.01
Shucks,one of my favorite stories about COHERENT was the near 2-year uptime of the port to Z8000 running on a bunch of disconnected hardware sitting on a table in an office.
Earlier quoted context omitted.
cp --reflink
One of the few feature btrs has which ZFS hasn't.
http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...
Earlier quoted context omitted.
Yes, root's shell should be one provided by the distribution's base install. I think the biggest worry is that if you need to do something like boot into single user mode for an emergency recovery, and /usr or /usr/local (with root's shell in it) is on a different or unmountable partition then you will not be able to do anything.
Additionally, if you upgrade your shell, or something gets borked, then... you now don't have a shell.
For those of us that are more interested in FreeBSD due to the whole Systemd 'controversy', look at the other HN link about the 'FreeBSD: the next 10 years' presentation. They clearly state that FreeBSD is in the same position and it seems that they are not hostile towards the concept of Systemd. Personally I hope that FreeBSD will choose a solution that does not involve QR codes (not mandatory).
Opponents of systemd aren't opposed to smarter dependency tracking at boot time. We're opposed to vendor lock-in (making desktop environments and regular GUI applications dependent upon it), an intentional and strong lack of portability (especially important given the former), pushing software into production servers before it is stable and mature, the backroom politics involved in this displacing other competing tec…
> an intentional and strong lack of portability He doesn't want the added complexity to support OSs which are over a decade behind. Should Microsoft still support Windows XP? Seems like some of the BSDs are already planning on forking it anyways, which is precisely what he wanted.
> pushing software into production servers before it is stable and mature It's been on production servers over at Red Hat for about three years now, and thus quite mature.
> the backroom politics involved in this displacing other competing technologies I haven't seen any proof of this yet, but feel free to link some beyond him showing why systemd is better. Is he actively poaching OpenRC developers or something? Shit, even the upstart creator admitted systemd was designed better.
> the move to corruptible binary log files It's just KEY=value. When a log file is corrupt, it's just the particular portion of the entry which is affected, you can still read the others. Or, just have it forward to the syslog of your choice.
> the assimilation and/or replacement of countless other services that already have more mature and stable implementations While being maintained under the "systemd" umbrella, only journald is required by systemd. Feel free to ignore the rest if you don't approve.
> The PID1 requirement This is _absolutely necessary_ for any init system. The very definition of "init" implies it.
> coupling itself tighter with the kernel There have been zero changes which will _only_ effect systemd.
> the aggressive and hostile attitudes of the lead developers Mr. P is actually incredibly kind and helpful, you shouldn't only look at the few cases where the peanut gallery pipes up. See: Linux, Theo De Raadt...
> the complete lack of choice being provided from nearly all major distros It's always been like this, you just haven't noticed. How many other init systems did they have scripts for before? That's right, none.
> Debian dismissing their heritage as a rock-solid, stable, conservative distro Refer to me mentioning that systemd has been battle tested already, and has the full backing and support from a commercial entity on top of that.
> Further, rc.d really isn't anywhere near as bad as SysVinit You chose one of the simplest examples possible with Mumble, and it's still needlessly complex. RC still uses a scripting language as a necessity instead of declarative syntax, needs a process watchdog, unique device names, socket activation, etc. Compare it to systemd:
[Unit] Description=Mumble Daemon After=network.target
[Service] ExecStart=/usr/sbin/murmurd -fg -ini /etc/murmur.ini
[Install] WantedBy=multi-user.target
Earlier quoted context omitted.
Indeed. This thread should really be titled OpenBSD vs. Linux. I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user. Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant…
> I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user. Maybe the first , but these articles claim Fedora can do it too, although currently you need to edit a config file, and it only works if you invoke startx(1), not when logging in from gdm. http://hansdegoede.livejournal.com/14446.html http://hansdegoede.livejournal.com/14268.html
"X is now rootless with the help of systemd-logind, this also means that it must be launched from the same virtual terminal as was used to log in, redirecting stderr also breaks rootless login. […]"
https://www.archlinux.org/news/xorg-server-116-is-now-availa...
This is obviously not a feature of archlinux itself, but an upstream x.org feature.
Earlier quoted context omitted.
This is why OpenBSD is the superior desktop operating system. Fixed months ago. :)
Indeed. This thread should really be titled OpenBSD vs. Linux. I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user. Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant…
Attempting to talk about "Linux", as if some single operating system - lack of pluralism between commenters to handle the differences notwithstanding - is a problem with this thread.
One of the biggest differences when compared to Linux distributions is that you have a base system which split from third party software. This is true for the other BSDs too. I think that's a huge point for people using one of the BSDs. The reason is that in practice it means you can have a stable and recent system. Where in Ubuntu on Debian one usually relies on third party repositories having a stable FreeBSD with the latest PostgreSQL for example is something you can decide on having. In fact that is so inherent that they have a lot of PostgreSQL versions in their ports tree which means you are not forced to use the old or the new version. However in a production environment it also means you want to use a tool like poudriere (extremely easy system to build packages and install them with the package manager on other systems. It's really easy) so in case you have a library dependency you don't get stuck. In the PostgreSQL example that would be true for PostGIS. That's actually one of the primary reasons for me using FreeBSD in production. I don't have a day or more to make PostgreSQL version X working on a system and then making that setup work with PostGIS version Y. If you have such a problem you really should have a look at FreeBSD and poudriere.
And then there are tons of small things. Packages come as intended, unmodified. pf and ipfw are (in my opinion) way nicer than iptables. jails are a nice way to abstract your system using virtualization (even though there is LXC). Sane and secure defaults are another I really like. Sometimes you want to change them for performance reasons, but most of the time it means that you don't have to worry about stuff popping up.
Then a personal experience: Updates and upgrades are nice. They always work out for me. I don't think that this is a pure FreeBSD thing, but I have used many systems where I had to be really scared about upgrades. FreeBSD isn't one of those.
It has nice tons of nice features like HAST. That is file system replication. I am not talking about ZFS here, which is also a really fine thing. If you somehow work with files, especially when it comes to high availability you should take a look at FreeBSD for both ZFS and HAST.
My biggest con until recently was performance. Linux had especially when it comes to HD access and stuff like memory mapping (something all kinds of DBs need to be performant) a standing way ahead of the BSDs. I think as of now the order for such things (based on various PostgreSQL benchmarks) is: DragonFly BSD, Linuxm FreeBSD, with DragonFly being the fastest, but all of them being so close that it mostly depends on specifics of Hardware, data set, exact DB version, etc.
Another problem you run into is that the world is often very Linuxy and it's especially at the beginning really hard to grasp that FreeBSD is not Linux. It is a separate operating system, just like FreeBSD, DragonFly, NetBSD, OpenBSD and MacOSX are all different BSDs. They simply are, so you can not really expect things to work in the same way and making things closer to something like Linux means that they will lose their strengths and disadvantages.
If you are happy with Linux then there is no reason to use FreeBSD. Neither system is magically perfect.
I mostly enjoy FreeBSD for knowing what is going on and I think that has mostly to do with people having a similar way of thinking and should there be a problem I will easily get to the right track. However as a matter of fact I know lots of experts with something like RedHat or Debian who have the same experience with those systems.
What I really want to disagree with because people always mention it is that using FreeBSD is hard. If you ever installed and configured Slackware, Arch Linux or Debian from scratch then installing any BSD will most likely be easier. However it is different. It is not like knowing Linux and trying just a new distribution, even if it at some points looks like it. OpenBSD might have a scare install procedure, but in the end it is just doing the ordinary stuff without using ncurses, GTK or whatever. It has questions like "Do you intend to use X11?" and you enter y or n. At first boot you have a nice mail in your inbox, etc. That's about as hard as it gets there. Slackware and Arch Linux can be way harder to use (I use Arch Linux on the Desktop and have been using it since its beginnings).
What is really great about the BSDs is how much they care about good official documentations, be it on their web pages, manual pages, etc. A big mistakes people sometimes make is going the usual Linux way googling for the problem they wanna solve. On the BSDs the documentation on the website will usually tell you things so you understand them. They are at a really good shape and things are rarely outdated. People really consider good documentation part of their software. There is a total lack of attitudes in the way of "I will do documentation later" or "It will be outdated soon anyway, so why care?". Community wise there is an age difference. There have been surveys on that. BSD folks tend to be older, both when it comes to users and developers. That's just a side note, because you asked for differences. Also I seem to be an exception here, because my first contact with FreeBSD was when I was 16 or so. So that's really just stats.
Sometimes stuff really is Linux specific, but it's usually only the kind of things that only work on one Linux distribution. Basically every piece of software can be found in FreeBSD ports, but if you have something that is optimized for Ubuntu for example (so basically things you find on GitHub) you might run into troubles getting in run on FreeBSD. However, you will usually also have some issues trying to run that on RedHat or Slackware then.
The most common problem I run into when using something made for Linux is shebangs that look like '#!/usr/bin/python' instead of '#!/usr/bin/env python' (FreeBSD has third party software, so everything you install as a package in /usr/local/bin). However, since I am an Arch Linux user I also run into that problem, because Python 3 is the default.
One last thing: You will most likely learn to use sysctls. FreeBSD tend to be extremely conservative about certain settings. That is good from a security point of view and from preventing servers to get into a state where you can't even connect to them anymore, but sometimes that is a hindrance for your performance. Typical example are databases again, but then if you think about PostgreSQL then you probably know their default settings are also conservative and still work fine for most people.
Taking a look at FreeBSD is really worth it, even if you end up not using it. People in the BSD community often respond something like "If you are happy with Linux why would you want to switch?". That might be related to their age, having used many tools seeing how everything has benefits and weaknesses. However, you really have to keep in mind that it is not Linux. It really is a different operating system and some things will be weird first. It's like learning a new programming language, maybe even a new paradigm. People in the BSD community don't usually try to convince everyone and they want people to understand stuff, so you will maybe have a hard time if you ask for copy&paste resolution, like on Ubuntu forums or so. That might also mean that you will end up understand the system in a more in-depth way than other systems in a really short time.
Saying one of them is better doesn't make a lot of sense anyway even in single instances, because things change so rapidly (see the LXC example). FreeBSD might suit you needs, but so might Linux and in a year or so that might have completely changed.