Ubuntu Developers Seem To Be Really Pursuing ZFS Root Partition Support On The Desktop

[hoconnor]

I'd still prefer much more OpenSUSE over that so I think I'll try to see how stable OpenSUSE Tumbleweed can be on a ZFS array first.

Did you install ZFS-on-root with OpenSUSE?

[aht0]

Dunno, I can't remember of anything developed in BSD that has been finished in this decade. EDIT: ah yes I remembered something, LibreSSL.

OpenBSD: OpenIKED, iscsid, rc.d/rc.subr, tftpf, npppd, ldomd, sndiod, cu, identd, slowcgi, signify, htpasswd, LibreSSL, rcctl, file, doas, radiusd, eigrpd, rebound, vmm, switchd, syspatch, xenodm, ocspcheck, slaacd, rad..

FreeBSD: Capsicum, Bhyve, nginx

Random selection of released software with a BSD license, and not GPL.
Arcan display server (mostly BSD licensed). BSD licensed: Nvidia's PhysX SDK, Chromium, Theora, Tor, Vi, Bionic, CMake, Django, i3, Klibc, Mumble, OpenCV, OpenMPT, OpenRC, Ruby, Vorbis, VP9, WebRTC, Zend (some of it might exceed 'this decade' condition, did not bother checking after a while)

Their "systemd-like" init? Not finished yet, many years down the line, maybe not even a major project

err.. what? AFAIK none, except TrueOS is dissatisfied with traditional init. BSD init does not have problem returning service status like Linux's SysV init has, parallelization is sort of unimportant, when it does not really work often too well on systemd either.. Service control (restart etc) can be established using certain applications from ports tree.

Their "layer to run linux drivers" not finished yet, also many years down the line

Which Linux drivers? Graphics. Intel, AMD and Nvidia graphics works. 11.2-RELEASE brought alive bunch of newer cards until then non-working.

ZFS? they are just a downstream.

downstream and it's now a native file system with bunch of modifications to the OS itself to make it tightly integrated.

HAMMER2? developed by someone since 2012, ETA for completion unknown
Regarding HAMMER2, you have no fucking clue. Does something like this https://gitweb.dragonflybsd.org/drag...hammer2/DESIGN
look like:
-finished
-comparable to btrfs

Amount of features is pretty meaningless, when you cannot TRUST the file system in the first place. So, yes, H2 is "more finished" in my eyes.
I haven't managed to have single install using BTRfs lasting more than month, before something fatal happening to it. H2 somehow has survived, meaning despite amount of features, individual items have gotten more care.

Latest OpenSUSE could not even finish install before installer threw me an error because apparently something went wrong with taking a snapshot right there. Before I even finished flippin' install itself.

It is a cluster filesystem, which is an entirely different type filesytem. https://en.wikipedia.org/wiki/Clustered_file_system
And yet it can't be used as cluster filesystem, as it still lacks the features to do so.
What HAMMER2 is good at now is more or less what Btrfs is also good/stable at, single drive only, no replication (RAID), no clustering. In both cases it's a far cry from the actual goal of the filesystem.

It's usable for single drive install and does IMHO better job at it too. When I really want a raid, I can use the original Hammer, which does have RAID,SPAN.JBOD capability. Bother Hammers are accessible from DragonFly's installer.

VK9 is a library supposed to be run on Windows, or through Wine (which is multiplatform and can run on MacOS or BSDs too).
What the fuck makes it a "linux project" in your mind?

https://github.com/disks86/VK9

I looked at sources and while I could spot #elif defined macros for win32, linux and macOS, I spotted none for any of the bsds. THAT makes it pretty convincingly something that does not run on BSD's without it having to be ported first.

Why I think it's 'Linux software':

WHY would somebody try to run 'DX9 over Vulkan' on Windows? - Windows is a fucking native platform for DirectX to start with - DX9 apps work by default and just fine. I am playing Arma3 enforcing DX9 if need be and it just works (tested). Ergo, it's truly usable only on Linux or Mac.
Now, lets look at Mac's. Currently (as of 2019) there are 0 Mac models remotely suitable for gaming, out of 10 being offered.
Mac's come with mishmash of iGPU's or workstation gpu's, which are not suited for gaming. Ergo, it IS Linux software, even if not built for exclusively for Linux, it's mostly usable on Linux. Rest of the support is just decorative.

More stupidity. KDE is not a Linux project, it is also running on BSDs, and most of their libraries use LGPL or BSD/MIT licenses.
KDE core (the libraries) allow to make cross-platform applications for Android and even Windows.

Oh, but it is "Linux project" Took years to get Plasma5 ported to FreeBSD in the first place. Why would you need porting on 'universal' code? It's still unusable on any of the other BSD's besides FreeBSD and TrueOS. Windows port required similar effort and it never worked properly - I've tried it.

Compiling KDE sources on FreeBSD goes like this: original sources get downloaded by port system, then port system does bunch of pre-defined automatic PATCHING on unpacked sources right there, then you can start compiling. 'Raw' sources without patching won't compile under FreeBSD.

It was the same deal with KDE3 and KDE4. Getting it working on BSD required dedicated removal of Linux-specific code/interfaces and adding BSD-compatible replacements. KDE increasing linuxisms were the very reason why PC-BSD became TrueOS and iXSystems started developing Lumina.

This is Canonical's work. You know the ones that ALWAYS reinvented the wheel when given the opportunity. Hardly big enough to be the flag of all things Linux though.

Agree to disagree.

[Holograph]

All this whining about Waah MUH GPL

ZoL does not violate GPL. You can do whatever you want to make it work, as long as the stuff you do to make it work is released under GPL.

You don't get sued for putting 2 non-officially-compatible things together.

Besides, with lawsuits, you sue for damages. What do you all think the "damage" is by allowing ZoL?

Most of us end users don't give 2 F's about the GPL itself. You who do are by far the minority. And the rest of us do not care what you think. At all. Go ahead and sue Canonical. I'd love to laugh at you having to pay for their lawyers.

[scineram]

Speaking of clustered filesystems, Lustre is one of the biggest users of ZFS on Linux.

https://www.youtube.com/watch?v=RoyrIocAByU

https://www.youtube.com/watch?v=4BxYjpJM-GE

https://www.youtube.com/watch?v=29VHDHm2C_s

https://www.youtube.com/watch?v=evY44I26TIQ

but you'll have to live without Firefox

The only problem with MPL is about logos and the name, there are plenty of forks that sidestep the issue.

[k1e0x]

I do not wish to be associated with Linux, if anything, I feel like the ship is sinking and the kernel will start becoming irrelevant. Microsoft seems to be stagnating, and OSes with Linux might start taking over. If anything, call me a GNU GPL zealot, as that's what I care about. While I used to like Torvalds for his attitude, his support for "open source" made me dislike him.

As for CDDL, I don't even care about the content of it, as the issue is the lack of compatibility with GNU GPL. It doesn't even matter whether it provides all 4 freedoms, it's effectively as bad as proprietary software because it's incompatible with GNU.

I think the GPL maybe was important in the 90's when Microsoft and other propitiatory software looked like it was going to rule the earth.. but I feel business gets it now and want their code to be open so they don't have to maintain a fork. Due to that I like more business friendly licenses. It's the terms of the GPL that makes it incompatible, not anything in the CDDL. This is why you see ZFS on every other OS except Linux. Solaris, BSD's, Mac OS even Windows and Haikau have a port. It's positioned to be a universal file system.. maybe even a replacement for fat32. (I want checksums on my usb stick, don't you? having glitches in that freebird mp3 really sucks lol)

It's unclear also if the CDDL is *actually* incompatible. It was Debian that originally found fault in it, Sun believed it was (at least the developers that have spoken upon it) pretty much the FSF and GNU say it isn't but others (such as Canonical and a Law professor at Cambridge say it is, because of a few reasons. (the fact that it's not a derivative work and it's file based and it's intent is compatible in spirit with the GPL) A real legal test should be put forth because if it is.. maybe we can all agree to work on bcachefs or something.

And.. if you really feel this way.. that's fine.. but you'll have to live without Firefox, Libreoffice, VirtualBox, Syncthing.. and a ton of other stuff you probably use every day is similarly licensed as ZFS.

[starshipeleven]

Mentality appears slightly different for me between users of two OS families with drastically different patience levels. You could describe it as one sort likes to 'hack away and see what comes out', other likes to 'build'. In BSD progress could be slow but usually shit ends up finished. Instead of being abandoned the moment something else strikes dev's fancy. Sometimes 25%, or 50% or effin' 95% done.

Dunno, I can't remember of anything developed in BSD that has been finished in this decade. EDIT: ah yes I remembered something, LibreSSL.

Their "systemd-like" init? Not finished yet, many years down the line, maybe not even a major project
Their "layer to run linux drivers" not finished yet, also many years down the line
ZFS? they are just a downstream.
HAMMER2? developed by someone since 2012, ETA for completion unknown

BTRfs as a project was started with huge fanfares, bunch of devs, multiple CORPORATION's participated. Everybody, their dog and cat cheered over 'future-ZFS-killer'. 12 years later it's still only 'mostly-done', where not even BTRfs own wiki does not dare proclaim it as a 'stable'. Even worse, some of the initial backers, like Red Hat have seemingly dropped idea of adopting it completely - it's indication RH considers BTRfs a 'lost cause'. VS. Matthew Dillon started Hammer early 2007, worked out design in 9 months and finished it up by 2011. Alone. Then announced plan for better-designed successor and got it done by last year. Despite the multi-year stall in-between he finished Hammer 2. Again. alone.

This is so fucking wrong.

RedHat was never an "initial backer" in any way, shape or form. They just provided it as a "preview" to see if their customers actually wanted it. Turns out their customers wanted a easy-mode tool to use what is already there, RH went for it.

Regarding HAMMER2, you have no fucking clue. Does something like this https://gitweb.dragonflybsd.org/drag...hammer2/DESIGN

look like:
-finished
-comparable to btrfs

It is a cluster filesystem, which is an entirely different type filesytem. https://en.wikipedia.org/wiki/Clustered_file_system

And yet it can't be used as cluster filesystem, as it still lacks the features to do so.

What HAMMER2 is good at now is more or less what Btrfs is also good/stable at, single drive only, no replication (RAID), no clustering. In both cases it's a far cry from the actual goal of the filesystem.

Recent Phoronix article "VK9 Project Stalls As Developer Leaves To Pursue Other Interests". Does it feel familiar behavior?

VK9 is a library supposed to be run on Windows, or through Wine (which is multiplatform and can run on MacOS or BSDs too).
What the fuck makes it a "linux project" in your mind?

https://github.com/disks86/VK9

When KDE3 became finally digestable and actually pretty darn good it was suddenly axed and KDE4 started from ground up. Pattern was repeated with Plasma5. Each time between EOL'ing the old and 'reinventing the wheel', the 'then-new-wheel's initial versions were as a rule rather buggy crap. Each time it took like 7+ point-releases before new KDE would be stable enough for daily use.

More stupidity. KDE is not a Linux project, it is also running on BSDs, and most of their libraries use LGPL or BSD/MIT licenses.
KDE core (the libraries) allow to make cross-platform applications for Android and even Windows.

But it is a "linux project", because reasons.

--Mir. "We do our own thing". Then axe it. Then use some of it. Waste bunch of years and developer hours while doing it.
--Unity, pretty much repeat pattern. 6 years of wasted efforts. Both read to me as 'clueless flailing around'..

This is Canonical's work. You know the ones that ALWAYS reinvented the wheel when given the opportunity. Hardly big enough to be the flag of all things Linux though.

Wayland display protocol, regardless of reasons, it looks and feels like an flippin' endless road. X still reigns supreme, 10 years after Wayland's initial release, it's been employed in one distribution, Fedora. Ubuntu previous release used Wayland as well but reverted back to X for it's latest.

It's in a pretty decent shape, and for what it actually is, it's not doing as bad as you think. It will be ready to be a default within a few more years as even now it "mostly works".

To the contrary of Btrfs where I can't see the light at the end of the tunnel, and I'm subscribed to their mailing lists too.

Windows software does rule the world. From user's POV.

That's completely tangential to the point. Proprietary software also does exactly the same as your "idea of linux software".

It comes down to want. If you want, you can use loopholes in GPL and take it for free too. Many companies do it.

It's objectively harder to exploit GPL than working with a project where you have no such limitations to begin with.

Let's say your changes are not proprietary/business secret, isn't it cheaper long-term to upstream?

Maybe? It all depends on how much you care about tracking closely upstream, and how complex it is to upstream.

Let's not forget that upstreaming something that "WorksForMe"(tm) isn't a painless process, especially if upstream disagrees with your "time-sensitive coding practices" and calls them "horrible hacks" and NAKs them.

[aht0]

So is this a pattern or just a sampling of open-source software projects with no real pattern, aside from, you know, being software?
Where is the 100% done open-source software project? And even if you've found it, is it reasonable to expect all open source software projects to reach 100% completion? How should they go about achieving it?

I presented you pretty much random list of projects. You can choose to take it literally if you wish. I wanted to use that list for illustration.

First let's get clear in base definitions:

• Is it piece of software that has met it's design goals and stays unchanged for years? As, "it works, does it well, don't further fu*k with it". If you wish, I can provide some examples.
• Or is it software that has met it's design goals, it's features are properly finished (fully working) and new features are introduced on occasion? Which also are finished before dev considers adding more.

For me either is 100% done, provided that all features are fully working.

• Software that has set of announced/planned design goals/features but of which some or more are half-finished or not working at all, is not 100% done.
• Software that ..(repeating previous sentence).. or not working at all AND where devs keep adding - is not 100% done by far and is in fact, the absolute worst.

And what I absolutely effin' hate - Lots of Linux-associated software (and many Linux distros themselves) have half-assed AND overcomplicated feel because they belong to the latter category. Introducing half-baked new stuff, then switching directions et cetera is more important for Linux developers ( & dev's developing for Linux) than finishing their work.

To put it short: Linux devs are interested more about feature-creep than tiding up loose ends. BSD devs rather bite less and finish what they had started. That's my subjective POV.

To give you another example of different philosophy: OpenBSD does not allow half-finished new features/components into their OS releases. Wanna add something to OS, finish it first - then it will be added to the next release. How often do you see something like this in Linux software-sphere?

I like HAMMER2, I've no problem with that but you'll need to get it by religous Linux zealots like yourself because it's got the wrong license for you. "GPL onry ppl"

I happen to *like* CDDL/MPL licenses. Have you read it? File based, weak copyleft, flexible and still requires changes to be public. It's the good parts of the GPL and not the bad.

I do not wish to be associated with Linux, if anything, I feel like the ship is sinking and the kernel will start becoming irrelevant. Microsoft seems to be stagnating, and OSes with Linux might start taking over. If anything, call me a GNU GPL zealot, as that's what I care about. While I used to like Torvalds for his attitude, his support for "open source" made me dislike him.

As for CDDL, I don't even care about the content of it, as the issue is the lack of compatibility with GNU GPL. It doesn't even matter whether it provides all 4 freedoms, it's effectively as bad as proprietary software because it's incompatible with GNU.

[gmturner]

Mentality appears slightly different for me between users of two OS families with drastically different patience levels. You could describe it as one sort likes to 'hack away and see what comes out', other likes to 'build'. In BSD progress could be slow but usually shit ends up finished. Instead of being abandoned the moment something else strikes dev's fancy. Sometimes 25%, or 50% or effin' 95% done.

I think this is like saying, look at this pattern, people's hearts always seem to stop beating and they die, or, look at all these buildings falling apart, that's a pattern in buildings.

Some software projects might theoretically be immortal; I will get back to you on that at the end of time. But this isn't capturing a salient social or institutional dynamic, it mixes up correlation and causation, and it ignores the life-cycle of open-source projects, which can benefit us either by being useful now, or later, or both, and dead projects may have been useful in the past.

Here's my personal take on your list:

• BTRfs: hard for me to say what went wrong here, but creeping-featurism may have played a role if I had to guess. Also, it does continue to slowly improve, maybe there is hope for btrfs yet? Maybe a lot of us may have some sort of "ptsd" from trying this in production too early. I know, for me, any tiny problem with btrfs just seems like the sky is falling and I just didn't want to feel that way anymore, so I stopped using it.
• VK9: dxvk took away all its potential market-share, leaving a lone developer who felt like he was just in a room by himself writing code
• KDE{3,4}: In both cases, the replacement projects provided migration paths and ultimately exceeded the value of their predecessors. There was some pain along the way, we must admit. They have even softened their stance on the crouton or whatever that stupid thing was on your desktop that they wouldn't let you get rid of.
• Mir: No clue/knowledge, I simply can't speak about it intelligently.
• Unity: Kind of the Windows 8 of the Linux desktop. A DE experience/paradigm that, arguably, most users simply didn't like or want, at least at first. This seems to more nearly conform to the pattern you're describing, aht0, than the others, as, like Windows 8, it was indeed abandoned before the dark cloud of negative initial reception was given time to dissipate.
• Wayland: wayland is definitely not dead but it's a huge project with a very high critical mass in the sense that end-users aren't going to want to migrate until almost every bug and limitation is fully ironed out. Perhaps wayland should have provided more of an evolutionary migration path (although this is a hard problem in itself, given that the idea of wayland is kind-of to make a clean break from legacy encumberments). I see wayland advocates bad-mouthing every fork or client-project that attempts to fill the gaps in the reference implementation. Now that's a real anti-pattern in open-source projects, everyone should stop doing that.

So is this a pattern or just a sampling of open-source software projects with no real pattern, aside from, you know, being software?

Where is the 100% done open-source software project? And even if you've found it, is it reasonable to expect all open source software projects to reach 100% completion? How should they go about achieving it?

TLDR: the failure of projects is a necessary part of how software can deliver value. Turning around and calling it a pattern tied to linux or even open-source seems unfair.