FreeBSD 10.3 Officially Released With Much Better Linux Binary Compatibility

[phoronix]

Phoronix: FreeBSD 10.3 Officially Released With Much Better Linux Binary Compatibility

FreeBSD 10.3 is now out in stable release form...

http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-10.3-Released

[Xaero_Vincent]

Does this mean Linux Steam will now run on FreeBSD?

[BSDude]

Does this mean Linux Steam will now run on FreeBSD?

Not yet. FreeBSD ships with a CentOS 6.7 userland that has an earlier version of glibc than required by steam.

[mike4]

How stupid...faster than Linux surprises me. When steam etc. works, together with zfs, this surely makes a nice alternative.

[PhilPotter]

Not yet. FreeBSD ships with a CentOS 6.7 userland that has an earlier version of glibc than required by steam.

Forgive me for the naive question, still experimenting with FreeBSD as mainly a Linux guy. Presumably, if the Linux system call interface and related kernel infrastructure in this release is advanced enough, one could replace the CentOS 6.7 userland with (for example) a CentOS 7 userland manually, in a jail or such like? This would contain a newer version of glibc and allow Steam to run potentially. Am I along the right lines here? I don't know how advanced the kernel side of things is with regards to Linux emulation so would be good to know.

[SystemCrasher]

How stupid...faster than Linux surprises me. When steam etc. works, together with zfs, this surely makes a nice alternative.

Actually, Linux proven itselt very nice alternative to BSDs, because BSDs were like 10 years before Torvalds even started coding. They just sucked at hardware support as usually and their corporate lords like AT&T sued them to make it even more fun. So Torvalds had to do hard job himself, eventually outrunning these wothless nuts. Do you honestly think they could catch up? Let 'em try. Or die trying.

P.S. "much better" Linux compatibility hardly scores to 2.6.22 level, with most container related clone() flags still missing, no cgroups, etc. Uhm, I'm even unable to remember when I've been fiddling with 2.6.22 kernels, it has been (unsigned) long long ago.

[aht0]

P.S. "much better" Linux compatibility hardly scores to 2.6.22 level, with most container related clone() flags still missing, no cgroups, etc. Uhm, I'm even unable to remember when I've been fiddling with 2.6.22 kernels, it has been (unsigned) long long ago.

Let us respond...

-Linux does still not have self-contained-installer package format (like windows .msi), you'd have to mess with obnoxious binary packages and dependency issues. Reinstall whole thing if you somehow manage to screw those databases up.. FreeBSD - binary packages, self-contained installers (pbi) and building from source, all without interfering with each other I can install some part of system by binary packages and then build some pieces from ports using custom options. Without jumping into any extra loops.

-Linux utterly sucks from documentation point of view. Up to the point you'd have to read source to get some information about using something more esoteric.

-doesn't need cgroups or other crap that's often enough just meant for patching "specially designed" holes in underlying software layer in Linux.

-Generally you don't care much about the version of linux ABI module. Nvidia driver needs it but it's compatibility has been taken care of by Nvidia. It's not mandatory for anything else..

-FreeBSD: ZFS root, GELI full fs encryption (AES-XTS 256bit), full transparent TRIM, incl queued (which has been problematic on Linux /smirk).

-pf rocks. Iptables with it's limitations is for masochists. Write your iptables rules, you can't understand your own creation 2 weeks later.

-BSDs are complete OS'es. Not bunch of software thrown together around Linux kernel half of it part-working.

[mmaxxza]

with most container related clone() flags still missing,

We've had "containers" since 1999 - aka bsd jails

no cgroups, etc.

Resource limits have been around almost as long.... https://www.freebsd.org/doc/en_US.IS...rcelimits.html

BSDs just like to grow in the right way and not just grow wildly. For example FreeBSD dealt with the smp Giant Lock https://en.wikipedia.org/wiki/Giant_lock in version 5 to 6 (circa 2005) while linux only removed it around 2011.

But hey best tool for the job - linux has its uses as does bsd and windows.

Hows that for catching up?

[SystemCrasher]

We've had "containers" since 1999 - aka bsd jails

Great feature. For 1999. BSD zealots pissed Linux users off a lot without chance of retribution, etc. I can remember it. But its 2016. Jails development virtually halted, OTOH Linux turned into powerhouse. So when it comes to containers and VMs, everyone gone Linux. There were few companies using BSD containers. Needless to say they never bothered to contribute back, like it happens to BSDs all the time. Over time Linux clearly prevailed, surpassing these half-baked implementations.

Resource limits have been around almost as long.... https://www.freebsd.org/doc/en_US.IS...rcelimits.html

There is little issue: these days we want something sensible. Not 1970s style bones and dust.

Imagine I've got some host. Imagine I want to split it to say 5 semi-independent VMs.
- How do I specify container #1 shouldn't consume more than 20% of host's cpu?
- How do I specify container #3 isn't allowed to take more than 30% of HDD bandwidth?
- How do I specify container #2 can't exceed 20Mbit/second of network bandwidth?

That's what we call resource limits and resource management as of 2016. Linux could do it. Maybe not best possible ways, but at least it would work. Somehow I can't spot anything like that in your manual. Not like I need limiting cpu time in seconds, it isn't 70s and mainframes, after all.

BSDs just like to grow in the right way and not just grow wildly. For example FreeBSD dealt with the smp Giant Lock https://en.wikipedia.org/wiki/Giant_lock in version 5 to 6 (circa 2005) while linux only removed it around 2011.

So FreeBSD is good in crap like "booting computers since 1830". Why I'm supposed to care about it? It suxx when I need sensible set of features. Virtually all VMs/VPS hosting and cloud companies gone Linux. Just because it could do what they need and they can't wait forever. It is so nice when there're limits, man tells about quotas, fle size limits, and ... no single word about policing disk bandwidth? What the hell?

But hey best tool for the job - linux has its uses as does bsd and windows.

I can't imagine where BSDs would be best. Except maybe acting like BDSM slaves of most evil proprietary companies around. Windows? Speaking for myself, I would let BSD users to enjoy by spyware, backdoors and draconian EULAs. Use such tools yourself. Well, I could be enterprise AD admin, but it is most useless skill I've got for sure. I'm better off with tools supplied on better terms, giving me more freedom. Sure, BSD users aren't picky in choosing friends. Known issue. Since 1992, AT&T vs BSDi.

Hows that for catching up?

Simple. BSDs appeared like 10 years before Linux did. And pioneered in doing some things like jails, sure. Then Linux has appeared, gained steam and pwned BSDs to the dust, outrunning BSDs in their own fields of expertise. It seems there were quite some valid reasons it happens this way.

[aht0]

Great feature. For 1999. BSD zealots pissed Linux users off a lot without chance of retribution, etc. I can remember it. But its 2016. Jails development virtually halted, OTOH Linux turned into powerhouse. So when it comes to containers and VMs, everyone gone Linux. There were few companies using BSD containers. Needless to say they never bothered to contribute back, like it happens to BSDs all the time. Over time Linux clearly prevailed, surpassing these half-baked implementations.

If anything is 'half-baked' then by definition and it's nature, it's Linux. For some reason there have never been any need for Enterprise xBSD. Just vanilla OS has had sufficed.

There is little issue: these days we want something sensible. Not 1970s style bones and dust.

if it's not broke, don't fix it.

Imagine I've got some host. Imagine I want to split it to say 5 semi-independent VMs.
- How do I specify container #1 shouldn't consume more than 20% of host's cpu?
- How do I specify container #3 isn't allowed to take more than 30% of HDD bandwidth?
- How do I specify container #2 can't exceed 20Mbit/second of network bandwidth?

That's what we call resource limits and resource management as of 2016. Linux could do it. Maybe not best possible ways, but at least it would work. Somehow I can't spot anything like that in your manual. Not like I need limiting cpu time in seconds, it isn't 70s and mainframes, after all.

- rctl -a jail:jailno1cpu:deny=20
- Measure disk IO then use rctl for setting the limits. Let's assume 300MB/s for example rctl -a jail:jailid2:ior:deny=100M and rctl -a jail:jailid2:iow:deny=100M
First for throttling the reads, latter for throttling the writes.
-Using functionality of pf on host would be easiest. Could regulate traffic throughput from one jail to another or from jail to World or to another host. Separately.

So FreeBSD is good in crap like "booting computers since 1830". Why I'm supposed to care about it? It suxx when I need sensible set of features. Virtually all VMs/VPS hosting and cloud companies gone Linux. Just because it could do what they need and they can't wait forever. It is so nice when there're limits, man tells about quotas, fle size limits, and ... no single word about policing disk bandwidth? What the hell?

cut the bs. Result of the companies behind Linux advertising it.

I can't imagine where BSDs would be best. Except maybe acting like BDSM slaves of most evil proprietary companies around. Windows? Speaking for myself, I would let BSD users to enjoy by spyware, backdoors and draconian EULAs. Use such tools yourself. Well, I could be enterprise AD admin, but it is most useless skill I've got for sure. I'm better off with tools supplied on better terms, giving me more freedom. Sure, BSD users aren't picky in choosing friends. Known issue. Since 1992, AT&T vs BSDi.

Firewalling, routing, desktops. And stop complaining about you cheap-a$$ GCN radeon "not lighting up". Buy Nvidia hardware (which is generally more power efficient and better-performing) and it's going to work.