FreeBSD/PC-BSD 10.2 vs. Ubuntu 15.04/15.10 Benchmarks

[aht0]

If some developers choose that they like one particular way of coding and they don't mind other people using their code, making money off it, modifying it or both, it's their own free choice. Respect it. I assume you would like your work to be respected by other people? If you don't like their creation, don't use it. And, it would be nice not to try bashing it relentlessly as "garbage" compared to "Your Shiny Thing(TM)" . Especially, considering the fact that over the years, plenty of code from those "primitive" OSes have found it's way over into Linux.

It has been true. Up to kernel 2.6.28 or so, and 2.6.28 has been released some SEVEN YEARS AGO. Seems your data about Linux are a bit stale, huh? I can understand, if I take 7 years old BSD and current version, it is hard to spot differences. But Linux can afford a better development speeds, and 7 years is quite a number. For me, Linux 2.6.28 is just antique. Oldest kernel around me is 3.12 on my router, just because I've been lazy to reflash it with newer openwrt.

- I could tell if FreeBSD version was even 2 years old before it finished booting. Seems like your experience is equally stale.

- Why update working device at all if it ain't broke?

I used linux starting from Red Hat 5 and stopped using it daily about 3 years a go. Over the years got slowly sick of code that's randomly audited or not at all resulting countless bugs, functions that sometimes work just half-way, shit breaking after updates. Final "fuck it" moment came where freshly burned installation DVD refused to recognize USB keyboard/mouse (Ubuntu 13-smth).Such a fucking rookie mistake from Canonical. Looking for alternatives I decided to migrate. I had played before with FBSD but never really jumped over. I'd rather save my time sticking to slower and more stable progress, instead of spending hours swearing at yet another piece of half-cooked piece of shit software while looking for fix. Linux is all about progress while half the times utterly forgetting to finish what it started. Something gets almost ready, then dev just drops it and moves on to next item of interest. Sloppy.

Btfrs - not fully mature, certain conditions may well lead to data corruption.

These days it only relevant for RAID5/6 code maybe.

And RAID5/ 6 are not relevant or used these days? And why is Canonical pushing for getting ZFS into Ubuntu as "standard-offer fs" if btrfs is supposedly so mature?

At least from major manufacturers. For home users, you get into trouble if you have Radeon graphics card from 2xx/3xx series and from older HD8xxx series

But I do not get into trouble in Linux. And don't you mind Sony runs AAA games on GCN GPUs in something which is FreeBSD9 spinoff? BSDs have very interesting philosophy, sure.

-Just quick example then. Recent OpenSUSE and laptop with Mobility HD4250. Due to probable bug in linux graphics driver you'd get flicker-flicker-flicker over whole screen each time you move your mouse cursor. Literally unusable, worse than CRT screen @60Hz. Happens with my other laptop that has Mobility HD6290 as well, though on slightly lesser scale. Nothing like it happens while using FreeBSD on the very same hardware. After install, everything graphics related, including 3D acceleration just works.

-Wanna game? Use windows. Better bang for buck, less issues, nicer graphics, more games. I won't bother gaming neither in linux or any bsd. So, no it does not bother me. Why Sony does nothing? Go ask them. Maybe they signed some sort of NDA. Maybe it's just principle. Consoles are closed platforms for gaming. Open the source code and it's main function gets in danger of being disrupted (cheating). Security trough obscurity, not that it often works.

but now it really huge something and plasma is slow, bugged and some plasmoids are just strange.

for a change, got to agree. 3 was very much okay. 4 more or less okay by now. At least it's stable. 5 is nothing I would want to use.

I like systemd, it simplifies system management on desktop and servers, and does it right like I want to see it. It handles plenty of rough edges of system management and coding this all myself could be a major nuissance. In embedded it also kicks ass, as properly admitted by Pengutronix devs.

Yeah, and along with it screw any portability for any other unix-like OS. Not that you can after systemd call linux "unix-like". It's just linux.
"I like it and fuck everyone and everything else" - attitude.
What's wrong with OpenRC Manjaro, Gentoo and Alpine are using?. Smaller, less dependencies, good init system.

[SystemCrasher]

Out of idle curiosity, how many file systems would you need, when existing ones work just fine?

Fancy necro, don't you mind thread mostly starved in 2015? . But let's reply, since I'm fed up with this standard BSD bullshit mumbling...

Like a dozen and half, because one size does not fits all.
- If I'm up for small Linux device like OpenWRT router, squashfs, JFFS and somesuch make a sense.
- If one has got larger RAW NAND flash, UBIFS would do the trick. It does high-profile features one could expect there: bad block management, wear leveling, taking care of "strange" flash programming, ECC and other NAND specific crap.
- If one wants FAST flash-backed storage on something like SD card or usb flash stick, F2FS would kick the ass in terms of speed while not being hostile to flash storages nature. Samsung produces a lot of flash ICs and so they know how to get it right. IIRC it is already used by some Android devices.
- EXT4 if one needs "just filesystem" e.g. to store OS itself. Fast, relatively hard to destroy, good recovery tools allowing to recover even from quite damaged HDDs. Since it fast and does not really hogs resources, could be nice to use on e.g. various "downloaders", routers, ARM boards and somesuch where one attaches HDD.
- BTRFS isnt as heavy as ZFS, yet provides quite decent featuers like snapshots and block-sharing hierarchies using CoW, checksumming and file-aware RAIDs. Very handy to insta-copy some 10Gb VM or large source tree hierarchy, try something out, and if it turns out it haven't worked, ok to delete it, etc. Just unreferences instance of data and only have to discard really small delta. I like it this way. Modern way to handle data. And does not puts too much strain even on my modest laptop. It somewhat slower than EXT4, etc, but in typical cases it is not really noticeable. And ZFS is nowhere close to it in terms of wasted resources vs achieved speed.

UFS2 is rock stable and fairly fast,

That's how BSD fans call outdated garbage using prehistoric storage techs. Sorry, but I can actually read code and get some idea about used data structures and algos. UFS2 is a trashbin of storage techs, even EXT4 weirdling based on prehistoric techs is better than that. At least they managed to get this crap FAST. And somehow "fairly fast" warrants us a lot of fun when ppl like you yell all the time in each and every benchmark on how it has been done wrong ways, blah-blah-blah.

ZFS is both of it and has ton of features. Both are fully usable in production systems.

...and takes shitloads of RAM, or if you cut RAM usage down, it getting damn slow. Nice tradeoff, blah-blah. Sorry, but I think I'm really better off with btrfs. Especially on laptop.

Issue in your case appears to be inability to understand differences in development philosophy for BSDs and Linuxes. BSD devs write code methodically and develop their OS as a whole, finalizing their code, writing the documentation, making sure the stuff would work.

And in practice it rather looks like this:
1) You can get some outdated third-rate crap for free.
2) Or better pay some company for Product and Solution.
3) If you did 2), enjoy by vendor lock, DRM, lack of sources and other "BSD freedoms" stuff.
4) When companies refuse to contribute back (uhm, who has allowed it in license?), BSD devs yell around and offer users to donate instead.
5) Sony tells thanks for donations and code. Makes PS[3,4, ... ]. And "forgets" to contribute back. So Linux runs on PS4 and can light up GCN-based GPU. BSDs just suxx, and while Sony runs AAA games these can't deal with GCN GPUs at all. Sure, it should work this way.
6) When it starts to sunk due to lack of cooperation, most companies are better off running Linus.

Most hilarious thing happens right now: AT&T has gone using ... Ubuntu on their servers. Sorry, UNIX, but you've got totally pwned on your very own field.

Linux: Each distributor does "their" thing, kernel itself is a fairly ungodly mess, rest of the Linux world acts in the way of "before one thing gets completely ready, whole project might get flushed down the toilet and started anew from different angle, abandoned or whatever". Shortly: change for the sake of change.

On other hand, I can always grab something most suitable for that particular task. If I want even more headroom, I would have no trouble changing it the way I need. Because distro infrastructure is actually tailored for such usage. And if I need some custom automation running on ARM board, things like Debian offer me a decent infrastructure to respin my own, task-specific system. And I can handle it single-handed, dammit. If I would try to do the same using BSDs, it would requite huge, Sony-sized corporation.

So BSDs target some abstract use cases and none of real world use cases match it, and it is hard to make something else than that. So I read BSD as Broken-and-late Software Distribution. Stuff like UFS2 is really very well in spirit of BSDs.

Let's look at Linux file systems now. For production system I would only dare using Ext4. All other filesystems being offered in "average" Linux distro have some sort of minor or major issues, be it being superseded, stability or real possibility for data corruption.

So, do you have any major objections against e.g. XFS? Also works well on interleaved multi-disk storages for large files, due to ways it stores data. Last reports about some major damages come down to 2.6.28 or so. And it has been quite a while ago. JFS? Works well on systems with weak CPU and whatever, but it nearly unkillable. Well, IBM does testing and it pays for itself. But it quite slow and not anyhow interesting. Just usual classic design. Not anyhow noteworthy. But used techs are ahead of UFS, regardless of being old stuff. At least it can afford extents, while UFS2 isn't quite there.

Btfrs - not fully mature, certain conditions may well lead to data corruption.

These days it only relevant for RAID5/6 code maybe. Other than that it works more or less like any other filesystem. I use it for ~2 years on some computers and it WORKSFORME. And these days fixes for BTRFS aren't much scarier than fixes for any other filesystem. I think kernels like 4.x are all ok for btrfs. Sure, it is larger design with more rooms for bugs and it takes longer to leverage all features it can do and more time to optimize performance. But it beated dust out of ZFS even a while ago. And facebook actually uses it on its servers. Do you have some larger production environment, lol?

XFS - one power failure and you have new content in files, mostly zeros.

It has been true. Up to kernel 2.6.28 or so, and 2.6.28 has been released some SEVEN YEARS AGO. Seems your data about Linux are a bit stale, huh? I can understand, if I take 7 years old BSD and current version, it is hard to spot differences. But Linux can afford a better development speeds, and 7 years is quite a number. For me, Linux 2.6.28 is just antique. Oldest kernel around me is 3.12 on my router, just because I've been lazy to reflash it with newer openwrt.

Ext2/Ext3 - why use'em when you got Ext4.

There is little point to use them and since EXT4 is a superset of these, EXT4 driver used these days to access EXT2/3 volumes. Basically EXT3 = EXT2 + journal and optionally dir hashing. And ext4 is ext3 + extents, delayed allocs and so on, to speed this ancient stuff up, finally getting to tech level similar to XFS/JFS/etc. It only makes sense to use EXT2/3 to read old drives and upconvert them to EXT4, if any real-world usage is planned. It can be done on the fly, though full speed benefit of EXT4 req's to overwrite files, so extent-based allocation scheme is used instead of bitmap-based. Ironically, UFS2 haven't got real extents so far. Only some half-baked variable blocks, which make design complicated but fail to be lightweight and fast like real extents do. Overall stuff like UFS2 looks like pointless design to me. Interestingly quite same applies to ZFS. BSDs just never were able to develop anything sensible. Uhm, except maybe HAMMERFS in NetBSD. Which isn't a match to btrfs deployed in Facebook in terms of production use.

JFS? has issues with journal writes and is generally slower than Ext4.

Yeah, it is not very fast. As for journal, XFS and EXT4 in most modes all share certain issue: they only journal metadata. Ext4 can also journal data, but it means writing data twice, to journal and to main storage area. It kills off speed. So it rarely used in EXT4 and not implemented in many other similar designs. Things like btrfs and other CoW-based things manage to do

VM.. quoting now https://wiki.freebsd.org/Myths

Notice, the jails. Usable as f'ck sometimes.

On other hand, even bare Linux containers would beat them to the dust. E.g. Linux properly virtualizes net in containers. So you can get own localhost, independent firewall rules, routing tables and shaping, veth pairs to link containers to host or each other, bridge to turn host into switch, etc. These can policy resources usage thanks to cgroups, etc. It is possible to do something actually usable from it.

Interestingly, Systemd is aware of these features, uses them extensively, makes starting up processes in isolated env rather simple and can even help to deploy OS image to virtual hierarchy, if desired. Can also make it one-shot, by virtue of btrfs snapshots, so you can try something, get result and discard environment or re-roll clean copy and try something else. BSD tooling is nowhere close to it, and jails are really half-baked in how they behave. Sorry, but jails looked cool quite some time ago. These days they are very bleak, even without installing extra high-profile products. Sorry, but managing Linux just happens to be much faster, easier and dammit, there is at least some logic. Not some smouldering wreck like in jails networking.

awkward package management. pkg install name-of-the-package is awkward exactly how?

Package management comes a bit further than just installing one package. It also comes down to features of package management tools, overall infrastructure, sane policies, making sense in production environments and so on. If done right, it drastically simplifies system management.

Especially considering I could be compiling also some stuff from source and not having it interfering with the rest of the packages.

I'm also compiling some few things from source, on Debian and Ubuntu. Of course it does not interferes with anything unless I'm doing something terminally wrong. But I only compile like maybe 10 programs, while I have like 2000 packages installed. And it is really nice I only have to fiddle with these 10 and package manager takes care to keep rst 2000 without major known vulns. This allows me to spend my time on doing interesting stuff rather than waste time on maintaining system.

What can't be said for Linux. Compile something from source in Ubuntu, without jumping trough extra loops making the "new" package, etc and you have screwed up package management real fast.

I compile some stuff in Ubuntu. Come on, tell me how "hard" it is. Sure, it takes learning about package manager and how to get things right. No, I do not screw anything up. Actually, most programs these days provide deb-related build files even in their "vanilla" repos. And if someone lazy to do it right, there is quick-n-dirtly checkinstall. Where one can skip learning how to make package right, and still enjoy by ability to e.g. remove built program properly.

Embedded. FreeBSD ARM is quite well supported. You can also use MIPS as long as you stick to supported CPUs/chipsets. NetBSD should run on literally anything. That's the "special niche" of NetBSD. No clue about OpenBSD,

And most of time you have to stick to some ancient shit which is not manufactured anymore. Or at most, "enjoy" by minimal, half-working support. In fact there're so many SoCs these days even Linux struggles hard to catch up. So, how many embedded designs you did using BSD? I've did more than dozen of various custom projects using small ARM SBCs and Linux to the date. And I can handle it alone. It does not takes Sony Corp like it happens in BSDs.

Define "poor hardware support" more precisely. AFAIK enterprise hardware RAID controllers, network cards etc have good or very good FreeBSD driver support.

Would not help me much on desktop or in embedded. And somehow, in Linux I can reuse knowledge about OS of choice. Be it server, desktop or embedded, kernel stays the same, ways it works stay the same, options are mostly stay the same, etc. Most of times I also stick to Debian and derivatives, so system environment also stays the same, with the only major difference being openwrt on smallest devices. It takes quite some tough decisions to fit 4MiB flash ROM, sure.

At least from major manufacturers. For home users, you get into trouble if you have Radeon graphics card from 2xx/3xx series and from older HD8xxx series,

But I do not get into trouble in Linux. And don't you mind Sony runs AAA games on GCN GPUs in something which is FreeBSD9 spinoff? BSDs have very interesting philosophy, sure.

and standby/hibernate is and issue for laptops (except some 220 series Thinkpads). Rest of the tech will work. In fact, I'm writing this tirade from laptop running FreeBSD. Hate SystemD and Plasma5.

I like systemd, it simplifies system management on desktop and servers, and does it right like I want to see it. It handles plenty of rough edges of system management and coding this all myself could be a major nuissance. In embedded it also kicks ass, as properly admitted by Pengutronix devs. Sorry, but I'm really not in mood to code service startup timeouts handling myself. Nor I dream to e.g. reinvent watchdog or service readiness APIs myself. I gave systemd a try and the only result is that now I spend far less time to add my services to OS, and managing OS became far more convenient to my taste. As for KDE, I'm not a big fan of it. Uhm, it has been ok around KDE3 or so, but now it really huge something and plasma is slow, bugged and some plasmoids are just strange. I'm better off with something like LXDE or XFCE. Though if LXDE would push Qt, Qt5 is quite a large monster on its own, so I guess I would have to stick to XFCE even on embedded designs. Qt5 is kinda large, heavy and slow compared to GTK. Makes sense on weak ARM boards.

Uhm, btw, Olimex just showcased us funny use of LXDE and GkrellM on their little cheap ARM boards.

[aht0]

...and do not use it as server, due to lack of filesystems choice, lack of production-quality VMs & containers and awkward package management. And do not use it in embedded, due to poor hardware support and weird approaches all over place. Supercomputers? Has it got GPU compute support on wheels? Uhm, what else I've forgot?

And on side note, comparing ZFS vs EXT4... well, it can be done, but its like comparing heavy truck vs bike. I guess it makes more sense to do ZFS vs Btrfs test run. It can also be interesting idea to give a shot to ZFS on Linux to see how it performs against these two. And as for ext4, I guess it should be rather tested vs UFS (I can guess the results though).

Out of idle curiosity, how many file systems would you need, when existing ones work just fine? UFS2 is rock stable and fairly fast, ZFS is both of it and has ton of features. Both are fully usable in production systems.

Issue in your case appears to be inability to understand differences in development philosophy for BSDs and Linuxes. BSD devs write code methodically and develop their OS as a whole, finalizing their code, writing the documentation, making sure the stuff would work.
Linux: Each distributor does "their" thing, kernel itself is a fairly ungodly mess, rest of the Linux world acts in the way of "before one thing gets completely ready, whole project might get flushed down the toilet and started anew from different angle, abandoned or whatever". Shortly: change for the sake of change.

Let's look at Linux file systems now. For production system I would only dare using Ext4. All other filesystems being offered in "average" Linux distro have some sort of minor or major issues, be it being superseded, stability or real possibility for data corruption. Btfrs - not fully mature, certain conditions may well lead to data corruption. XFS - one power failure and you have new content in files, mostly zeros. Ext2/Ext3 - why use'em when you got Ext4. JFS? has issues with journal writes and is generally slower than Ext4.

VM.. quoting now https://wiki.freebsd.org/Myths

FreeBSD 9 supports running as a Xen guest (domU) on both x86 and x86-64, including Amazon EC2. Thanks to work done jointly by Microsoft, NetApp, and Citrix, it is also possible to run FreeBSD on Microsoft's Hyper-V hypervisor. Many versions of FreeBSD are also on the VMware Supported Guest Operating Systems list.
FreeBSD also supports VirtualBox, as both a host and a guest. You can find the VirtualBox guest additions and then hypervisor itself in the ports collection. FreeBSD 10 also acts as the host operating system for bhyve, the BSD Hypervisor, giving a variety of options for running FreeBSD VMs on top of FreeBSD.
Finally, if you don't require full virtualisation, you can use the jail subsystem to run isolated FreeBSD userlands (or even Linux userlands using the Linux ABI layer) on a single FreeBSD kernel. Jails can even be provided with their own independent network stack etc, and so a single machine can be used to emulate an entire machine room.

Notice, the jails. Usable as f'ck sometimes.

awkward package management. pkg install name-of-the-package is awkward exactly how? Especially considering I could be compiling also some stuff from source and not having it interfering with the rest of the packages. What can't be said for Linux. Compile something from source in Ubuntu, without jumping trough extra loops making the "new" package, etc and you have screwed up package management real fast.

Embedded. FreeBSD ARM is quite well supported. You can also use MIPS as long as you stick to supported CPUs/chipsets. NetBSD should run on literally anything. That's the "special niche" of NetBSD. No clue about OpenBSD,

Define "poor hardware support" more precisely. AFAIK enterprise hardware RAID controllers, network cards etc have good or very good FreeBSD driver support. At least from major manufacturers. For home users, you get into trouble if you have Radeon graphics card from 2xx/3xx series and from older HD8xxx series, and standby/hibernate is and issue for laptops (except some 220 series Thinkpads). Rest of the tech will work. In fact, I'm writing this tirade from laptop running FreeBSD. Hate SystemD and Plasma5.

[RedShift]

The tests that are heavy on disk I/O weren't conducted fair. ZFS was used on the BSD side, for equal comparison, the Ubuntu setup should have used BTRFS (or the BSD side, UFS should've been used).

[TiberiusDuval]

Lack of PKG management? What then does pkgng do, if not package management? And ZFS does everything I'll need from filesystem. (On Linux side I use ext4)

[DeFTeR]

Very much interested in some network as well as DB(MySQL/PostrgreSQL) benchmarks for FreeBSD/NetBSD and CentOS/Debian/Fedora/Ubuntu.

[profoundWHALE]

I would like a few networking benchmarks and possibly a game? Maybe? Back in the day, FreeBSD was faster than Linux at that.

[nasyt]

Phoronix: FreeBSD/PC-BSD 10.2 vs. Ubuntu 15.04/15.10 Benchmarks

It's been a while since last running any BSD vs. Linux benchmarks, so I've started some fresh comparisons using the latest releases of various BSDs and Linux distributions. First up, as for what's completed so far, is using the FreeBSD-based PC-BSD 10.2 compared to Ubuntu 15.04 stable and the latest development release of Ubuntu 15.10.

http://www.phoronix.com/vr.php?view=22232

Whats about BSD's Networking code, is this faster or slower than Linux'? We don't know because it was not measured on this benchmark. In fact, it was never measured.

#TcpipBenchmarksPlease

[nasyt]

You see, I've used containers for somethnig like TEN YEARS. And VMs, too. It made my life considerably easier in some regards... while BSDs do not even have it in production state. Same goes for package management. I do not live forever, so waiting 10 extra years for some tech isn't good for me. Hopefully it explains why I'm not a big fan of BSDs.

I'm not a big fan of BSDs eighter. But I'm also not a fan of Linux. There are many good things out there - all underutilized in favour of Linux of course - that would all give one an distinct advantage in his infrastructure. And the Linux folks are adding good features to make people ignore bad things. Like spraying around fragrance spray in order to conceal the stink.

[SystemCrasher]

Obviously, package management and VMs and containers are more important than everything else.

You see, I've used containers for somethnig like TEN YEARS. And VMs, too. It made my life considerably easier in some regards... while BSDs do not even have it in production state. Same goes for package management. I do not live forever, so waiting 10 extra years for some tech isn't good for me. Hopefully it explains why I'm not a big fan of BSDs.