Slashdot Mirror
FreeBSD 10.0 Released
An anonymous reader writes "FreeBSD 10.0 has been released. A few highlights include: pkg is now the default package management utility. Major enhancements in virtualization, including the addition of bhyve, virtio, and native paravirtualized drivers providing support for FreeBSD as a guest operating system on Microsoft Hyper-V. Support for the high-performance LZ4 compression algorithm has been added to ZFS and TRIM support for SSD has been added to ZFS. clang is the default compiler. This release has official Raspberry Pi support. For a complete list of new features and known problems, please see the online release notes and a quick FreeBSD installation video is here. FreeBSD 10.0-RELEASE may be downloaded via ftp or via a torrent client that supports web seeding."
It is really nice that the recent Linux distros have them.
It is a pain in the butt on FreeBSD to manually switch compilers and hack /etc files and then do a manual compile to get them to work in VMWare workstation 10 in comparison.
http://saveie6.com/
Good to hear. I'm sure I'm not the only one who really likes the BSDs in general. After almost 20 years in the IT biz, I would still choose FreeBSD or OpenBSD for my server needs for almost anything over almost anything. I've never been disappointed in the service of either BSD variant. Kudos to the FreeBSD devs!
It would be nice if FreeBSD had a Xen-like tier 1 hypervisor. Running as a client is one thing. Running as something with ZFS underneath would be very useful as an alternative to QEMU or Bochs.
pkg is NOT the default package management
"pkgng is the next generation replacement for the traditional FreeBSD package management tools, offering many features that make dealing with binary packages faster and easier.
pkgng is not a replacement for port management tools like ports-mgmt/portmaster or ports-mgmt/portupgrade. "
bhyve is technically a type 2, but it makes use of the HW acceled instructions that Type 1s normally use. bhyve is more a of a hybrid between 1 and 2, with more of a bias towards 2. Because of this, it is not very friendly with many Type 2 guests because it lacks legacy support and it's not a true Type 1, so it still needs proper interfaces, but it is faster, lighter weight, and uses about 10x fewer lines of code than most, so it is easy to debug and prove security.
I've been using 10.0-PRELEASE for most things here for a while and it works well... Watch the package system change though if you're upgrading a really old system and used to just using things like portupgrade, I'm still trying to get one of my old 8.something boxes ports all updated properly, though that's probably mostly my fault for being sloppy and not reading ports/UPDATING carefully enough :) The 10.0 kernel and userland themselves are working perfectly and it was a pain free transition all the way from 8 on that box.
With the recent OpenBSD news many people claim OpenBSD has much cleaner code and can be kept more secure as a result. Is this just FUD or is there some evidence that FreeBSD accepts horrible performance patches and so on?
They're different projects with different emphasis. I think it's just a "us and them" type thing.
PS: I don't reply to ACs.
I agree...FreeBSD seems like a great Xen host.
PS: I don't reply to ACs.
OpenBSD does have cleaner code because they continually audit their code. It's the only way. OpenBSD also does not allow binary blobs, which in today's world would be the height if stupidity because you cannot validate what is in them, view their source, to whom they may communicate with unbeknownst to you. Clean, open source viewable code is a must to establish and maintain trust. Binary blobs and the recent Linux model of cooperating with the MS secure boot initiative scares the crap out of many, including myself. I will likely be buying the same machines that RMS uses from this point forward.
Is there any real difference between a Type 1 hypervisor and a Type 2 where you never run anything? If you took FreeBSD and ripped out everything but the minimum binaries and scripts needed to boot and run bhyve instances, how would that be different from a Type 1 hypervisor?
Exactly. Versus a properly configured host, It's a "difference" drummed up out of thin air so they can sell you "security".
brandelf -t FreeBSD
I'll wait for the x.1 release
Which is fine. Avoiding a rush to implement a .0 release for anything critical is sound advice, regardless of vendor or closed/open source. But if nobody runs it, you do not uncover bugs and you never get a .1 release.
FreeBSD's goal is to create a solid Unix based general server OS. And it's around a lot in the storage markets and routing markets, it's just not usually called FreeBSD. I know more than a few Solaris shops that have been converting over to FreeBSD after the Oracle purchase because FreeBSD had DTrace and ZFS support that Linux didn't have at the time.
OpenBSD's goal is security above all else.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
According to wiki: Kernel-based Virtual Machine (KVM) and bhyve are implemented as a kernel modules for Linux and FreeBSD respectively which, when loaded, allows its host operating system to act as a bare metal (i.e., Type 1) hypervisor
So the only difference is the kernel is not just a hypervisor, but also an OS. If you don't make use of the OS part, it works like a normal Type 1 hypervisor.
Yeah, we're talking the NIMFY effect: not in my front yard.
Really, with the .0 releases, if you try to stay fairly mainstream in your deployment, and you're mindfull about the necessary mitigations if it doesn't go well, the risk is not outrageous. But first test your backups.
If I had to choose between 10.0 (which I hardly know) and 5.3 (all too well known) I'd pick 10.0 in a heartbeat. That series should have started out at 5.-5 (five dot negative five).
The .0 thing is just a loose heuristic.
Before anyone considers upgrading or installing FreeBSD 10.0-RELEASE, it is recommended you first read the Errata (particularly the Open Issues section):
http://www.freebsd.org/releases/10.0R/errata.html
Some of these might come as a shock to readers, especially the killall argv parsing bug and the ipfw fwd link-layer bug.
other projects just increment numbers without any radical changes. OpenBSD for example just slowly increments by 0.1
...that's the one that's a bit like Linnux but not quite, right?
systemd is Roko's Basilisk.
The major release numbers in FreeBSD mean breaks in binary compatibility. Any binary, including kernel modules, that runs on FreeBSD x.y is expected to run on FreeBSD x.(y+1). Userspace binaries should also work on (x+1).z, but may require compatibility packages to be installed (for userspace libraries that had ABI changes or were removed) and may require the kernel to be built with compatibility options enabled. This is the default for the GENERIC kernel, but some embedded builds disable them, and for some architectures there's no point in enabling them if FreeBSD didn't run on that architecture at the time.
I am TheRaven on Soylent News
The distinction between Type 1 and Type 2 hypervisors doesn't really make sense anymore, and is largely marketing. For example, Xen running on a system with no IOMMU is still a Type 1 hypervisor, but the whole of the dom0 kernel and a chunk of its userspace are in the trusted computing base (TCB), where a compromise can extend to every other domain. In the case of Linux's KVM and bhyve, the host kernel (and anything that can poke kernel memory, or exploit kernel vulnerabilities) are in the TCB.
The distinction makes more sense for certain ARM, SPARC, and PowerPC hypervisors, where the hardware handles most of the virtualisation (devices all support multiple isolated command queues and run behind an IOMMU), so a small Type 1 hypervisor can be a few tens of thousands of lines of code and that's the entire shared TCB. Guests run their own device drivers, the hypervisor just handles the control plane.
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
I am TheRaven on Soylent News
Some guys at Spectra Logic and Citrix have been pushing Xen PVH support into FreeBSD recently. It didn't make it for 10.0, but hopefully should be in 10.1. In PVH mode, a guest boots as if it is a PV guest, with Xen's entry point and event channels instead of interrupts, but then uses the hardware page tables and either PCI pass-through devices or PV devices. This is important, because PVH guests can also run as dom0, if they implement the management interfaces (which are mostly userspace and shared across platforms). Getting PVH working in domU is much more effort than going from a working domU PVH to a working dom0 PVH.
That said, with bhyve and the new vps work (shared kernel like jails, but with some nifty features like live migration between hosts), there's a lot less of a reason for me to care about Xen, in relation to FreeBSD.
I am TheRaven on Soylent News
http://www.gnu.org/distros/common-distros.html#BSD
FreeBSD is free according to the definition used by the FreeBSD developers. Firmware is not loaded into the kernel so it's not concidered to be a concern, and the FreeBSD developers have no interest in saying what programs users should or should not use.
My primary attraction is the strengthened random number generation for cryptography. This eliminates the NSA introduced weaknesses in the underlying hardware.
That alone is enough to turn me into a rapid FreeBSD supporter.
TCAP-Abort
The important distinction is between hypervisors that do software partitioning of devices (either via emulation or paravirtualised devices), and ones that don't. Xen, KVM, and byhve all fall into the former category and so have a TCB that's several MBs of object code.
It is interesting to note that KVM is over 12mil lines of code and XEN is about 515k LOC, while byhve is only 1,300.. yes.. 1 thousand three hundred. byhve also compiles to just under 500KB. XEN is around 1MB, but I can't find info on KVM.
You've given me an interesting thought - if time permits I might try it to see what happens.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
I think your numbers for KVM are for the entire kernel, not just the VM support, but your bhyve numbers are for the bhyve kernel module, which depends on a lot of other stuff in the kernel (the VM subsystem, device drivers, at least one out of the network and storage stacks). The Xen number includes, I think, includes just the hypervisor, not the domain 0 guest that is responsible for running the control plain, providing all of the emulated devices, and so on.
I am TheRaven on Soylent News
The whole debate about what is actually 'free' software is hilarious and comes down to miniscule differences in dogma. It's pathetic.
OpenBSD's goal is security above all else.
This phrasing implies that FreeBSD doesn't care about security, which is somewhat misleading. Take a look at the number of papers at Oakland that use FreeBSD as a base and the number of those that we've accepted into the base system sometime.
For example, FreeBSD has a modular mandatory access control framework with pluggable policies. This is used by some downstream projects for things like the OS X / iOS sandboxing subsystem and the JunOS code signing infrastructure. It's also used for the type enforcement mechanism in FreeBSD and a few other things.
FreeBSD has had jails for a long time, which are an easy way of creating a completely isolated environment (distinct root user, filesystem hierarchy, and so on), sharing the same kernel (so much cheaper than a VM). With ZFS and cheap clones, it's easy to keep a stock FreeBSD install around, clone it, and have a new jail up and running in a few seconds. Poudriere (French for Powderkeg), the package building program uses this mechanism to create a pristine environment for building each package, allowing untrusted intermediate binaries to be run on the build server without giving them any access to the host environment.
In FreeBSD 10, Capsicum is enabled by default in the kernel, and a number of base system utilities are sandboxed out of the box. Capsicum sandboxing means that things run without the ability to create file descriptors and have to request a more-privileged daemon pass them the ones that they need. For example, tcpdump (which doesn't have the best security record in the world and is often used to inspect malicious network traffic) runs in compartmentalised mode and just delegates DNS lookups to a daemon that runs outside of the sandbox. The daemon only accepts records in fixed formats (IP addresses) and returns a string, so it has a very small attack surface.
FreeBSD supports both POSIX and NFSv4 ACLs, for people who want finer-grained filesystem security. With 10 (and, I think, 9.2?), the audit log daemon is complemented by auditdistd, which allows you to distribute cryptographically signed audit logs across machines, allowing you to detect suspicious activity.
The binary packages that we're distributing are signed, by a key that is distributed via a different mechanism to the packages, and the pkg audit command allows you to display known vulnerabilities in any of your installed third-party packages.
I am TheRaven on Soylent News
Capsicum, POSIX and NFS4 ACLs are all about adding complexity to allow for greater administrative policy enforcement. To put the OpenBSD point of view into perspective with a modern example, this is exactly the kind of policy that makes NSA admins rest easy at night and exactly the kind of security that allows Edward Snowden to secretly make out with 200,000 top secret documents. Real security means the software *does*what*it*promises* which a large and complex administrative policy enforcement system can almost never do.
In OpenBSD, security means that you eliminate bugs so that the most basic promise is held true. Adding complexity almost always does the opposite. We are talking about two completely different ideas of "security" here. This is not to say that ACL systems have no place, but rather, the systems that are smaller, easier to audit and easier to implement are going to find a place in OpenBSD long before the large and unwieldy systems could ever be incorporated.
That being said, FreeBSD 10 was the first FreeBSD system to distribute signed packages. OpenBSD 5.5 will be the first version of OpenBSD that distributes a signed base, signed firmware and signed packages. The code is small, the benefit is clear, and the implementation (at least in OpenBSD) is obvious.
OpenBSD also has a lot less functionality.
It's a trade-off - you decide what your requirements are and you make your choice.
For me, FreeBSD is "good enough" in terms of security (track record is pretty good), and has functionality that I require on some machines, that OpenBSD does not. Your mileage may vary. For me, shared knowledge across all my *NIX systems is a big plus, so I've standardized on FreeBSD unless there are vendor support requirements that dictate Linux.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
For the vast majority of FreeBSD installations, USB3 is entirely irrelevant.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
So RMS writes his own hard drive firmware, yeah?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
OpenBSD turns on a number of security features by default that FreeBSD avoids for really early backward binary compatibility (or just plain laziness). The newest feature in OpenBSD 5.5 is PIE-by-default executables on major platforms. Even Microsoft Windows implements more than FreeBSD! See Theo deRaadt's talk slides http://tech.yandex.com/events/ruBSD/2013/talks/103 for some more examples.
OpenBSD has usability as a very high goal. I'd say it's more usable out of the box than FreeBSD, but that depends on what makes it usable for you...
Capsicum, POSIX and NFS4 ACLs are all about adding complexity to allow for greater administrative policy enforcement
This is almost true for ACLs. ACLs are no more expressive than standard UNIX permissions, but they are significantly simpler for implementing the same thing - you no longer need to create a group for every set of people who want to share things. This lets you leave your default at share-nothing, and explicitly share the things that you need to share with the people that you need to share it with. The code for implementing them is significantly less complex than the work arounds that you need for their absence if you want the same level of access control, and if you don't want the same level of access control it's because you're fine with leaving things more widely readable than they need to be. Neither of these attitudes is good for security.
Capsicum is definitely not about adding complexity. The implementation adds an extra bitmask check on file accesses and restricts system calls to a whitelisted set. The total code changes in the kernel are very small and easy to audit (and have been audited by several groups). The code changes in userspace code are far more significant. The sandboxing in Chromium, for example, is six times more lines of code on OpenBSD using chroot() than it is on FreeBSD using Capsicum, and offers less isolation (for example, the renderer processes on OpenBSD can create network sockets, so an image in an email that exploits libpng or libjpeg vulnerabilities can phone home and send copies of all of your emails if you use webmail from OpenBSD, with Capsicum is can't). The privilege separation code in OpenSSH is also cleaner and easier to audit when it uses Capsicum.
In OpenBSD, security means that you eliminate bugs so that the most basic promise is held true.
In FreeBSD, we care about mitigation. Useful software is never bug free, no matter how simple you make it. The goal is to ensure that once an attacker finds a bug, they can't use it to exploit the system. That doesn't mean 'they can't get root', because on a huge number of modern systems, from single-user laptops to single-service VMs, getting ambient authority for a single user can mean the same as getting root, when it comes to having access to the data that the user cares about. Jails, Capsicum, and so on are all about enforcing the principle of least privilege, so when a bug is discovered the attacker only gets control of a sandbox with no access to the rest of the user's data. This used to be something that OpenBSD people cared about.
I am TheRaven on Soylent News
Binary firmware blobs, OpenBSD allows. You would run them anyways on your hardware, no matter what software you choose.
Binary kernel blobs, OpenBSD eschews. Example - While FreeBSD is basically happy to suck the dick of Nvidia, running proven crap, OpenBSD will wait for a Nouveau port coming in perhaps the near future.
Since FreeBSD is one of the top distributions, even appearing on Linux-centric sites as mentionable: http://distrowatch.com/dwres.p...
BSD is free by any rational definition.
The differences do have significance. The differences can be usefully and rationally discussed back and forth. What impresses me is that one side in the divide gets off on dissing the other, but it's not reciprocal.
--That's not the point. USB3 is now becoming common hardware, and needs to be supported as such. God, I hate elitist answers like the one you just gave. " YOU'RE doing it wrong... " No!! It's 2014 FFS, Freebsd has several years of catching up just to get close to where Linux is NOW.
--Ten minutes of experimenting with the latest Freebsd10--64 DVD install ISO and Vmware Player revealed several obvious bugs in the installer. I had to trash the VMDK entirely and start over after the install bombed because it was hopelessly stuck - even after a reboot, because it DIDN'T destroy all existing data on the (aborted install) ZFS root disk like it should. Increasing the VM RAM from 1GB to 1.5GB finally got a successful basic install, but DAMN they need to do some more basic testing before releasing this stuff to the general public. PCBSD has the same (lack of testing) problem.
--Even after the install completed and switching to the new ' pkg ' system, I can't even get Xorg to install**. Still craptastic 80x25 text consoles, and the Delete key STILL doesn't even work as expected at the command prompt. They don't even install BASH by default yet. This is *pathetic.*
** What, you want me to *compile* Xorg on a 4GB RAM laptop in a VM? Sod off. And yes, I was following the official handbook.
--Don't even get me started on the lack of decent /dev/disk entries, Linux kernel has /dev/disk/by-id that is making ZFS on *Linux* way more appealing these days. And this is coming from someone who had my main RAID server running PCBSD 9.0--64 + ZFS RAIDZ3 + Samba for a year and a half with an unrecoverably broken ports tree(due to an unavoidably ^C'ed compile), until I finally converted it to ZFS on Linux a couple of weeks ago. Package manglement was a nightmare compared to apt-get. I even tried giving Kfreebsd the benefit of the doubt for a couple of years, but that distro is a long way from even being home-user ready. Nobody is going to take them seriously until they can at least have a viable install in Vmware with everything working out of the box as expected.
--I really want to be a fan of Free/PCBSD, but they arguably have a long way to go before they can even begin to match the current Linux comfort level. Srsly.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
p.s. - more on Freebsd's /dev/disk.
--Look it up**, the *recommended* way to discover disks in Freebsd is to grep 'dmesg' for da* and ad* entries. There are multiple different ways to do this simple thing in Linux, which also provides more information as a bonus:
o ' fdisk -l ', /dev/disk/by-id|grep sdX '.
o ' blkid ', even
o ' ls -al
** Google " freebsd list disks ". Srsly, the mind boggles.
--Truly this is a sorry state of affairs, and nobody seems interested in making it better on the Freebsd side. This is making it difficult to have a sane naming scheme if you want to have a fairly large ZFS installation, since disk entries can change after a reboot. Even adopting Solaris' c1t1d1 method would be a start.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
The way God *intended* version numbers to work! ;) None of this always-a-major-version Chrome/Firefox nonsense.
I liked the old base Linux versioning scheme too, but they killed that as well. Sigh.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
They don't even install BASH by default yet.
Ouch. What is there instead, dash?
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
The idea of "forced freedom" is a bit funny if you think about it, yeah, but we live in a (justly) cynical world.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Let me know when a BSD gets opencl and cuda support. That's the main thing keeping me from using it in more than just a VirtualBox machine.
Ops, I shuld have usd the prevuwe but in.
Being able to use ZFS on Raspberry PI, even running on USB disk and low performance, would be really nice for mediacenters and backup NAS. Anybody has experience with that, I guess 512MB is not enough for it...
I don't care a lot about performance in this context, but stability.
Opinions?
csh. (shudderz)
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
Oh God.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Being able to use ZFS on Raspberry PI, even running on USB disk and low performance, would be really nice for mediacenters and backup NAS. Anybody has experience with that, I guess 512MB is not enough for it...
I don't care a lot about performance in this context, but stability.
Any opinion or experience?
Does FreeBSD/PC-BSD have anything like a QEMU/KVM?
PC-BSD is the FreeBSD distro targeted at desktops & laptops. FreeBSD itself is targeted at servers. I'm not sure whether any FreeBSD distro is targeted at embeddeds
They are Free even by the FSF definitions. What they are not is that they are not CopyLeft. That is a different beast
If the firmware can be moved from Flash to ROM, RMS will redefine it as 'hardware' and then it won't have to fall under the definition of 'free'. Or 'libre', as they prefer saying in non-English
I never said "you're doing it wrong". Just that for the 99% use case of FreeBSD, USB3 is entirely irrelevant, hence effort is put into things that are MORE relevant. Thus, "wake me up when it supports USB3" or whatever is just being a dick for the sake of it.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Other points... Xorg is available as a package (no you do not need to compile), VMware does not yet support FreeBSD 10, ZFS is NOT recommended for use in a virtual environment.
If you're setting up a desktop, you're better off with PC-BSD anyway.
On the contrary, I just (last night in fact) installed PC-BSD 10 pre-release (2014-01-25 nightly build) on bare metal on my Core i5-4430 with GT760 NVidia card and everything was detected and worked out of the box. It was essentially the same experience I had with Ubuntu 13.10, except I got root on ZFS out of the box.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Bash = GNU, and therefore not in the default install. it is available as a package, just like it is on Linux (the Linux package just happens to be installed by default).
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Yup, gpart list. Maybe the documentation needs updating.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
And yes, looks like the parent poster has a heap of gripes about FreeBSD because it doesn't work the Linux way. ZFS with gpart is entirely usable, and no you don't need to grep through dmesg. However, expecting FreeBSD to work like Linux, or Linux to work like FreeBSD will just end in tears. They are not the same and never will be.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Oh and by the way. USB3 is supported in FreeBSD 10 anyway, just checked my box's dmesg. I hadn't noticed because I don't have any USB3 peripherals.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
--I appreciate your responses. Just saying that there are a lot of good things that Linux is doing (and has done for years) that Freebsd would do well to incorporate. God knows how many people get to know Linux, then want to try Freebsd (like I did) for $featureset and end up getting frustrated because it seems way primitive in comparison. PCBSD gets this to a certain extent, but they still suffer from lack of testing and compatibility with various system chipsets. I get on the forums and let them know, but the last bug I posted there has been no response.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
Yeah, comparing a typical Linux distro to FreeBSD is a little bit "unfair" for lack of a better word, unless the distro is LFS or Gentoo stage 2 (? its been a while).
If you're going to compare Fedora, Ubuntu, Mint, etc. the better comparison is PC-BSD as they are aimed at similar users.
Whilst Linux has a bunch of interesting work, so does the FreeBSD code-base - capsicum, dtrace, zfs, grand central, clang, beadm, etc. Also, for a light-weight multi-platform box, FreeNAS 9.1 plus jails = awesome. Point and click jail generation = far lighter weight than virtualization and most of the benefit - and your entire jail is able to be snapshotted/rolled back/etc. with ZFS.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. Capsicum can be used for application and library compartmentalisation, the decomposition of larger bodies of software into isolated (sandboxed) components in order to implement security policies and limit the impact of software vulnerabilities.
That there's a BSD system component named after the primary component of a pepper that causes pain (okay, capsaicin, but whatever) makes me laugh, and wonder whether the name is as apropos as it sounds.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF