FreeBSD 15 probably will include KDE as DE installtion option

[kpedersen]

why not? the listing of the iso's in the download area for the images makes a pretty strong case for yes.

Nope. The userlands and installers are not customized. The multiple aarch64 images are simply different uboot (first section of bytes). You could actually get a generic image, dd a different uboot and recreate any of them.

I think the only exception is RPI where it has accrued some clutter compared to other builds.

Besides, userland and installer kind of have to be compiled for specific architectures. You can't just rip /bin/ls out of an amd64-tagged image and stick it into an arm64-tagged image...

Yep, which is why I was careful to state in my previous post "Other than architecture, the userland and installer is identical"

 

[astyle]

Yep, which is why I was careful to state in my previous post "Other than architecture, the userland and installer is identical"

Yeah, well, it's still identical implementations on different architectures. As in, /bin/ls is supposed to work exactly the same on both little-endian arches and big-endian arches. But thanks to the fact that it's two different architectures, you have to write two different implementations. I'd say that is customization.

You can customize a bicycle to no end, and still end up with something on two wheels that rolls like any other bicycle.

You could actually get a generic image, dd a different uboot and recreate any of them.

Not really, I think it's more work than that. There's kind of a reason why Loongson ports took so long to get to mainstream. Why do you think writing a cross-compiler is one of the first things to do when developing a new architecture? it's so that the very basic userland can be implemented.

 

[kpedersen]

Yeah, well, it's still identical implementations on different architectures. As in, /bin/ls is supposed to work exactly the same on both little-endian arches and big-endian arches. But thanks to the fact that it's two different architectures, you have to write two different implementations. I'd say that is customization.

No, you don't write two different implementations. The C compiler does the platform specific endian work, or at the very least you #ifdef out small platform specific parts of the code.

Not really, I think it's more work than that. There's kind of a reason why Loongson ports took so long to get to mainstream. Why do you think writing a cross-compiler is one of the first things to do when developing a new architecture? it's so that the very basic userland can be implemented.

Nope. There really isn't. Check out the example here for a typical process for an ARM board to "make a custom image".

As per my previous post;

"The multiple aarch64 images are simply different uboot (first section of bytes). You could actually get a generic image, dd a different uboot and recreate any of them."

Loongson is not aarch64. You can't just dd an aarch64 bootloader onto it and expect it to work. For reference, for my big collection of old arm7 boards (i.e beaglebone, pcduino, etc), this is the generic image I use.

Check out the difference between the many aarch64 images, you will see the only difference is the bootloader. I don't believe other than the RPI ones they even change the kernel / drivers.

 

[nxjoseph]

I don't want to sound rude and/or mean but I want to mind you again that this thread is about the title and you are discussing about some architectures. I'd like to see more people talking about the topic rather than that. I am not a moderator or something but just sayin'.

 

[angry_vincent]

The reason is that KDE/Plasma has a good ports team and it is best supported among all other DE's, comparatively. So it is not a surprise for me at all. And is good.

 

[kpedersen]

I don't want to sound rude and/or mean but I want to mind you again that this thread is about the title and you are discussing about some architectures. I'd like to see more people talking about the topic rather than that. I am not a moderator or something but just sayin'.

Yep you are right. I think the project needs to remain mindful of bloating out the installation images, but probably going into depth of how they are created per architecture is out-of-scope of this discussion.

If they just mash the PkgBase packages together with the KDE cruft; this is going to be grim.

 

[nxjoseph]

Yep you are right. I think the project needs to remain mindful of bloating out the images, but probably going into depth of how they are created per architecture is out-of-scope of this discussion.

Thanks, you've explained it better than me!

 

[astyle]

Yeah, we did go into a rabbit hole here...

Because after all, for any given architecture, you can have many editions, each with identical installers that have further options that can be enabled/disabled.

Mixing and matching components between architectures - that is more work than kpedersen seems to say. When the architecture is the same, then yeah, the installer can be the same, and offer options. Basic userland can actually be a no-brainer, and be the same - but only within the same architecture.

 

[RetroComputingCollector]

With PKGbase and now KDE, it feels like they are trying to Linuxize BSD. If they ever get rid of non-pkgbase installs, I will switch to OpenBSD. Hopefully they never do that. Ever.

 

[nxjoseph]

With PKGbase and now KDE, it feels like they are trying to Linuxize BSD. If they ever get rid of non-pkgbase installs, I will switch to OpenBSD. Hopefully they never do that. Ever.

I agree with you on the "linuxize bsd", I wouldn't want to see, at least, FreeBSD, to get "linuxized" either. I wonder if something that happens, I think someone can show up and keep maintaining "old" freebsd, right? So we can keep using "non-linuxized" freebsd.

 

[RetroComputingCollector]

I agreed with you on the "linuxize bsd", I wouldn't want to see, at least, FreeBSD gets "linuxized" either. I wonder if something that happens, I think someone can show up and keep maintaining old" freebsd, right?

That would be hard work, but I hope someone would do it.

 

[kpedersen]

that is more work than kpedersen seems to say. When the architecture is the same, then yeah, the installer can be the same, and offer options. Basic userland can actually be a no-brainer, and be the same - but only within the same architecture.

I think I have stated "same architecture" more than enough times. You need to learn to read astyle. Lets go through them shall we XD:

Other than architecture, the userland and installer is identical

(Even re-iterated for you)

Yep, which is why I was careful to state in my previous post "Other than architecture, the userland and installer is identical"

Loongson is not aarch64. You can't just dd an aarch64 bootloader onto it and expect it to work.

But what I believe you might still not have understood (and leading back to this thread), is that we don't provide a custom image for i.e amd64 containing i.e ssh enabled by default; and then aarch64 image with it disabled by default. In terms of release engineering, our images are generic in terms of a standard base. So what you were implying as a suggestion in your Post #45 is no good.

The outlier is RPI because someone wanted powerd enabled by default (for some reason they couldn't be bothered to set it themselves). And now, the images will have whatever cruft KDE requires on some platforms at whatever snapshot and state the port is currently in that release (today it will have 300 dependencies, tomorrow it will have 299, and the day after 306).

 

[kpedersen]

Other than architecture, the userland and installer is identical

You may not know this but bsdinstall is not a compiled binary. It is a (combined) shell script. So it is identical; even across architectures.

 

[mer]

I'm not advocating for either approach here, just opinionating and thinking out loud.

pkgbase vs current. What's the real difference?
My understanding pkgbase is giving granularity on things that make up kernel and userland. Is that incorrect?
So right now, with freebsd-update, you have a monolithic update for just a driver, just a single service like ssh.
How many threads here are "I updated to latest but freebsd-version -kru doesn't show what I think it should"

so with pkgbase, it seems like one could simply update a package that contains ssh instead of pulling in patches for other things.

If pkgbase is always treated as "kernel plus userland, just split into lots of smaller pieces" to me it's neutral. I don't look at it as trying to linuxize FreeBSD, I look at it as a path to maybe addressing CVEs quicker.

 

[RetroComputingCollector]

I'm not advocating for either approach here, just opinionating and thinking out loud.

pkgbase vs current. What's the real difference?
My understanding pkgbase is giving granularity on things that make up kernel and userland. Is that incorrect?
So right now, with freebsd-update, you have a monolithic update for just a driver, just a single service like ssh.
How many threads here are "I updated to latest but freebsd-version -kru doesn't show what I think it should"

so with pkgbase, it seems like one could simply update a package that contains ssh instead of pulling in patches for other things.

If pkgbase is always treated as "kernel plus userland, just split into lots of smaller pieces" to me it's neutral. I don't look at it as trying to linuxize FreeBSD, I look at it as a path to maybe addressing CVEs quicker.

I think that having both would be fine. If you can pick freebsd-update or pkgbase, I would be happy. If freebsd-update gets neglected or deprecated, I will be VERY angry.

 

[kpedersen]

pkgbase vs current. What's the real difference?

(Apologies to nxjoseph again for taking this thread towards PkgBase. I will stop after this, I promise!)

In theory, no difference. Just rather than a big .tar.gz, we have lots of little .tar.gz. But what PkgBase offers is flexibility to mix and match newer packages from base. Sounds good right? Which is why some are advocating for it.

However in practice it opens us up potential for:

1) Including more stuff into base (perhaps a few different text editors, some perl, python?) because why not? Its all just packages anyway right!
2) What we have seen with the LinuxKPI stuff is constant breakage. Imagine this for every package in base.
3) Now that i.e awk is a package; lets remove it and go ultra light DIY. Save on space! (and break a shed-load of existing scripts, expecting a proper "complete" UNIX user-land).

The fact that zero Linux distributions have a consistent base should be enough evidence that it simply cannot be done if you split everything up into micro-packages and micro-dependencies. And this is why others, are *not* advocating for it.

 

[RetroComputingCollector]

The fact that zero Linux distributions have a consistent base

Zero linux distros (that I know of) even have a base. It's all packages!

 

[nxjoseph]

(Apologies to nxjoseph again for taking this thread towards PkgBase. I will stop after this, I promise!)

Maybe pkgbase would be another thing that FreeBSD 15 will bring, so I think that's not out of scope here.

You've very good explained some things about pkgbase, disadvantages and whatnot, and I agree with you too. Thanks!

 

[scottro]

Looking at this thread, I am reminded of numerous It's Always Sunny in Philadelphia episodes, where they start discussing one thing, and then wind up in an argument about something completely different. Which, on the TV show, is often funny.

 

[baaz]

(Apologies to nxjoseph again for taking this thread towards PkgBase. I will stop after this, I promise!)

In theory, no difference. Just rather than a big .tar.gz, we have lots of little .tar.gz. But what PkgBase offers is flexibility to mix and match newer packages from base. Sounds good right? Which is why some are advocating for it.

However in practice it opens us up potential for:

1) Including more stuff into base (perhaps a few different text editors, some perl, python?) because why not? Its all just packages anyway right!
2) What we have seen with the LinuxKPI stuff is constant breakage. Imagine this for every package in base.
3) Now that i.e awk is a package; lets remove it and go ultra light DIY. Save on space! (and break a shed-load of existing scripts, expecting a proper "complete" UNIX user-land).

The fact that zero Linux distributions have a consistent base should be enough evidence that it simply cannot be done if you split everything up into micro-packages and micro-dependencies. And this is why others, are *not* advocating for it.

I have to add this too:

The intention behind the action of updating my OS and updating software running on my OS are distinct.

I do not want be forced to update my kernel while running a routine pkg upgrade of 3rd party software.
This is top on my list of gripes with Linux. You run your distro's package manager update command and your kernel, your boot-loader and other supper essential parts of your OS get swapped under your feet, and in many cases that causes a unexpected situation that bricks your system the next time you boot it.

This maybe a unusual take, but a package managers job should be just installing packages (i.e 3rd party software not fully essential to the OS). It has no business of messing with the foundation that it itself is running on. It has one job that it needs to do is to manage packages not manage OS updates.

Also there is a non zero count of me having to fully remove every package on a system, and rebuild the pkg databases, because of some weird bugs in it forcing me to install random packages that nothing depended on.
To this day the freebsd-update had never done such things, instead it provides useful info and diffs that are not a package managers job and responsibility.

 

[T-Aoki]

Without doubts, pkg should fix known regressions.

Putting it aside, if freebsd-update remains as the frontend of PkgBase and keeps on doing any jobs that are NOT jobs for pkg, it can be considered to be just a change on backend only.

And making base as packages (PkgBase), we would have not only finer grained controls on installation, but also finer grained updates.
Currently, if a patch releases (i.e., 14.3-Release-p1) is kernel only or userland only, the patchlevel become mis-matched between kernel and userland.
This makes admins confused, "Gah! why my kernel (or userland) is NOT updated?! I've installed updates via freebsd-update!", often seen in this forums.
Using pkg for base could make it saner with this, as pkg version should show each components are up-to-date or not.

About installer, PkgBase would (hopefully) allow installer to handle base and ports "nearly equivalent", so installing selected ports on after installation phase could be easier to (internally) handle, including DEs.
But base pkgs and ports pkgs should be treated slight differently (not sure it's already done or not, though) as of auto-removes. Base pkgs SHALL not be targetted to be auto-remove even if nothing flags dependency upon them. Otherwise actually mandatory base pkg could be accidentally deinstalled.

 

[GlitchyDot]

I hope KDE would be option like you have options, lets say in Debian installer, where you can choose some packages like ssh / web-server / and desktop environments.

I do not want be forced to update my kernel while running a routine pkg upgrade of 3rd party software.

With PKGbase and now KDE, it feels like they are trying to Linuxize BSD. If they ever get rid of non-pkgbase installs, I will switch to OpenBSD. Hopefully they never do that. Ever.

Yeah - this would be a disaster. I love the way i need to update FreeBSD and/or installed packages. I think i still have that Arch Linux OCD to run update every now and then but getting closer to once a month or once a quarter and only packages not a kernel. Damn, my laptop pkg update / upgrade was a while ago and just recently i did pkg update / upgrade option but still run 14.2-RELEASE.

This makes admins confused, "Gah! why my kernel (or userland) is NOT updated?! I've installed updates via freebsd-update!", often seen in this forums.

PkgBase would update Kernel and packages when you update Kernel right ? aka freebsd-update fetch / install and Upgrading Packages After a Major Version Upgrade section combined together ?

 

[astyle]

PkgBase would update Kernel and packages when you update Kernel right ? aka freebsd-update fetch / install and Upgrading Packages After a Major Version Upgrade section combined together ?

PkgBase upgrades only kernel, not packages that are compiled from Ports Collection.

Basically, FreeBSD's base.txz distribution (which is the kernel) is wrapped up into a .pkg format that can be handled by normal pkg commands. If you can package up LibreOffice.zip into a FreeBSD package and add some scripts to install it correctly on FreeBSD, same thing can be done with the FreeBSD kernel - and that's what PkgBase is all about. Pretty convenient, I'd say!

Trouble is - it doesn't solve the issue of needing to run pkg update afterwards.

 

[angry_vincent]

PkgBase upgrades only kernel, not packages that are compiled from Ports Collection.

Basically, FreeBSD's base.txz distribution (which is the kernel) is wrapped up into a .pkg format that can be handled by normal pkg commands. If you can package up LibreOffice.zip into a FreeBSD package and add some scripts to install it correctly on FreeBSD, same thing can be done with the FreeBSD kernel - and that's what PkgBase is all about. Pretty convenient, I'd say!

Trouble is - it doesn't solve the issue of needing to run pkg update afterwards.

It is not that base.txz is wrapped into .pkg. it is subdivided into individual packages, for example:
FreeBSD-pf : 14 [FreeBSD-base]
FreeBSD-lld: 14 [FreeBSD-base] ...etc
Then, it is FreeBSD-base pkg repository formed of such packages that is the "base" in new guise.

 

[T-Aoki]

PkgBase would update Kernel and packages when you update Kernel right ?

IIRC, as astyle already mentioned as below,

PkgBase upgrades only kernel, not packages that are compiled from Ports Collection.

base (including kernel) and ports are not upgraded at once.
IIUC, this would be because pkg need to know what arch / version of base is "running" first for determining package (pkg built from ports) to be upgraded and/or installed. And making upgraded kernel "running" requires restarting whole OS.

And as angry_vincent mentioned, distributions of PkgBase is fine-grained than ones of current installation images.
But as I'm upgrading via src, I myself never tried PkgBase. Just read documents at several points.