FreeBSD Foundation Flounders on 15 with Rust, pkgbase, and KDE

Would boot environments work in that case? I ask that because I remember when I did a rm -r / and just put the install CD back in (I haven't messed up my system like that in a while, but I can defiantly appreciate the thought :) !!).
The type of person to create boot enviromenys every 3 seconds isn't the type of person to uninstall all packages by accident.
 
Would boot environments work in that case? I ask that because I remember when I did a rm -r / and just put the install CD back in (I haven't messed up my system like that in a while, but I can defiantly appreciate the thought :) !!).

That's not sportish.

Repairing using backup type methods (to which BEs belong) just doesn't give the same satisfaction as weaseling yourself out of trouble.
 
The type of person to create boot enviromenys every 3 seconds isn't the type of person to uninstall all packages by accident.
Sorry, but this makes no sense. I've been using BEs for a long time, and freebsd-update creates a new one when you do "install", I manually create one when I am updating across releases (12.x to 13.x etc) or when I'm doing a quarterly package update.

Where are you getting "...create boot enviromenys every 3 seconds..."? If one has a cron job doing that I'd be questioning their sanity.
 
That's not sportish.

Repairing using backup type methods (to which BEs belong) just doesn't give the same satisfaction as weaseling yourself out of trouble.
lol!

I was brand new. I can still remember how hard my heart was thumping. I just started seeing my old/little pen II machine's terminal scream past. "Wait! this seems like it's deleting a lot more files than two!! ..."/usr/local" ??!?! Oh no!!!" At this time, I had zero skills, so I just put the CD back in the tray and was very happy to know that my system and files were all saved.
 
Wait! Why would you create a boot environment for any time frame? Wouldn't you just do it when you do some sort of system update? ...you're loosing me here with this non "KISS stuff".
 
  • Like
Reactions: mer
so, what's the problem if your system gets borked by freebsd-update or pkg? same difference; BE to the rescue! "Look ma, no hands!"

EDIT:
I'm making the assumption that if either (freebsd-update or pkg) works, then there is no issue as to which tool is used.
 
It's hyperbole for "boot enviroment every half hour for no reason".
Ahh, I've never known anyone to do that. Snapshots of user datasets? Sure, but BE's? That would be like "I'm going to update my Windows machine every half hour".
Wait! Why would you create a boot environment for any time frame? Wouldn't you just do it when you do some sort of system update? ...you're loosing me here with this non "KISS stuff".
My feeling exactly. New BE when you freebsd-update install and maybe quarterly pkg upgrade -f just in case something didn't build.
 
I am not a troll, I just am a bit ideological. Maybe I am overreacting, I just am afraid that my one refuge from Linux is slowly becoming Linux. As Mon Mothma said: "The monster will come for us all soon enough" ;)
Importing drivers and even Rust to compile them won't convert FreeBSD into Linux.

The big difference between Linux and *BSD is that the Linux API is a playground of all kinds of disparate ideas. Some make sense and some don't. We can pick the ones that make sense and discard the rest. It's called leapfrogging.
 
I found this on the official 15.0 release notes. This is a nightmare. It seems like, to compete with Linux, the Foundation wants to turn BSD into Linux. I hate the idea of pkgbase being the only way to update FreeBSD. That is the main reason why I fled the Linux world. Furthermore, the KDE integration is also so Linuxy. I also hate the push for rust and zig and whatever is the new fad. FreeBSD is abandoning its UNIX roots to chase trends and imitate Linux. I probably will not end up switching to OpenBSD (atleast for the forseeable future), but this new route is concerning, to say the least.
I don't see the difference between freebsd-update and pkgbase. They're both binary updates. To the end user it's all the same.

If you're a developer or keen user, you can always do buldworld/buildkernel/installworld/installkernel. You can even build your own packages, which I've been meaning to do here. If you want legacy style system management you should be building from source. Again, it's all the same.
 
As for pkgbase, it makes sense to package certain applications within certain categories. The entire compiling tool chain can be packaged; each additional firewall aside from IPFW can be packaged; cleartext network applications can be packaged; GPIO, games and Floppy can be packaged. LibreSSL and OpenSSL could be packaged, for those who have the ability to choose. Perhaps what's in contrib can be packaged. Outside of things which don't carry much outside dependencies, it doesn't make sense to package the rest of FreeBSD's base system. It's just work and complexity for little in return.

Packaging within base to a limited extent can help with replacing goals in base. For instance, toolchain components with a completely permissive license can replace GPL components without waiting for each FreeBSD release. Those who want to install LibreSSL and don't need OpenSSL can choose one or both. GPIO is needed for circuit boards or such like projects. Additional firewalls can be chosen from, and perhaps more can be added from other BSD's. Pkgbase can allow a choice of which version of PF to install, to install NetBSD's or DragonflyBSD's firewall. Cleartext networking applications can be chosen to be not installed. Video drivers can be packaged, so those with the newest cards don't have to wait for the next release. Done correctly, the install image can fit on a CD again. Pkgbase would be better standardized than ports and be part of the extended base system.

As for KDE in the installer, I'm not a fan of it. KDE at one time tried to be more permissive than GPL, but it stuck with GPL. It makes sense that KDE has internationalization and accessibility for the impaired, so that could be why it was wanted in an installer. For an installer, KDE seems too heavy. As long as there's always an option for the text-based installer. My desktop is lightweight: I use a combination of mcwm, ittywm and fswm.

As for Rust or Zig, what goes in base needs to be within the C family, and must be able to replace C++ compiling in base, if it means replacing all C++ components. As good as Rust is, since it's not in the C family, it needs to stay in ports. (Zig is in the C family.)
 
Last edited:
Would boot environments work in that case? I ask that because I remember when I did a rm -r / and just put the install CD back in (I haven't messed up my system like that in a while, but I can defiantly appreciate the thought :) !!).
Solaris uses packages and boot environments. They're not mutually exclusive.

And boot environments came about a few years after I had switched careers from IBM mainframe to UNIX. I like to think that my constant harping to anyone at Sun had something to do with it. Though we all know most definitely not.

I did implement boot environments by hand on Solaris and Tru64 simply by copying disks (dump | restore) then apply Solaris or Tru64 patches in a chroot. Reboot and set the new boot device at the prompt.

Before Solaris implemented boot environments using ZFS they used Online Disksuite for UFS boot environments.

Boot environments and ZFS are not the same thing.
 
Back
Top