from the bazaar?-what-bazaar?-this-is-my-cathedral dept.
In the release notes for RedHat Enterprise Linux 7.4 we can see the following:
The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.
Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use. We encourage feedback through your Red Hat representative on features and requirements you have for file systems and storage technology.
Btrfs, originally developed by Oracle and now also by SUSE and others, seems to have lost Red Hat as supporter. So what is ahead? RH isn't very clear. ZFS had license issues since day one, and is currently under Oracle umbrella, making a change near impossible. Does this mean improving XFS? Some other FS to be announce soon? Will Red Hat push its weight around like in other cases? Will other distros hold their ground or bow? Unix wars all over again, this time in Linux and FOSS land.
Maybe time to update it to Corporate Open Source Software, COSS, you can look but forget about having a voice among the big guys. The bazaar is dead, long live the cathedral. Or time to fork them off.
(Score: 2) by Gaaark on Wednesday August 02 2017, @03:53PM
Be nice if they bought oracle and changed the license!
Nice
CDreams--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by bart9h on Wednesday August 02 2017, @04:03PM (37 children)
What are the disadvantages of Btrfs?
I started using it some time ago, and had no problems so far.
The snapshot feature is very handy.
(Score: 4, Interesting) by tekk on Wednesday August 02 2017, @04:20PM (14 children)
I think the problem is that in the approximately forever that it's been supported and even encouraged in distros like Fedora, it never quite got as fast or as stable as XFS, EXT4, or even ZFS.
It had nice features, but it never got to feature parity with ZFS despite (I think) BTRFS being in development longer. A quick glance at Wikipedia says yes: ZFS went from concept to inclusion in Solaris with a stable on-disk format in 5 years, BTRFS took 7 years for an on-disk format which didn't do everything ZFS did.
If I were cynical I might say that Oracle intentionally hamstrung BTRFS development to just be a token of "see, we support modern, advanced filesystems too" with no real intention to seriously support it. We'll see how Unbreakable Linux handles things when upstream drops btr.
(Score: 4, Informative) by KiloByte on Wednesday August 02 2017, @05:04PM (7 children)
I've got burned by ext4 several times in a row recently, there's no way I'm using a silentdatalossfs anytime soon.
On one hand, btrfs has crap fsync performance, and has some caveats (like the need to balance in some cases).
On the other, old-style filesystems fail to detect any data corruption the disk did not report. On ext4 or xfs, bad data will overwrite backups, and if you have tiered backups with adequate history, there's still no clue when a piece of data went bad. Btrfs on the other hand will tell you immediately on read, or on scrub for cold data (you do run scrub from a weekly cronjob, don't you?).
Another massive advantages of btrfs are local snapshots (so you can rollback with a single command, test upgrades, etc), and O(changes) backups. On spinning rust, when a single rsync run takes north of 30 mins just to stat everything, you can't run backups frequently enough. On btrfs? Do you want them every 3 hours? An hour?
Thus, your choice is between ridiculously non-KISS btrfs that provides data safety features and "stable" filesystems that don't.
Ceterum censeo systemd esse delendam.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 02 2017, @06:01PM (1 child)
But ext2 could handle checksum metadata via its attribute/metadata format, although it AFAIK currently doesn't.
Personally I have lost multiple partitions due to ext4 and seagate drives, in situations that ext2 or 3 on the same drive wouldn't cause any corruption at all. As a result of this I've been sticking to kernels with the old ext3 driver included rather than updating and getting the new 'ext4' features.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @09:31PM
Maybe it was this paper http://pages.cs.wisc.edu/~remzi/Classes/736/Spring2005/Projects/Brian-Chloe/ext2c.pdf [wisc.edu] the one you remember about ext2 and data checksums.
(Score: 4, Informative) by frojack on Wednesday August 02 2017, @06:55PM (1 child)
On the other hand, I find ext4 quite stable. I've never lost a byte. If you have, it was due to bad drives or bad power, which no file system can get around.
The only FS I have ever lost data on was BTRFS, on perfectly functioning drives with battery backed up power. Twice in 6 months, the second event was un-recoverable (required restore from backups after reformatting the drives).
After the second failure btrfs has been on my ban list, which means its on a five year timeout. Maybe if other distros are walking away I won't bother to re-evaluate.
It held out promises, with snapshots and roll backs and all sorts of volume management things. It was starting to become the systemd of file systems, (that is an insult to systemd, which is far more stable). You never knew just how much available space you actually had on a btrfs machine, it took a great deal of digging and calculating.
In short, I could never figure out what market this was aimed at. It has almost nothing Joe Hacker needs, and nothing Small Business could trust. And Big Business has a lot more reliable systems to choose from.
No, you are mistaken. I've always had this sig.
(Score: 2) by KiloByte on Wednesday August 02 2017, @09:16PM
But if I lose data to a bad drive (and there's no such thing as a "good" drive in the long run), I do want to know when and what I lost. With btrfs, I take it from nightly backup (single or raid0) or the filesystem itself takes it from the other copy automatically (redundant¹ raid). With ext4, I have no clue, and the loss is likely to cause actual damage rather than at most a short downtime.
And ext4 is on mine. Despite years of heavy use of btrfs, I have yet to lose data to it (hardware failures and test systems with intentional mucking around obviously excluded). I'm no btrfs dev yet I try to help them — you can come too if you wish.
WHAT THE FUCKING FUCK?!? Now this was uncalled for. Not even fat is that bad!!!
inode limit on ext{2,3,4} anyone?
[¹]. Yeah, "redundant raid" sounds redundant, but someone had the bright idea of naming raid0 thusly.
Ceterum censeo systemd esse delendam.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @09:21PM (2 children)
you two are "on the cheese". ext4 doesn't lose data for shit.
(Score: 2) by Immerman on Thursday August 03 2017, @03:32PM (1 child)
Cosmic ray hits drive, flips a bit, data is lost (a real issue, especially on airplanes). Lot's of more pedestrian ways a bit can get flipped as well.
How long does it take you to notice?
The problem is not the data loss itself - that's completely unavoidable regardless of file system. The problem is if the filesystem doesn't detect and/or repair that damage. And very few of them do.
(Score: 0) by Anonymous Coward on Thursday August 03 2017, @05:40PM
If it's a bit flip like that, the disk will detect and correct it when you read the sector. It take multiple errors for it to be uncorrectable
(Score: 2) by TheRaven on Wednesday August 02 2017, @06:58PM (1 child)
Not even slightly. Btrfs design started in 2007, and was first shipped in 2009, ZFS shipped in 2005. Many people were using ZFS in production when Btrfs was still a design doc and some proof of concept code. ZFS was ported to FreeBSD in 2007 and shipped in FreeBSD 7.0 and was pretty stable in FreeBSD 8 (2010). ZFS was ported to Linux as a proof-of-concept in 2008 and vaguely usable in 2011.
Btrfs was originally started by Oracle because they couldn't use ZFS with Linux because of the GPL and they wanted something equivalent. When Oracle bought Sun, they largely stopped caring about Btrfs. RedHat picked up some of the developers, but it never got the amount of testing required for a production filesystem.
sudo mod me up
(Score: 2) by tekk on Thursday August 03 2017, @03:30AM
Sorry, that's not what I meant by in development longer. I mean that ZFS was shipping, as I understand it more or less as ZFS is today, 4 years after its inception (2001). It took btrfs 7 years just to decide what its on-disk format should be permanently with zfs to draw inspiration from.
(Score: 2) by driverless on Thursday August 03 2017, @10:29AM (3 children)
The problem with ZFS is that it's designed for big iron, don't even think about running that on anything less than serious server-grade hardware. With BTRFS gone that leaves ext2^H3^H4, which is sort of the FAT32 of Unix filesystems, it's the hacked-over fallback system that you use if nothing better is available, with its main selling feature being that at least it's not FAT16.
Maybe it's time to revive murdersYourWifeFS?
(Score: 2) by TheRaven on Thursday August 03 2017, @10:41AM (2 children)
sudo mod me up
(Score: 2) by driverless on Thursday August 03 2017, @10:58AM (1 child)
My Raspberry Pi, my mom's Core i3 desktop, and my niece's school laptop are all very happy for your 16GB laptop with 2TB of SSD that can run ZFS.
(Score: 2) by TheRaven on Thursday August 03 2017, @03:03PM
sudo mod me up
(Score: 4, Insightful) by loic on Wednesday August 02 2017, @04:23PM (11 children)
The raid code is known to be flaky (https://btrfs.wiki.kernel.org/index.php/RAID56 [kernel.org]). I heard about compression issues too, though I had only minor issues with it (zlib CPU usage on old hardware, lzo did the trick). I read other complains about snapshot performance issues, though I have not noticed over 2 years (on small servers and around 80 snapshots, though). BTRFS is known to be factually slower when writing and reading compared to xfs and ext4.
So in a nutshell, if you use your average mdadm powered raid and have moderate performance requirements, you probably will not notice a thing.
But the real story is that Red Hat is pushing its own premium products:
- http://permabit.com/products-overview/albireo-virtual-data-optimizer-vdo/ [permabit.com]
- and https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology [redhat.com]
(Score: 3, Interesting) by KiloByte on Wednesday August 02 2017, @04:53PM
RAID5/6 has never been declared stable. Unlike mirror RAID, parity RAID is in the "here be dragons" land, together with qgroups, and if you use them despite the warnings, kiss your data goodbye.
The only problem here is that the warnings are nowhere big enough. Sadly, my patch to make them appropriate [spinics.net] hasn't been taken. I've put a slightly less in-the-face warning into Debian 4.9 kernels, though.
4.12 has a bunch of drastic improvements here, and RAID5/6 data (ie, -draid5 -mraid1) should be good enough for adventurous users on non-production machines, on 64-bit machines only. Unlike MD, btrfs can have a different level for data and metadata, and a write hole issue results with a single corrupted file (data) or likely total filesystem loss (metadata) -- but with metadata usually taking around 2% space, no one cares you get only 1/2 capacity (raid1) instead of 2/3 (raid5) for it.
Ceterum censeo systemd esse delendam.
(Score: 5, Interesting) by sjames on Wednesday August 02 2017, @05:29PM (9 children)
It's not really surprising that BTRFS isn't as fast as XFS (SGI's filesystem back in the '90s when file I/O was barely fast enough for video) or even ext4 since neither have to do COW to support an advanced feature set.
ZFS and BTRFS are the most interesting next filesystems on offer. ZFS disqualifies itself by not having a compatible license and so requires a number of workarounds. While that may be OK for some users who want ZFS on a data volume, it simply won't do as a default root filesystem.
That leaves BTRFS. It actually works quite well as long as you avoid raid5/6. In some ways it is actually superior to ZFS. For example, it's handling of raid1. While ZFS really wants devices kept in pairs, BTRFS doesn't care about that, it just makes sure there are 2 copies of everything and they are on different devices. Add or remove devices as necessary. BTRFS doesn't insist on snapshots being special things that aren't cloned filesystems. ZFS can have better performance, but only if you throw a metric assload of memory at it.
Really, I think it's time to declare RH to be not actually Linux and leave them to disappear up their own backsides. They can take systemd and freedesktop with them.
(Score: 2) by kaszz on Wednesday August 02 2017, @06:13PM
I think you are on to something..
Always experienced them as something odd in practical interactions. Linux way, BSD way... and the RedHat not anything else way.
(Score: 1, Flamebait) by Grishnakh on Wednesday August 02 2017, @07:03PM (3 children)
Really, I think it's time to declare RH to be not actually Linux and leave them to disappear up their own backsides. They can take systemd and freedesktop with them.
If you're going to do that, then we need a good replacement for systemd (and no, the old sysvinit isn't a good replacement), just like a Chevy Corvair (after the fix) is not a good replacement for any modern vehicle).
However, if you can get Red Hat to keep Gnome3 to themselves, I'm in hearty agreement.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @07:54PM (1 child)
They're are many alternative init systems. Many /most of the good ones also handle process management... If you think the choice is systemd or medieval bs, you're driving the koolaid.
(Score: 3, Touché) by kazzie on Thursday August 03 2017, @10:08AM
Don't drink and drive!
(Score: 2) by sjames on Thursday August 03 2017, @12:31AM
There are many to choose from. Most don't try to wedge themselves into the system like systemd does.
(Score: 3, Informative) by pendorbound on Wednesday August 02 2017, @07:04PM (1 child)
Root on ZFS is extremely do-able. It's easier if you have a /boot partition on something like ext2, but recent GRUB can read your kernel and initrd directly from a zfs /boot or single root containing /boot.
You need an initrd with the ZFS module in it, but that's really the only requirement different from using an in-tree driver for root. The distro-level support scripts for it are quite solid. There's no licensing issue with using it in initrd in this fashion.
I've been using root on ZFS with Gentoo for about 8 years now. Initially I used ext2 for /boot. I moved to some custom patched versions of GRUB, and now using generally available GRUB with no more separate /boot.
(Score: 2) by sjames on Friday August 04 2017, @12:09AM
Good to know! :-)
(Score: 3, Insightful) by VLM on Wednesday August 02 2017, @08:39PM (1 child)
Not bad, but a unix-like might be an even better phrase. And FreeBSD is freaking awesome and works great. No licensing problems, "just works". Has a sane and easy/fast to debug init system, totally non-windows/redhat-alike in general.
Don't dedupe which is cool but both not terribly useful and eats memory, or if you're spending an inordinate amount of money on drive space, budget perhaps $100 of ram for every $1000 of spinning rust. If you're building SSD and you have enough storage for a "normal" amount of ram to be a problem, then you must have a very large budget indeed and a couple gigs here and there will be OK.
(Score: 2) by sjames on Wednesday August 02 2017, @09:48PM
Perhaps so. No slight to FreeBSD intended.
(Score: 4, Informative) by WillR on Wednesday August 02 2017, @04:55PM (1 child)
porn and pirated musictotally legitimate Linux ISO collection more times than reiser4 did.(Score: 2) by sjames on Friday August 04 2017, @12:22AM
Other than using raid > 1, what have you seen cause a problem?
(Score: 3, Funny) by Bot on Wednesday August 02 2017, @07:21PM (2 children)
> What are the disadvantages of Btrfs?
for one, it is reportedly being called butterFS.
Account abandoned.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 02 2017, @09:23PM (1 child)
uhh, it's pronounced "Butt R"!
(Score: 1, Informative) by Anonymous Coward on Friday August 04 2017, @07:24PM
Not sure how they got butterfs out of btrfs, it's clearly bitterfs.
(Score: 2) by chromas on Wednesday August 02 2017, @11:36PM
Until late last year, I was using btrfs on two luks-encrypted disks (no RAID or anything). It worked fine most of the time, but any time there was much disk activity firefox would freeze up, or when doing something even more I/O-ier like moving a big file, the whole desktop would lock up.
But I gave up on it when trying to rip a CD caused one of the disks to disappear (bad optical drive?) and btrfs absolutely refused to do anything with the disk after that. Trying to mount it, it would just tell me it wasn't a btrfs volume and the offline restore tool would just segfault. I've since put XFS and EXT4 on those same disks (still encrypted) and have no problems. Also tossed the optical drive since it threw errors during POST.
(Score: 2) by Entropy on Thursday August 03 2017, @12:25AM (3 children)
BTRFS is an inferior version of ZFS, basically. The interface is awful in comparison, and it has many silly requirements(why exactly would I want snapshots mounted all the time or read-write? Kinda defeats the point.) Also why is a snapshot command like a copy command?
btrfs subvolume snapshot /mnt/data /mnt/data_mysnap
vs
zfs create mnt/data@mysnap
Which is more intuitive? A snapshot isn't a COPY. It never was a copy. It's a set of pointers moved around. In BTRFS I furthermore have to worry about some program bumbling into my snapshot and changing something because it's both obviously mounted, and writeable. BTRFS to my knowledge has never had volume support(like devices).
Keep in mind with ZFS's volume support comes snapshot of volumes(think virtual machines) and block-level replication of those virtual machines.
(Score: 2) by sjames on Friday August 04 2017, @01:13AM (2 children)
You can mark the snapshot read only if you like. the fs doesn't treat it as distinct from a COW duplicate because it has no need to. You may make it read only and treat it as special if you want, it's an administrative policy.
The snapshot/copy isn't really mounted all the time, think of the root volume of a btrfs as the administrative interface. You can unmount that when not operating on the filesystem, or put it where only root can see it. use the subvolid option to mount to directly mount the subvolumes without exposing the root volume with the snapshots in it.
You are correct about volume support. It would be nice for BTRFS to get that at some point.
(Score: 2) by Entropy on Friday August 04 2017, @01:19AM (1 child)
You can work around it... It's just always felt more clumsy to me than ZFS. Seeing as ZFS came first, and has wide enterprise support I wish they just stole the interface. As to not mounted all the time, I think if you find / ...it'll list all the files. Can you truly make it not mounted as in it isn't in the directory tree anywhere?
(Score: 2) by sjames on Friday August 04 2017, @01:54AM
Yes. By convention, you create a subvolume called @ and mount it to /. You may also create things like @home or (depending on need, @username) and mount it all up using the subvolid option.
I typically ALSO choose to mount the root as /btrfs with root owning the mount point and only root granted access, but that is purely optional and a matter of taste. This means that /btrfs/@ is the same as /. Skip that and it's not in the tree.
(Score: 2) by engblom on Wednesday August 02 2017, @04:37PM (3 children)
XFS is developed by RedHat, so expect more features for XFS. I wish they would include ready compiled ZFS, as Ubuntu does, but sadly they have not shown the same interest for ZFS.
Besides checksums, transparent compression and snapshots I find the datasets of ZFS to be a really useful feature as you still have different "partitions" (=dataset), but you do not need to reserv space, so you get more out of one hard disk. If you really want to reserv space, you can also do it with dataset quotas. LVM partly does the same, but it is not automatic and many filesystems are not able to shrink in order to give the free space back to another volume when needed.
(Score: 4, Funny) by Bot on Wednesday August 02 2017, @07:23PM (2 children)
> XFS developed by RH
This is strange, no dependency on systemd yet.
Account abandoned.
(Score: 3, Informative) by frojack on Wednesday August 02 2017, @08:45PM (1 child)
It was mature and largely feature complete well before systemd arrived.
Besides you and the GP are wrong.
XFS was created by Silicon Graphics, Inc (SGI) in 1993.
No, you are mistaken. I've always had this sig.
(Score: 2) by engblom on Friday August 11 2017, @05:43AM
I have used XFS probably longer than most people visting soylentnews, and I know very well that SGI created XFS. However, it is correct as I said, that RH is developing XFS. SGI has been gone for 8 years.
(Score: 3, Interesting) by nimbius on Wednesday August 02 2017, @04:54PM (4 children)
BTRFS is easily one of the greatest open source achievements in the past 10 years. this filesystem was designed to be the killing blow for vendors like NetApp, who had inline deduplication, mirroring, and snapshotting in WAFL-fs for a premium. XFS is a nice idea but hasnt had a status update in four years on the wiki so the idea that theres an active community is a little far fetched...its just redhat's knee jerk response to ceph switching recommendations at the last minute to XFS in order to shore up issues with emerging versions of BTRFS in the RADOS/FUSE layer. at this point the only dev is redhat and the 2038 epoch issue isnt going away. So what then? EXT4? its a joke compared to BTRFS's performance and offers none of the deduplication. ZFS? sure, just be sure to budget for triple the RAM everywhere.
First systemd, now we get rid of BTRFS? Jesus Christ Redhat...what are you thinking? and FWIW btrfs isnt going away. I'll just pull it from EPEL.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @06:11PM (2 children)
What's EPEL?
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @06:26PM
Extra Packages for Enterprise Linux (EPEL)
https://fedoraproject.org/wiki/EPEL [fedoraproject.org]
(Score: 2) by zocalo on Wednesday August 02 2017, @06:27PM
UNIX? They're not even circumcised! Savages!
(Score: 2) by rleigh on Wednesday August 02 2017, @07:49PM
I would not count it as a "greatest achievement". Despite all the effort which went into it, they failed to do the necessary up-front design work, and then failed to create a robust implementation. It's been a buggy mess since the start, and despite lots of work since then, it's still a mess. Lots of effort on the codebase can't work around fundamental design flaws baked into the on-disc format.
They wanted to create something better than ZFS. But when it came to the design, they ignored much of the subtle details of ZFS and failed to appreciate the implications. This is why the fsync performance of Btrfs is abysmal, likewise snapshot performance and deletion, but it's almost negligable with ZFS. Why? Because the ZFS design was carefully considered and this was ignored by the Btrfs developers.
Btrfs is a poster child for hubris. Despite all the hype, and the vast number of man hours which went into it, it's still very immature. It doesn't hold a candle to ZFS from a decade ago, let alone today, and that was entirely self-inflicted by rushing to write code before working on the design. And then freezing the on-disc format when it was known to be defective in multiple ways, thereby preventing whole swathes of problems from ever being fixed.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday August 02 2017, @05:38PM (8 children)
Perhaps SystemD set up to crash and burn if run on a system that uses Btrfs?
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @05:53PM (2 children)
They'll just roll it up into systemd.
(Score: 2) by kaszz on Wednesday August 02 2017, @06:00PM
You shall have no other processes before systemd. Other processes are heresy! :p
(Score: 3, Informative) by zocalo on Wednesday August 02 2017, @06:34PM
UNIX? They're not even circumcised! Savages!
(Score: 4, Informative) by sjames on Wednesday August 02 2017, @05:57PM
Systemd already refuses to boot if the root filesystem is BTRFS and it needs to be in degraded mode due to loss of a drive.
(Score: 2) by Bot on Wednesday August 02 2017, @07:27PM
> Perhaps SystemD set up to crash and burn...
Failing early and verbosely? That's too unixy.
Account abandoned.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @11:34PM (2 children)
Yep, I was thinking the same thing. SystemD FS.
Remember, if something goes wrong with it, its your fault -- WON'T FIX, NOT A BUG.
(Score: 2) by kaszz on Thursday August 03 2017, @12:11AM (1 child)
Is there any way to use such refusals to make them suffer at their own making?
(Score: 0) by Anonymous Coward on Thursday August 03 2017, @03:11PM
Infiltrate the redhat dev community
get mainainership over widely used programs
hide systemd exploits in packages
Nuke them from orbit
(Score: 3, Offtopic) by kaszz on Wednesday August 02 2017, @05:55PM (12 children)
Linux Foundation quietly drops community representation [lwn.net]
Karen Sandler comes from a US law degree background and practicing corporate law.
There's more over at lwn.net:
Is it here the GNOME <--> systemd <--> RedHat <--> Shelton <--> Military connection becomes obvious?
After all the US military is the largest customer [soylentnews.org] money wise to RedHat.
SFC = Software Freedom Conservancy
(Score: 1, Interesting) by Anonymous Coward on Wednesday August 02 2017, @06:31PM
Jews are very hard working, dedicated people; hence Richard Stallman, etc.
They are a disaster when they're on the wrong side of things; hence people like Ms. Sandler.
(Score: 3, Insightful) by Grishnakh on Wednesday August 02 2017, @07:21PM (3 children)
GTK is no longer a serious competitor to QT in any respect. Every Linux desktop install in a commercial Desktop installation I have seen in the last ~5 years has run KDE. if for no other reason because any custom tools that are written now use QT or PYQT/PYSIDE so it makes utterly no sense to try to adapt the crippled GNOME desktop into a usable workspace that runs predominantly QT applications.
Where the hell did this come from? This is a completely warped view of reality; here in the real world, almost everyone running Linux on a desktop (or VM) is using Gnome3, to my horror I'll add. GTK is indeed a horrible toolkit IMPO, and Gnome3 is a horrible desktop environment IMO, but that doesn't seem to stop it from being by far the most popular choice, even with MATE and Cinnamon being made in response to it. (Even worse, those two also use GTK; they eschew Gnome3, but not its horrid toolkit.) And Ubuntu has now switched to Gnome3 too. Almost no one uses KDE in my observation, and few distros feature it as a first-class DE.
As much as I'd like to see the Gnome devs all be forced out of software and into cleaning toilets for a living, for Red Hat to become a bit player while other distros rise to prominence, and for the world to dump Windows and Mac and adopt Linux en masse with KDE, XFCE, and LXDE (now LXQt) being the top choices, what you quote here simply doesn't resemble reality in my universe whatsoever.
As for the Linux Foundation, that thing is an abomination. Any organization that allegedly exists to advance Free software and Linux but has Microsoft as a "platinum member" is clearly corrupt and lying about its real mission.
(Score: 2) by kaszz on Thursday August 03 2017, @12:06AM (2 children)
The post that upset you came from "Posted Jan 21, 2016 22:25 UTC (Thu) by brine (guest, #106482)". The full posting here:
I do suspect Gnome3 use less memory than KDE and is less intrusive too. Why no one forked Gnome seems weird. Maybe twm is better these days..
RedHat will be DeadRat. But the rest of the community don't need to depend on them. I think that is the important factor. And that they may not strongly influence other project on design issues.
I read that the invasion of Iraq was done using RedHat OS. But that should imply that they were infested with systemd. Wouldn't that be a reliability issue? "Sorry car won't boot, systemd botched init files. Please use nearest RS232 terminal.." while being shoot at....
I missed that Linux Foundation had Microsoft as "platinum member". But that and the trash ideology does it for me. Final nail *bang*.. and then usenet *plonk* ;-)
(Score: 1) by EEMac on Thursday August 03 2017, @12:58PM (1 child)
They [mate-desktop.org] did [linuxmint.com].
(Score: 2) by kaszz on Friday August 04 2017, @03:08AM
Great tip. Thanks.
https://en.wikipedia.org/wiki/MATE_%28software%29 [wikipedia.org]
https://en.wikipedia.org/wiki/Linux_Mint [wikipedia.org]
(Score: 3, Informative) by requerdanos on Wednesday August 02 2017, @07:35PM (2 children)
That article's over a year and a half old. Please stop modding parent up.
(Score: 0) by Anonymous Coward on Thursday August 03 2017, @12:11AM
Why? Is old news no longer true?
(Score: 2) by kaszz on Thursday August 03 2017, @12:17AM
Have the issues been resolved?
(Score: 2) by jmorris on Thursday August 03 2017, @05:30AM (1 child)
I'd say that this incident shows LF willing to take difficult steps to prevent a blatant attempt to seize the Foundation's resources and Converge it to a purpose incompatible with its current mission. Banning all individual contributers from running for the position was drastic but probably the only measure that could be quickly implemented once the clear and present danger presented itself.
Any organization that has goodwill, public influence or controls material resources should be implementing positive measures to prevent Entryism. It is the only defense possible, once they get in the only cure is burn / abandon and build anew because THEY will always be willing to see the organization destroyed than see it reclaimed for the purpose it was founded for.
(Score: 2) by kaszz on Friday August 04 2017, @02:55AM
The alternative is to burn the people doing the entryism.
(Score: 1) by crafoo on Thursday August 03 2017, @04:05PM (1 child)
This is incredibly interesting. It's unfortunate to see open source software so heavily politicized. Is Btrfs being pushed to the wayside due to lack of funding on core technology issues? It seems file system development would be a better use of funds.
(Score: 2) by kaszz on Friday August 04 2017, @03:00AM
I have also noted the politicization of open source software as of the last years. Seems as soon as there is money, influence or recognition. These sociopaths creeps up. I think there needs to be some mechanisms that makes sure those shitheads never get any say in the process.
Evaluating if a organization is conducive to good coding and research tends to quickly show which ones that are astray.
(Score: 2) by chromas on Wednesday August 02 2017, @08:32PM (4 children)
I bet this makes Lennart [0pointer.net] a sad panda.
(Score: 4, Insightful) by FatPhil on Wednesday August 02 2017, @09:53PM (3 children)
Invalid username - have access as root.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by chromas on Wednesday August 02 2017, @11:23PM (2 children)
Thanks man. systemctl enable systemd-nsa-backdoor-loaderd
(Score: 2) by kaszz on Thursday August 03 2017, @12:09AM
"You got a new pen-pal at NSA" ;-)
(Score: 0) by Anonymous Coward on Thursday August 03 2017, @04:54PM
That command is redundant, systemd-nsa-backdoor-loaderd is already installed and enabled by the "apt-get install systemd", "dnf install systemd", or "pacman -S systemd"
(Score: 1) by axsdenied on Thursday August 03 2017, @02:14AM
I, for one, welcome our new systemd-FS overlords.