Right, but this does seem to compound over time, and thus gets worse.
Also, NIH is more prevalent in certain Linux developers/communities than others. systemd adoption/rejection I think is at least somewhat representative of this issue (since one of the issues of systemd is that it is not very portable, requiring glibc [rather like proprietary software….], and integration of, for instance, GNOME with certain subcomponents of systemd creates a dependency of GNOME on systemd – which is currently able to be worked around, creating issues both for any portable to BSDs and also issues for non-systemd Linux distros and for non-glibc distros [Alpine, some Void]).
Yeah, this is really really weird. systemd publishes D-Bus interfaces. It’s just D-Bus, you should be able to use libdbus. But for some reason they created libsystemd which contains a new D-Bus client (and some other little things). And it’s installed as a part of systemd.
So far there are workarounds for these sorts of things. But I worry that these will get harder and harder and that clear systemd/Linux will coalesce. I prefer as much interoperability and interchangeability between components.
I spoke to the FreeBSD folks at fosdem about laptop compatibility as I’d also had issues. The advice they gave was that h/w support is best in -CURRENT so laptop users should treat that as a rolling release. I have yet to try that out.
I run TrueOS which tracks current + the DRM changes. I’m on UNSTABLE, but with Boot Environments it’s not a problem (the last UNSTABLE release actually broke quite a bit for me so I just rolled back, without issue). I suggest it if you want to track the latest stuff but don’t care to do it yourself. cc @oz@leeg
Btrfs has been deprecated. 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.
SuSE still uses btrfs by default, AFAIR, so it’s not deprecated as such, but it also doesn’t have a lot to recommend it……
There is bcachefs, still in development; but even if it is successful, I would assume it would be at least a decade before it would be a real competitor for even present-day ZFS (which presumably would not stand still).
Linux didn’t lose its way. It always suffered from NIH syndrome.
Right, but this does seem to compound over time, and thus gets worse.
Also, NIH is more prevalent in certain Linux developers/communities than others. systemd adoption/rejection I think is at least somewhat representative of this issue (since one of the issues of systemd is that it is not very portable, requiring glibc [rather like proprietary software….], and integration of, for instance, GNOME with certain subcomponents of systemd creates a dependency of GNOME on systemd – which is currently able to be worked around, creating issues both for any portable to BSDs and also issues for non-systemd Linux distros and for non-glibc distros [Alpine, some Void]).
Yeah, this is really really weird. systemd publishes D-Bus interfaces. It’s just D-Bus, you should be able to use
libdbus. But for some reason they createdlibsystemdwhich contains a new D-Bus client (and some other little things). And it’s installed as a part of systemd.So far there are workarounds for these sorts of things. But I worry that these will get harder and harder and that clear systemd/Linux will coalesce. I prefer as much interoperability and interchangeability between components.
I spoke to the FreeBSD folks at fosdem about laptop compatibility as I’d also had issues. The advice they gave was that h/w support is best in -CURRENT so laptop users should treat that as a rolling release. I have yet to try that out.
Are there binary releases of -CURRENT, or is the advice to “rolling recompile” the kernel & base system daily/weekly? 😒
the advice is to compile from source, but rather than doing it regularly to track the -current mailing list and see what folks are talking about.
You have to recompile if you want
evdevsupport in most input device drivers (options EVDEV_SUPPORTin config is still not on by default >_<).I run TrueOS which tracks current + the DRM changes. I’m on UNSTABLE, but with Boot Environments it’s not a problem (the last UNSTABLE release actually broke quite a bit for me so I just rolled back, without issue). I suggest it if you want to track the latest stuff but don’t care to do it yourself. cc @oz @leeg
That’s interesting, I’ll have a look. Thanks!
https://download.freebsd.org/ftp/snapshots/amd64/12.0-CURRENT/
The mention of (now deprecated) btrfs had me scroll up to check the date: 2015. Time flies!
Link to deprecation notice? I was under the impression that it was still under active development.
I assume @varjag is referring to this redhat doc, stating that:
Some people are still developing it, but Red Hat is no longer interested.
SuSE still uses btrfs by default, AFAIR, so it’s not deprecated as such, but it also doesn’t have a lot to recommend it……
There is bcachefs, still in development; but even if it is successful, I would assume it would be at least a decade before it would be a real competitor for even present-day ZFS (which presumably would not stand still).