Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by janrinok on Friday October 18 2019, @11:53PM   Printer-friendly
from the all-change dept.

Project Trident will be built on Void Linux starting January 2020 and leave its current base of TrueOS behind. This will immediately improve GPU driver support, sound card and streaming, wireless networking, and, for the first time, add Bluetooth capabilities as well as providing newer versions of user applications.

Currently, Project Trident is based on FreeBSD and uses the TrueOS build framework. Over the years, we have accumulated multiple long-standing issues with the underlying FreeBSD OS. Issues with hardware compatibility, communications standards, or package availability continue to limit Project Trident users. After many years of waiting for solutions, there don't appear to be any resolutions on the horizon. To continue to strive for the stated project goals, we have had to make the difficult decision to shift our focus and move to an operating system that better suits what Project Trident is trying to deliver to our users.

Earlier on SN:
TrueOS Doesn't Want to Be 'BSD for Desktop' Anymore (2018)


Original Submission

Related Stories

TrueOS Doesn’t Want to Be ‘BSD for Desktop’ Anymore 22 comments

TrueOS, once a FreeBSD distro, will change the focus of their project and become a full, separate fork. TrueOS was known especially for providing a nice FreeBSD desktop based on -CURRENT with the Lumina desktop environment and the ZFS file system by default. Now it is a full fork.

Essentially, TrueOs will become a downstream fork of FreeBSD. They will integrate newer software into the system, such as OpenRC and LibreSSL. They hope to stick to a 6-month release cycle.

From
It's FOSS : TrueOS Doesn't Want to Be 'BSD for Desktop' Anymore
FreeBSD News : TrueOS to become a fork of FreeBSD
TrueOS Blog : TrueOS to Focus on Core Operating System


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Insightful) by Rosco P. Coltrane on Saturday October 19 2019, @12:25AM (1 child)

    by Rosco P. Coltrane (4757) on Saturday October 19 2019, @12:25AM (#909047)

    Desktop FreeBSD distro becomes desktop Linux distro.

    • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @05:47AM

      by Anonymous Coward on Saturday October 19 2019, @05:47AM (#909152)

      "Desktop FreeBSD distro becomes YET ANOTHER desktop Linux distro."

  • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @12:29AM (12 children)

    by Anonymous Coward on Saturday October 19 2019, @12:29AM (#909054)

    Why did they choose FreeBSD in the first place? Did a political coup occur to get them to move to Linux? And Void Linux at that, which I note is one of the SystemD resisters.

    • (Score: -1, Flamebait) by Anonymous Coward on Saturday October 19 2019, @12:41AM

      by Anonymous Coward on Saturday October 19 2019, @12:41AM (#909060)

      They were looking for a more inclusive CoC since the lead developer decided to have gender reassignment surgery.

    • (Score: 2, Informative) by Anonymous Coward on Saturday October 19 2019, @01:12AM (1 child)

      by Anonymous Coward on Saturday October 19 2019, @01:12AM (#909077)
      Actually, Void Linux was one of the first distributions to adopt SystemD. Void migrated from SystemD to runit [voidlinux.org] in 2014. I admin a few Debian boxes and vastly prefer runit over systemd for its speed and elegant design while still maintaining the features needed in a modern init system.
      • (Score: 0) by Anonymous Coward on Sunday October 20 2019, @01:54AM

        by Anonymous Coward on Sunday October 20 2019, @01:54AM (#909436)

        They are actually a great study as to why people both like and hate systemd. They originally switched to systemd because it allowed faster, parallel start and service supervision with more reliable logging in a way that is easier for package maintainers. Then systemd started losing the simplicity and throwing in the kitchen sink, so they replaced it with runit (from a couple of alternatives) to get the same benefit without the bloat and ecosystem lock-in.

    • (Score: 5, Interesting) by Mojibake Tengu on Saturday October 19 2019, @01:14AM (8 children)

      by Mojibake Tengu (8598) on Saturday October 19 2019, @01:14AM (#909078) Journal

      One of the hidden funny reasons may be the Trident project does not value user security too much, for it prefers infamous VirtualBox virtualization, while state of the art of security on FreeBSD is bhyve https://bhyve.org/ [bhyve.org] and jails using bhyve and ZFS. Both hypervisors cannot be used at the same time. For me myself, this is exactly the most critical factor for not using Linux on desktop and using FreeBSD instead. Any other arguments about hardware incompatibilities are always only temporary. Also, note the features in ZFS filesystem necessary to use jails safely are missing completely from Linux ZFS implementation. From my perspective, the Trident project shoots itself into head, not just into leg. It is not a secure distro at all.

      --
      Respect Authorities. Know your social status. Woke responsibly.
      • (Score: 2, Insightful) by fustakrakich on Saturday October 19 2019, @04:50AM

        by fustakrakich (6150) on Saturday October 19 2019, @04:50AM (#909133) Journal

        And they're waiting for solutions?

        Can't they make them? Or do they just assemble packages and call it a distro?

        --
        La politica e i criminali sono la stessa cosa..
      • (Score: 2) by darkfeline on Saturday October 19 2019, @05:33AM (5 children)

        by darkfeline (1030) on Saturday October 19 2019, @05:33AM (#909144) Homepage

        If you're talking about Linux containers, they are quite different from FreeBSD jails. Just like how FreeBSD is about having a monolithic core and Linux is about duct taping random shit together to make something resembling an OS, jails are a monolithic isolation feature while "containers" are simply something glued together with namespaces, cgroups, and perhaps some other parts like overlayfs, selinux, apparmor, etc.

        Jails are nice and all, but you can't share PIDs with another jail, devices with yet another jail, network interfaces with yet another jail, UIDs with yet another jail... like you can with Linux containers. Why would you do that? Because you can, the same reason why you can *gasp* choose to use systemd as your init, or not. Choice, what a revolutionary concept!

        --
        Join the SDF Public Access UNIX System today!
        • (Score: 5, Interesting) by rleigh on Saturday October 19 2019, @07:41AM (4 children)

          by rleigh (4887) on Saturday October 19 2019, @07:41AM (#909168) Homepage

          There is a wide gulf between "choice" and "incoherent, bad design". Jails and Zones were designed. Linux containers are a horrific mess accreted from numerous independent pieces. The interaction between all of the different features is unknowable, and there have been, and will be, numerous performance, reliability and security problems as a consequence. As much as I love Linux, its maintainers have excelled at reimplementing existing designs such as basic Unix and Plan 9 pieces, but have not shown great aptitude for design themselves.

          • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @08:18AM

            by Anonymous Coward on Saturday October 19 2019, @08:18AM (#909172)

            Nail on the head!
            Linux is a clear example of "worse is better."
            I think of it as the Microsoft Windows of open source. It's got the widest spread adoption, so network effects compel you to use it instead of any alternative.

          • (Score: 4, Interesting) by TheRaven on Saturday October 19 2019, @10:19AM

            by TheRaven (270) on Saturday October 19 2019, @10:19AM (#909190) Journal
            Which, in turn, leads to security issues, such as Linux adding a new system call in 32-bit compat mode a few months ago and the policy applied by Docker not being updated to block it, allowing a simple sandbox escape.
            --
            sudo mod me up
          • (Score: 2, Insightful) by Anonymous Coward on Sunday October 20 2019, @02:30AM (1 child)

            by Anonymous Coward on Sunday October 20 2019, @02:30AM (#909450)

            Part of the reason for that is because Linux blazes the trail. The operating systems that come later get to see what they do and take the good parts while redesigning the bad. For a great example look at ASLR. OpenBSD got their first, but was more limited in scope than Linux, which in turn, is more limited in entropy and scope than later implementations in OpenBSD, PaX, and FreeBSD's CURRENT-only version.

            • (Score: 3, Insightful) by rleigh on Sunday October 20 2019, @08:31AM

              by rleigh (4887) on Sunday October 20 2019, @08:31AM (#909508) Homepage

              I have a mixed opinion about this. It's true that it's "blazed the trail" for some things. But it's equally true that it's a sub-standard shoddy mess in many other aspects.

              For the case in point, containers, there was prior art in both Jails and Zones. Linux could have built upon both of these concepts and created something that went even further and was even more powerful and flexible. But it didn't happen. We got a mess. While the individual parts might have had some design, the collection of disparate pieces does not integrate together properly. There wasn't enough communication and planning to result in a sensible and coherent system based upon a sound design.

              We could make the same case about filesystems. Linux is currently a couple of decades behind the state of the art. It doesn't currently have a decent current generation filesytem. Like containers, there was a solid implementation in ZFS. But rather than build the new filesystem upon the solid and well tested design concepts which ZFS pioneered, they went with Btrfs. A hastily-designed and poorly-implemented mess which after a decade is still unreliable, poorly-performing trash with terrible documentation and tooling. They outright rejected some of the carefully considered design in ZFS, without understanding why it was necessary. You've got to have a full understanding of things if you want to improve upon them.

              Even older and simple stuff is junk. Look at something as basic as RS-232 serial I/O. Linux doesn't support the DTR/DSR pins properly. Support is missing from multiple layers in the kernel. The implementation is basically half-arsed.

              This mentality is pervasive. Ultimately, I don't think that never ending code churn is a measure of progress. It's a sign of poor or nonexistent underlying design before coding commenced. It's satisfying to scratch an itch, but it's not particularly professional nor is it the basis for a sound and stable system. We might criticise older Unix systems like Solaris, or BSDs like FreeBSD for being slower moving and less featureful. But what they do have, as a general rule, is better designed and implemented and of higher quality and robustness. New shiny stuff is fun and exciting, but when people are intentionally not learning the lessons of the past or from other systems of the present, that does not improve the quality of the system as a whole. It's just insular and NIH behaviour.

              After using it for 22 years at this point, I've become increasingly disillusioned with the cowboy approach of Linux developers. I've spent the last 4-5 years suffering regular lockups because of fundamental VM defects which are only now beginning to become more widely acknowledged as a critical problem. It's worse than the 2.0.x kernels! Some improvement all that churn has brought. Linux was supposed to be more reliable than this, but there's no one who cares!

              Another problem with "trailblazing" is that if you get it wrong, you still have to maintain the mess indefinitely due to backward compatibility concerns. It will be interesting to see what happens with cgroups and all the other hacks which systemd has made mandatory in the kernel configuration. Once optional, they are now required, and if they ever change or break, systemd breaks. They have painted themselves into a corner of their own making.

      • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @05:57PM

        by Anonymous Coward on Saturday October 19 2019, @05:57PM (#909299)

        wtf does their preference for virtualbox (who the fuck needs that shit goofy shit?) have to do with anything. they left bsd b/c it sucks ass as a desktop OS.

  • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @06:56AM (2 children)

    by Anonymous Coward on Saturday October 19 2019, @06:56AM (#909159)

    Over the years, we have accumulated multiple long-standing issues with the underlying FreeBSD OS.

    Just wait until they encounter systemD issues.. let alone try to get some fixed

    • (Score: 2, Interesting) by Anonymous Coward on Saturday October 19 2019, @12:50PM (1 child)

      by Anonymous Coward on Saturday October 19 2019, @12:50PM (#909215)

      VOID doesn't use systemd. It uses runit. The whole point of VOID was to be Linux, but as BSD like as possible. This is a good thing, as you get all the driver and application support without all the redmondhat dick sucking that Debian derivatives are famous for.

      • (Score: 0) by Anonymous Coward on Saturday October 19 2019, @07:50PM

        by Anonymous Coward on Saturday October 19 2019, @07:50PM (#909345)

        Void really fails at being BSD-like though. Crux's port system is far more BSD-like, and also way way way easier to work with (Pkgbuilds are just a shell script that fills in a few variables and describes how to build the package in a shell function, whereas void has a weird template that's somewhat similar to BSD port Makefiles, but with it's own shitty syntax and formatting and build system that make it way more convenient to just compile by hand than write a new one, plus you have to keep a multi-GB local-tree).

(1)