Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday June 28 2018, @04:26PM   Printer-friendly
from the declining-desktops dept.

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.
  • (Score: 1) by technoid_ on Thursday June 28 2018, @05:15PM (1 child)

    by technoid_ (6593) on Thursday June 28 2018, @05:15PM (#699904)

    Actually heard interest to port Mac OS' launchd to FreeBSD.

    If it sticks to the startup, I will take a look, but no need to re-write the kitchen sink. I don't reboot/power off enough for saving some speed on start that big of a deal to me though.

  • (Score: 4, Interesting) by canopic jug on Thursday June 28 2018, @05:47PM

    by canopic jug (3949) Subscriber Badge on Thursday June 28 2018, @05:47PM (#699913) Journal

    launchd is an init system. systemd is not. So they are not comparable. It would be fine if launchd, openrc, upstart, daemontools, or other actual init systems were ported or had concepts ported, as long as the OS remained modular and the init sytem could be swapped out by the users. What would be dangerous would be for a monolithic blog to appear between the kernel and user space and start swallowing key system functions. Even worse would be for that monolith to be full of half-baked code and inept designs.

    The automatic supervision of processes and restarting them in the event of a failure may not be a good idea. I read an interesting, public e-mail from a top developer once who pointed out that from a developer perspective, automatically restarting is bad because from it reduces the presssure to hunt down and repair what caused the failure. Odds are whatever caused the failure can be turned into a security exploit eventually. However, that attitude works best where the users are the developers and in other situations when the users are too far from the developers or vice versa then you have problems. And when the problems get ignored they turn into security problems.

    --
    Money is not free speech. Elections should not be auctions.