FreeBSD development seems lost

[CeXP1917]

My experience with freebsd-update is that it is indeterministic & lame, takes hours and one can end with a broken system.

Strange. "Hours" I saw only one time -- when ZFS ARC was too small.
Usually f-u works fast.

 

[kpedersen]

By now I think most of the fuss about pkgbase is a storm in a teacup.

I disagree looking forward. They haven't started "picking" at the base packages yet. The firewalls, nvi, csh, etc will almost certainly be pulled out of base within half a decade. Perhaps zsh will be added instead because "thats cool currently".

You are basically going to be left with a teacup, but the storm inside is going to be replaced by a scoop of random soil, sand and dust from the back garden. Each time you want to fill the teacup, its going to be a different mix.

I would have more confidence if I had seen any Linux distro with this package mechanism with a consistent base. But I haven't. Not even Alpine with 10 default packages.

My experience with freebsd-update is that it is indeterministic & lame, takes hours and one can end with a broken system.
I upgraded debian many times, really good experience, works without troubles and is not an endless process.

Debian's install is completely random. Their minimal, standard package selections change by around 2% of their packages every release. Its not really about being a pleasant experience, its about what you are left with at the end.

 

[cracauer@]

So we have 6 pages of fear and loathing by now and the only real thing that is reflected in code that was brought up is pkgbase.

 

[MrBSD]

So we have 6 pages of fear and loathing by now and the only real thing that is reflected in code that was brought up is pkgbase.

And we also have users bashing freebsd and praising debian. What are they doing on freebsd forums ?

 

[sidetone]

From one retro enthusiast to another, I think dropping i386 is a crime.

i386 needs to go, and be replaced by 32bit ARM, and Risc. Also, let NetBSD have i386 for legacy purposes. 32bit, needs to be for simpler operating systems like Haiku, RiscOS, PDOS etc... ARM and Risc are better for 32bit computing, than i386. I read that i386 has kept backward compatibility for 286, 386 and 486 which made it not as efficient. So ARM and Risc could run on smaller hardware.

And to that end, I'm certain that MBR will be on the chopping block soon.

I wish there were an MBR version 2, which had 8 or 16 partitions, instead of 4. I don't like the idea of how upgradeable UEFI is. MBR was set into the hardware.

I think that the rust-in-base

I also wish claims of Rust in base would stop being brought up. Rust has its place, and they settled it, that it's not going into base. FreeBSD does need a C compatible safer language for base, but I believe it's not Rust. Also, there's nothing wrong with Rust in ports. If you want Rust in base, use RedoxOS, and use C for the userland.

 

[vmisev]

So we have 6 pages of fear and loathing by now ...

Suddenly, there was a terrible roar all around us, and the sky was full of what looked like huge bats, all swooping and screeching and diving around ...

 

[drhowarddrfine]

OMG! Scared myself. I thought I accidentally clicked on a Reddit link!!

 

[Starcat]

It's almost like end users shouldn't have any negative opinions. I get it in the sense that negativity doesn't breed anything positive or productive, however, when your system works great under 14.1, suddenly things break and/or are buggy in 14.3 and 15.0 arbitrarily drops support for your peripherals; it pisses you off.

And while I don't agree with every gripe, I wholeheartedly agree with the title of this thread. QA practices need to be improved. Introducing bugs and breaking basic installer functionality in a minor release is unacceptable in my opinion.

 

[Crivens]

I disagree looking forward. They haven't started "picking" at the base packages yet. The firewalls, nvi, csh, etc will almost certainly be pulled out of base within half a decade. Perhaps zsh will be added instead because "thats cool currently".

As long as it is that pkgbase packages are build from /use/src it is only a question of how that is sliced. Pulling in stuff from /use/ports into base, now that is what Linux is doing and getting into hot water with. And I have seen enough Linux systems being restored from snapshots after an upgrade, that is not what I would want to see here.

 

[hruodr]

The firewalls, nvi, csh, etc will almost certainly be pulled out of base within half a decade.

Tragic.

Perhaps a metaport "classicbsd" with all that programs and the games will be necessary.

Another called "mitxclients" is necessary already now.

 

[gotnull]

Actually FFS is solid as hell. It is slower though but for my use-case (I am not an enterprise), it is easily good enough.

vmm and chroot are also good enough for me. I only allocate one core to my VMs anyway and my use of a jail is mainly building software / administrative rather than security, so chroot will suffice.

For me personally, OpenBSD is an easy compromise.

Thank you for the feedback, it's an interesting point of view.
I might dig a bit on this, not that I have a desire to leave FreeBSD but just because I like how this project handle things, small team with a specific vision.
It's good to look at what others can do/offer, it gives ideas and overall it makes us progress in the right direction, I think.

 

[hruodr]

Strange. "Hours" I saw only one time -- when ZFS ARC was too small.
Usually f-u works fast.

Perhaps that is the reason. I have 'only' 4GB in my Desktop. Perhaps I upgrade to 8 GB.

The other solution is to install FreeBSD with UFS if I decide to work with FreeBSD 15 and when I do it.

For A NAS I will need ZFS, or perhaps Hammer 2 ?

 

[blackhole]

freebsd-update concerns me and I may look elsewhere. It was time it be deprecated.

Being an advocate of the clear separation of base and ports tree does not equate to being an advocate of freebsd-update - please educate yourself...