# FreeBSD derivatives



## Alain De Vos (Feb 6, 2022)

Instead of creating FreeBSD derivatives would it not be better to make a ports which changes your FreeBSD into that specific "flavor".
There are many advantages in doing so.
You could go back to FreeBSD by just de-installing that port.
You could go to another FreeBSD-flavor by installing that other port.
Note : Derivatives use the same kernel and mostly only change the "desktop or user interface experience" and a few configuration files.


----------



## Ole (Feb 6, 2022)

I think the ideal solution would be to not 'instead', but 'together'  For example, I created a port for ClonOS ( not commited yet into official: beta ). BUT having a distribution is user-oriented step: as it simplifies installation, configuration, and therefore the first acquaintance of the user. Especially when user is not familiar with FreeBSD. But besides ClonOS, I would also like to see these meta ports: *ghostbsd, opnsense, pfsense, truenas, nas4free, helloSystem, airyxOS, .. *


----------



## chrbr (Feb 6, 2022)

In my opinion the situation is fine as it is now. Let the creators and maintainers of the derivates use FreeBSD as the basis and add what their community likes. One should not underestimate the effort of doing this kind of work. If the a user of the derivates want to try FreeBSD it is perfectly fine. If not let them have the derivate based on the rock solid FreeBSD. There are many user how are not interested in the details of an OS but use computers just as a tool. Why not? This is the purpose of those boxes. It is good that there are so many options for different levels of interest and topics.


----------



## drhowarddrfine (Feb 6, 2022)

Alain De Vos Ok. You choose. Make everyone happy. Choose wisely. Don't be wrong.


----------



## Alain De Vos (Feb 6, 2022)

I just use plain/vanilla FreeBSD. But sometimes i go looking into hardenedbsd and then i try to configure some options alike.
Sometimes i go looking into other derivatives to see which are the insteresting applications even fonts they use as default and this gives me ideas for my setup.


----------



## drhowarddrfine (Feb 6, 2022)

Alain De Vos Which goes to show what a run around creating such a package would be.


----------



## Beastie7 (Feb 6, 2022)

I'm sure this can either be scripted or built via a metaport. Network appliances (_TrueNAS, OPNSense, etc_) are specialized with webGUI's and whatnot. Trying to automate that versus just shipping a binary would be a royal pain. Unless you like pain, then go for it.


----------



## grahamperrin@ (Feb 6, 2022)

chrbr said:


> … One should not underestimate the effort of doing this kind of work. …



+1


----------



## bakul (Feb 6, 2022)

Many years ago I had wondered about turning even most of the base FreeBSD into packages. Then you can have super-packages for various "flavors" that bundle a bunch of packages, depending on their primary function.

Later I had the idea of treating the local filesystem as a versioned cache with only enough initial bits to set things up for this to work. So the first time you run a program, it is fetched from the backend and cached locally. Security patches would be fetched automatically as the  cache of an insecure program would be invalidated by the security update! Even a release update (or rollback) would be almost instantaneous. You can define a "personality" or flavor to prefetch things of interest for that particular personality (e.g. kernel developer, game player, port developer, curmudgeon, newbie, student, mentor etc.). I never did this of course (our company focus was elsewhere). But I think the idea is worth exploring.

Clearly you need a way to trust the backend you choose + verify its identity. And clearly you need to keep your own files separate from such a backend. And you would need some way to prove the "provenance" of standard programs -- this need exists even today, we just ignore it.


----------



## grahamperrin@ (Feb 6, 2022)

bakul said:


> Many years ago I had wondered about turning even most of the base FreeBSD into packages. …



(You're aware of PkgBase, yes?)


----------



## bakul (Feb 6, 2022)

grahamperrin said:


> (You're aware of PkgBase, yes?)


It didn't exist back then. Even now this is not quite ready.

Here is one message I found (there may have been earlier ones): https://www.mail-archive.com/freebsd-current@freebsd.org/msg134965.html


----------



## Deleted member 67862 (Feb 12, 2022)

Alain De Vos said:


> Instead of creating FreeBSD derivatives would it not be better to make a ports which changes your FreeBSD into that specific "flavor".
> There are many advantages in doing so.
> You could go back to FreeBSD by just de-installing that port.
> You could go to another FreeBSD-flavor by installing that other port.
> Note : Derivatives use the same kernel and mostly only change the "desktop or user interface experience" and a few configuration files.


Much better idea than these derivatives like GhostBSD. They pretend FreeBSD is like Linux distros, when in reality it is a single operating system that requires much more to be a derivative (take DragonflyBSD for example) than just adding some interface of your choice on top of it. There is no reason to not just use FreeBSD with sysutils/desktop-installer.


----------



## Alain De Vos (Feb 15, 2022)

I would like to know beforehand which files sysutils/desktop-installer will modify ? Is this possible ?


----------



## eternal_noob (Feb 15, 2022)

By looking at the source?








						GitHub - outpaddling/desktop-installer: Quickly configure a FreeBSD desktop system
					

Quickly configure a FreeBSD desktop system. Contribute to outpaddling/desktop-installer development by creating an account on GitHub.




					github.com


----------



## grahamperrin@ (Feb 15, 2022)

Alain De Vos said:


> I would like to know beforehand which files sysutils/desktop-installer will modify ? Is this possible ?



Not easily, although from what I recall there's thoughtful, careful logging.


----------



## skunk (Feb 22, 2022)

hunter0one said:


> There is no reason to not just use FreeBSD with sysutils/desktop-installer.


Or, use the Skunk Installer for FreeBSD.
This is a completely different installer, intended to bootstrap SkunkOS onto computers.

It starts where the "bsdinstall" FreeBSD installer, sadly, leaves off.
It keeps the look and feel of bsdinstall, updates the system, then autodetects and autoconfigures your hardware for Xorg and working suspend/resume, installs and configures desktops and applications of your choice, and finally starts up X, ready-to-use.



Alain De Vos said:


> I would like to know beforehand which files sysutils/desktop-installer will modify ? Is this possible ?


Like with Jasons' desktop-installer, just look at the source.
The Skunk Installer is written in Perl, not in sh. Thus it is much easier to modify configuration files.

In short:
It just does the necessary modifications in system files. It creates a xorg.conf tailored to your hardware, and dispatches all the postwork fiddling mentioned in the pkg messages.

You know: The user needs a really-ready-to-use system. Requiring her/him to do manual postconfiguration is not acceptable.
So I suspect the Skunk Installer pokes around even more in these files...

You could try out the Skunk Installer in a throw-away virtual machine before deciding whether to use it on bare metal.



grahamperrin said:


> Not easily, although from what I recall there's thoughtful, careful logging.


The Skunk Installer log is found in /var/log/bootie.log. It is not yet perfect. In some places it could be a bit more verbose, in others a little bit less. But this and other details will be better fine-tuned with the next alpha release 0.0.5.

BTW, the Skunk Cloner, which makes cloning FreeBSD systems really easy, is starting its internal test phase. First alpha will be released soon.


----------

