Excitement and opportunity for the future of FBSD

[malco_2001]

i a agree alot. Just freebsd and then you install a package ghost-bsd-ify it. Or any other derivative.
Don't know why derivatives want to change everything.

When I made FuryBSD to a short time after PCBSD ended it was exactly the opposite. Stock FreeBSD. The problems were lack of automatic graphics detection for certain setups. The nvidia drivers or maybe it was Intel drm kmod breaking when 13.1 would release because the packages were still built for 13.0. That problem was kind of resolved recently with kmods repo I think. There were problems with package availability for desktop related packages as well that were breaking often in quarterly and I didn’t have the hardware to build ports, hold good package sets back and rehost them.

I felt it was better just to contribute the livecd work that I came up with to GhostBSD. Which originally had unionfs for read write live media that was unstable. For FuryBSD I came up with a solution that used ZFS to replicate a compressed file system into memory.

Package availability issues again I ran into the other day I tried to install obs from quarterlies and couldn’t. A month or so before that I couldn’t get chromium that I needed for testing something. GhostBSD for example will hold packages back until more desktop related packages and GUI apps people commonly use all build.

I don’t try to solve these problems anymore for people that GhostBSD does. I wouldn’t have had the money for the server hardware to build ports all the time and host package mirrors to keep “good” desktop package sets published. These are things downstreams like GhostBSD try to solve because FreeBSD has not yet in some of the cases but sounds like 15.1 will fix a few more things.

 

[malco_2001]

Another thing is 15.0 does not support my Realtek 2.5gb Ethernet. So everytime I reinstall stock freebsd I have to use a usb dongle, get the drivers, set up loader.conf to use them. These are things the ghostbsd project just sees and tries to automate nicely. Maybe it’s also that the barrier to contribution is much lower with a smaller team. I also wouldn’t consider freebsd-src as easy to work on as ghostbsd-build.

 

[drhowarddrfine]

The fact FreeBSD 15 has X and KDE on the install image probably means that I will never upgrade to it, and switch away from FreeBSD when 14.X goes EoL.

Don't most other OS installs include the same things? And isn't installing them optional? I don't see the issue.
I agree with everyone that FreeBSD should continue to be held to a high technical standard and not be held down to compliance of corporate interests, the everyman or gamers.

 

[Alain De Vos]

We all now wayland & nvidia don't work. Currently using nested gnome-wayland in xorg.
So there is always choice. But i'm certain kde/plasma will always work fine (maybe not sddm but who cares).
When gnome will enforce systemd that will be another peace of cake.

 

[T-Aoki]

Another thing is 15.0 does not support my Realtek 2.5gb Ethernet. So everytime I reinstall stock freebsd I have to use a usb dongle, get the drivers, set up loader.conf to use them. These are things the ghostbsd project just sees and tries to automate nicely. Maybe it’s also that the barrier to contribution is much lower with a smaller team. I also wouldn’t consider freebsd-src as easy to work on as ghostbsd-build.

Doesn't GhostBSD installing any of (or all of, if not conflicting) net/realtek-re-kmod, net/realtek-re-kmod198 or net/realtek-rge-kmod automatically?

If so, (sorry, not confirmed, though) possibly using *disc1*.iso as installation image would allow installing them from the installation media (DVD-R or memstick).

 

[Alain De Vos]

there was a derivative which had something nice like linux gparted. I didn't needed the derivative, i needed that package

 

[T-Aoki]

We all now wayland & nvidia don't work. Currently using nested gnome-wayland in xorg.
So there is always choice. But i'm certain kde/plasma will always work fine (maybe not sddm but who cares).
When gnome will enforce systemd that will be another peace of cake.

It would depends on the compositor used. And matching graphics/nvidia-drm-*-kmod{-devel} would be mandatory.

I've tried some of Wayland compositor with Japanese input method configured in several patterns suggested I could find here in forums or other sites on stable/14.
Some compositors (at least WayFire, wlmaker) starts fine, but as I couldn't make Japanese input methods working, got back to X11 without further tests. So it can crash after some time I've stop testing, though.
And I've deinstalled them on upgrading to stable/15.

I've installed labwc, but cannot take enough time to try configuring and test yet.

 

[rcbsdpge]

I really like how the Arch Linux ecosystem runs rolling releases.

With that said, I would like to see the ports tree ecosystem establish its own identity in this space as a further complement to FreeBSD base system for robust computing - as it evolves in the long term.

 

[drhowarddrfine]

I would like to see the ports tree ecosystem establish its own identity in this space as a complement to FreeBSD base system for robust computing

??? Doesn't it do that now? I don't understand.

 

[T-Aoki]

Running upgrades: Latest
Rolling release per 3 months: Quarterly

 

[T-Aoki]

So in

• late December through quite early January,
• late March through quite early April,
• late June through quite early July,
• and late September through quite early October

before new quarterly is branched from latest, massive upgrades and fixes for them rushes into latest to be in upcoming new quarterly.

 

[rcbsdpge]

??? Doesn't it do that now? I don't understand.

You can’t mix ports tree and base system without something breaking. That is common knowledge in the FreeBSD community

 

[drhowarddrfine]

That is common knowledge in the FreeBSD community

For something that's common knowledge, this is the first I've heard of it after 22 years in this FreeBSD community and my company used to upgrade everything from ports. So I'm guessing we're not talking the same terminology.

 

[rcbsdpge]

For something that's common knowledge, this is the first I've heard of it after 22 years in this FreeBSD community and my company used to upgrade everything from ports. So I'm guessing we're not talking the same terminology.

maybe your company can optimize the ports tree ecosystem then.

 

[wolffnx]

If the desktop attracts more users to FreeBSD, is fine
but not modify the FreeBSD main line that is servers,make a "flavor" of fbsd oriented to that users and done

what more do you need from FreeBSD now? you have a desktop,you have a good OS, K.I.S.S philosophy
sorry for sound like an asshole but is you want games, go to Windows and if you want the latest "hacker movie" desktop go to Linux

 

[T-Aoki]

Anything installable via ports/pkgs would be the way for FreeBSD, and let distros derived from FreeBSD (like GhostBSD) to install anything optional-on-FreeBSD by default without asking.
To ease these, anything downstream distro wants would better upstreamed and being in official ports tree of FreeBSD.

 

[kpedersen]

One man's "more usable" is another mans "useless clutter that makes upgrades run slower, increases technical risk, and makes configuration more complex".

Absolutely. The foundation has an impossible task:

• Support a good operating system
• Support a popular operating system

These are mutually exclusive properties. The latter helps to ensure funding but then, for what purpose? The niche of a popular, well funded operating system is already taken by Microsoft Windows.

It annoys me that I get forced to install X windows components, which will never be used.

Xorg/Xenocara is a set you can choose not to select during install, but yes, this is still problematic because ports/packages assume libraries like libfreetype2 exist on the system, will install fine but then fail to execute. However I do like that the entirety of the X11 implementation is contained within /usr/X11R6. So even if it is installed, the clutter is encapsulated. It is also vastly smaller than FreeBSD's Xorg (minimal) package. Less modular means its cleaner and i.e uses the system llvm. So its a decent compromise if future PkgBase growths destroy FreeBSD.

 

[drhowarddrfine]

distros derived from FreeBSD (like GhostBSD)

We need to find a non-Linux term for this. Perhaps "derivo" or "derivistro" to show they are derivations and not distributions.
I'm not sure "derivation" is the correct term, either, since they are FreeBSD with pre-defined packages installed and system settings. Perhaps "prepacks" or .... now I forgot.

 

[T-Aoki]

We need to find a non-Linux term for this. Perhaps "derivo" or "derivistro" to show they are derivations and not distributions.
I'm not sure "derivation" is the correct term, either, since they are FreeBSD with pre-defined packages installed and system settings. Perhaps "prepacks" or .... now I forgot.

Yeah, it's really a headache.
Using term "distribution" would confuse existing long-standing users that the term "distribution" is considered something like base.txz.

The term "derivative" could confuse persons working on financial area.

And not widely used terms would confuse both existing users and new comers.

So I'm using the term "distro" knowing it's not so good, but not worst.
This term is used widely to mean Linux "distros", which are the "mixtures" of (exact) Linux (means, kernel), usually GNU libraries, several (or plenty of) apps, (by default or optional) DEs and some original codes.

So calling something like GhostBSD as "distro" would be relatively natural and understandable, as it is (as far as I know) consisted of FreeBSD base, some default components from ports and some original codes.

 

[AlfredoLlaquet]

Inventing terms is kind of easy. Having them catch on is kind of impossible. It happens when it happens. I would suggest "repack" from "repackaging."

 

[Espionage724]

So calling something like GhostBSD as "distro" would be relatively natural and understandable

BSD is different to me like Windows, macOS, and Linux:

• Windows has editions
• macOS has numbers and names
• Linux (I suppose interjecting the main kernel part ) has distributions shipping that kernel to users
• FreeBSD is FreeBSD
• No mainstream BSD (afaik) offers the direct same as another (OpenBSD isn't NetBSD, DragonflyBSD isn't FreeBSD)
• GhostBSD is different enough to not be FreeBSD and targets a largely different userbase (I'd run GhostBSD desktop, but wouldn't consider it server; that's what FreeBSD's for )

 

[Espionage724]

Inventing terms is kind of easy. Having them catch on is kind of impossible. It happens when it happens. I would suggest "repack" from "repackaging."

Heh, I can't come up with a name for how I write game server notes

Like for a WoW server; when others provide a pre-compiled binary it's usually referred to a "repack". I wasn't a fan of repacks like that (usually no source/detailed changelog, upstream code changes break old repacks; felt proprietary), so I write the scripting to do the server config with upstream tools/code no-branding; not quite the same as a repack, but not sure what to really call that beyond "not a repack" (maybe DIY, but I already did it )

 

[cracauer@]

I really like how the Arch Linux ecosystem runs rolling releases.

Speaking of Arch: how does Arch avoid the problem we have with occasional build fallout and some packages becoming temporarily unavailable due to dependency breakage.

I understand how Debian does it, but Arch seems to do what FreeBSD does, but with less (no?) fallout.

 

[T-Aoki]

GhostBSD is different enough to not be FreeBSD and targets a largely different userbase (I'd run GhostBSD desktop, but wouldn't consider it server; that's what FreeBSD's for )

Within your examples, GhostBSD alone is different.
If I understand correctly, it is basically FreeBSD, with original installer that installs GUI components via bundled pkgs, some original and additional ports, and possibly some modified default configurations like PC-BSD did before.

Yes, GhostBSD has its own ports tree, but it seems to rebasing from time to time with upstream FreeBSD ports.
If GhostBSD is completely different OS, it wouldn't be needed or worse, harmful, as any ports affected by GhostBSD changes would be broken unless port maintainer intentionally conditionalize purely for GhostBSD.
And read this. It a bit old, but describes how GhostBSD was/is maintained.

 

[PCUser]

I'm not sure courting end users should be the goal. Look at what Gnome, Wayland, and even newer Firefox versions are doing.

But you're forgetting what I mentioned in my post. The Linux world is fragmented, they all want their own thing yet have to rely on each other and GNU and other components. FreeBSD is one and will maintain one vision and philosophy that it has already had for so long.

So funny people in here arguing to keep people out when that's the opposite of what the Foundation is trying to do.

Precisely. Keeping users out is a fallacy. Seeing its userbase grow (and seeing its brand grow too!) is only good for everyone.

I am friends with Eric from GhostBSD. Gershwin is a separate project with now Probono (Simon Peter) the author of app image and myself. Now we have another new contributor who is ramping up quickly and others offering to help. As soon as things stabilize from all the improvement's to move to all native components we hope to push updates to GhostBSD.

I used to work for the company that sponsored PCBSD, FreeNAS as well which seems like an eternity ago. I think it’s everyone’s dream to do this kind of work or just in general something they love doing as the day job. I appreciate the thought.

That's great to hear! Gershwin is so exciting. It's like taking the old NeXT (or WM) and putting modern Mac on top of it, a very fresh take on desktops and it funnily fits *BSD so well because of the Unix links. Can't wait to see it complete and stable! Honestly I'm getting a bit sick seeing KDE Plasma and Cinnamon just trying to be a copy of Microsoft Windows, they lack originality. But Gershwin looks to be something that could potentially be perfect.

You know what? Turning Gershwin into a "default" DE for GhostBSD (or future FreeBSD express if it will ever merge as I wish) would be great. It will certainly give it its own unique identity, a bit like how Cinnamon is to Linux Mint, or how Ubuntu has that trademark orange-purple color and look that everyone in the FOSS world recognizes.

If the desktop attracts more users to FreeBSD, is fine
but not modify the FreeBSD main line that is servers,make a "flavor" of fbsd oriented to that users and done

what more do you need from FreeBSD now? you have a desktop,you have a good OS, K.I.S.S philosophy
sorry for sound like an asshole but is you want games, go to Windows and if you want the latest "hacker movie" desktop go to Linux

This is exactly my point. FreeBSD doesn't need any modification or change, it's already so great for desktop and has none of the disadvantages of Linux. That's why I say it should attract itself further to that sector by making the entry-point installation easier. FBSD is a complete OS and the Foundation maintains the same philosophy, so there should be no fear of any change to existing server-oriented users.