Stable vs Stable...

Would you be interested in a Stable (as in Debian) branch where you get only security updates?

  • Not really

    Votes: 12 52.2%

  • It would be interested

    Votes: 3 13.0%

  • I need it

    Votes: 0 0.0%

  • Not again...

    Votes: 8 34.8%
  • Total voters
    23
  • Poll closed .
mer said:
I treat it as more process: Follow RELEASE and Quarterly, but before actually updating either.
Click to expand...
Note that merging to alreay-branched Quarterly basically requires explicit approval of portmgr team, unless the to-be-merged things are covered by alreay existing "blanket approvals" like security fixes.
And also note that some security fixes includes changes that break some others.
 
Seems like the best way is to grab updates for both base and packages in source form, at the same time, and recompile the whole thing from scratch. Base and ports have to be exactly the same age, and be in source form, ready for compilation.

This is the baseline where the upgrade starts. Pre-compiled packages are a deviation from that baseline. When upgrading, you gotta ask yourself how much deviation from that source-only baseline can you get away with before dependency hell starts biting?

That can easily take a few days every time you want an update. And forget upgrading KDE/GNOME, there's still Firefox and drm-kmod.
 
T-Aoki said:
Note that merging to alreay-branched Quarterly basically requires explicit approval of portmgr team, unless the to-be-merged things are covered by alreay existing "blanket approvals" like security fixes.
And also note that some security fixes includes changes that break some others.
Click to expand...
Honestly the Op issue is not unique to FreeBSD. Heck it even happens on Windows; I've had situations where a Windows update broke an application, that was picked up in an application update.
So the bottom line is "an update of anything may break something else" and a user needs to figure out how to mitigate breakage. This is why I like ZFS: create a BE before doing updates, either base or pkgs.
 
mer said:
Heck it even happens on Windows; I've had situations where a Windows update broke an application, that was picked up in an application update.
Click to expand...
Just my observations, but historically, Windows broke things repeatedly to attract "newly comming in" users' attention, ignoring existing users' experiences. And these applies not only user interfaces but also API/ABI and KPI/KBI, breaking apps.

I used to see Microsoft stated "For this new version, we've REWRITTEN * million lines of source codes!".

But if the ground design is good enough, it should be like "We needed to ADD only * hundred lines for this great new feature! We're proud that we did NOT AT ALL needed to rewrite existing codes! Exactly zero lines was needed to change although strict overall code reviews for security!".
Of course, this should be applicable for any softwares. But non-existent or quite rare, unfortunately.

mer said:
So the bottom line is "an update of anything may break something else" and a user needs to figure out how to mitigate breakage. This is why I like ZFS: create a BE before doing updates, either base or pkgs.
Click to expand...
100% agreed! 😁
 
  • Like
Reactions: mer
T-Aoki said:
Just my observations, but historically, Windows broke things repeatedly to attract "newly comming in" users' attention, ignoring existing users' experiences. And these applies not only user interfaces but also API/ABI and KPI/KBI, breaking apps.
Click to expand...
My experience is quite the opposite, you still can run windows binaries written in '90s (given that it's not a win16 program, support for those is no more), sometimes it requires enabling the "compatibility" settings, yes. And it's actually one of the reasons windows installs are so huge and complex, carrying all the stuff from ancient times.

OTOH, it's linux continuously (and deliberately?) breaking its API/ABI, and FreeBSD is somewhere in the middle with all the COMPAT_* options and compat packages.
 
When win11 starts logging me into live.com automatically (and getting my laptop registered in Windows Store), all without my authorization, that's when I decided, "No more, I'm gonna only turn that laptop on if I need to do some scanning ( I have Epson Perfection V19, no intent to buy something else when that one works for the last 20 years and still makes VERY good scans!) or Teams/Zoom or TurboTax, but after I'm done, I actually turn the damn laptop off. Win11 uptime needs to be minimized to the extent practical, I want it down to zero. 👿 :rude::rolleyes:
 
Espionage724 said:
This isn't a thing 24H2 LTSC (unless you want it to be :p)
Click to expand...
Yeah, probably, but I'm beginning to lose motivation to do the research it takes to tell Windows to not take unauthorrized actions. It's not that different from researching CVE's for UNIX. Might as well equate Microsoft Windows 11 with one big security hole. 😩
 
chungs said:
Has anyone here experienced anything breaking due to an update?
I think freebsd's package management system is perfect. It can't really logically break due to the user packages being separated from the system, this way everything is very secure and is always more or less up to date
Click to expand...

Yes, unfortunately quite a bit more than compared to when I used Debian Linux on my desktop systems (before 2016), but that is probably the price one has to pay for getting more recent versions from upstream compared to Debian where users rely on the resource-intensive work of backporting patches. I do use lots of ports, and sometimes it was my own error because some libs or dependencies got removed and following that some programs. Sometimes I just overread that in the list pkg presented to me, sometimes I had to decide that upgrading my browsers was more important than having access to program XY, knowing that it will be fixed in one or two weeks. Some upstream regressions get in, like the libreoffice bug where users could not print PDFs any more. Sometimes signal-desktop just vanished, sometimes one of the browsers. That's one reason why I am all in for getting application level containers in FreeBSD. I currently have 12 jails each with a bundle of ports which I use at work and for my personal stuff. This is much more work to keep up to date than compared to Linux containers. However, it saves me from all the headache when at some update programs get uninstalled, or problems from upstream sneak into the system (I can just rollback to a snapshot on my video-editing jail).

edit: some things to add: I did not answer the poll, I think it would be nice, however, I think the honorable developers should concentrate on more important work. Also, on a side note, using Gentoo Linux which resembles more like a FreeBSD type experience with rolling package releases, the system broke much, much more often than compared to FreeBSD.
 
astyle said:
Very few have NOT experienced anything breaking due to an update. These Forums are full of threads complaining about the dependency hell and drm-kmod being incompatible with the upgraded base.
Click to expand...
Survivorship fallacy. People that don't have issues don't post about it. So there's a selection bias happening here.
 
SirDice said:
Survivorship fallacy. People that don't have issues don't post about it. So there's a selection bias happening here.
Click to expand...
I think that 'Survivorship fallacy' is a pretty weak argument. As a counter-example, the wi-fi (particularly roaming) is a weak spot for FreeBSD, and a well-known one. If the issues were that easy to fix, the RTFM refrain would hold water.

There's kind of a reason why there's not that many threads about "ZFS not working right". Yeah, people who don't have issues with ZFS, don't post about it. True, BUT: they do help people who do have issues with ZFS, and issues actually get resolved, even with the RTFM refrain. This is in stark contrast to wifi or the dependency hell.

It can be pretty difficult to get a manufacturer to acknowledge a defect in the product.
 
astyle said:
I think that 'Survivorship fallacy' is a pretty weak argument. As a counter-example, the wi-fi (particularly roaming) is a weak spot for FreeBSD, and a well-known one. If the issues were that easy to fix, the RTFM refrain would hold water.

There's kind of a reason why there's not that many threads about "ZFS not working right". Yeah, people who don't have issues with ZFS, don't post about it. True, BUT: they do help people who do have issues with ZFS, and issues actually get resolved, even with the RTFM refrain. This is in stark contrast to wifi or the dependency hell.

It can be pretty difficult to get a manufacturer to acknowledge a defect in the product.
Click to expand...

WiFi or DRM-KMOD are problems that go beyond FreeBSD (or any BSD). It's simple: it takes hands to code everything needed for it to work properly. And I mean hands, not words, much less complaints, because that doesn't magically write code. That's leaving aside money, which is also lacking.

I'm affected by DRM-KMOD on FreeBSD 14. I have an RX 580, on which amdgpu, with DRM-515-KMOD and DRM-510-KMOD, behaves explosively, and this is documented (from 14 to 14.2). But my response to this isn't to point fingers at the FreeBSD devs, but rather to find a way to fix the problem. Whether it's filing a good bug report, testing a configuration or patch, or whatever, as long as I'm helping and doing something constructive and real.

I could (for example) get picky and end @jsg's (OpenBSD dev) email because the 6.12 DRM there doesn't work with my Intel Arc, and instead, I'm trying to fix the problem. Same with FreeBSD, where we have DRM-66-KMOD. That doesn't mean I'm attacking the devs.

And yes, RTFM is a common practice, because RTFM is how these things work and the risks. Furthermore, the license makes it clear that:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 
ArgentoSoma said:
WiFi or DRM-KMOD are problems that go beyond FreeBSD (or any BSD). It's simple: it takes hands to code everything needed for it to work properly. And I mean hands, not words, much less complaints, because that doesn't magically write code. That's leaving aside money, which is also lacking.
Click to expand...
It feels more like Wifi being an afterthought; Ethernet subsystem seems fantastic all BSDs.
 
ArgentoSoma said:
WiFi or DRM-KMOD are problems that go beyond FreeBSD (or any BSD). It's simple: it takes hands to code everything needed for it to work properly. And I mean hands, not words, much less complaints, because that doesn't magically write code. That's leaving aside money, which is also lacking.
Click to expand...
Seems like I will need to start a different conversation, rather than hijacking this thread... At least wifi is getting worked on, the FreeBSD Foundation gave it priority for this year. And I do see Wayland gaining steam in spite of GPU support being rather basic on FreeBSD.
 
In the old days, XFree86 drivers had to be compiled for each OS.
Well, that makes sense.
Later, in XFree86 4.0 the driver binaries were made common.
There is no need to compile it for each OS.
At the time I used the Linux binaries I got from ATI.
And now we have to deal with it for each OS.
The good old days.
 
astyle said:
Seems like I will need to start a different conversation, rather than hijacking this thread... At least wifi is getting worked on, the FreeBSD Foundation gave it priority for this year. And I do see Wayland gaining steam in spite of GPU support being rather basic on FreeBSD.
Click to expand...
There's still a long way to go regarding Wayland, especially since some features aren't entirely complete or polished. For example, you can share your screen in Sway, but doing so currently requires a fairly messy level of code—a hack in wlroots—that should be fixed for future versions.

That's in addition to improving dbus and seatd integration, so it's less of a headache, and getting pipewire to work properly on FreeBSD, especially in WM environments.

A good thing would be to rewrite the entire Sway/Wayland section of the HandBook to make these points clear, as well as clarifying the handling of XDG_RUNTIME_DIR and
pam_xdg, which often cause problems when not configured correctly, both in X11 and Wayland.
 
Espionage724 said:
It feels more like Wifi being an afterthought; Ethernet subsystem seems fantastic all BSDs.
Click to expand...
I understand that Wi-Fi is important for many people who carry laptops or simply don't want to have Ethernet cables running through their homes. It's a problem that needs to be solved, and the good news is that it's being addressed.

DRM-KMOD, on the other hand, is a more complex issue. There are engineering decisions behind doing things with LinuxKPI at this point, rather than a more direct approach like OpenBSD does, although from my perspective, that has caused more problems for FreeBSD than anything else.

Currently, we have four separate DRM-KMOD versions (5.10, 5.15, 6.1, and 6.6), two of which have serious issues with AMD GPUs and some Intel iGPUs (5.10 and 5.15). 6.1 is actually working quite well now (it also crashed with AMD GPUs before, in my case), and 6.6, which is currently in progress and is required for, for example, newer graphics cards (e.g., Intel Arc, newer Xe graphics, or Radeon graphics cards higher than the 7000 Series).

And here's a pretty obvious point: 6.6 is far from ideal for FreeBSD 15. The ideal DRM would be 6.12, but I doubt we'll see it until 15.1 or 15.2 arrives, and something tells me the DRM-KMOD problem will only get bigger as more versions of it are added to the maintenance stack across the various supported FreeBSD releases. That's a point worth reviewing, because maintaining that pace of work is exhausting and wastes human resources, which are few.
 
cracauer@ said:
They mention "automatically" too often to make me comfortable with the concept.

Is thingie working?
Click to expand...
If it works, it does its job of allowing the use of Wayland and its various compositors.

The idea behind seatd is to not depend on logind (systemd-logind or derivatives) and to be portable. In a way, it would be a UNIX-like solution to avoid using systemd-related things with Wayland.
 
ArgentoSoma said:
If it works, it does its job of allowing the use of Wayland and its various compositors.

The idea behind seatd is to not depend on logind (systemd-logind or derivatives) and to be portable. In a way, it would be a UNIX-like solution to avoid using systemd-related things with Wayland.
Click to expand...

Does Wayland with seatd allow multiple users with full graphics each to be logged in (via VT switch or so)?
 
cracauer@ said:
Does Wayland with seatd allow multiple users with full graphics each to be logged in (via VT switch or so)?
Click to expand...
I can't say for sure; I haven't tested that.

But since seatd is client-server, it should allow that type of operation. The only thing is that it's as tested as X11 (which I highly doubt).
 
You must log in or register to reply here.
Back
Top