2024: The year of desktop FreeBSD?

[cracauer@]

The vast majority of FreeBSD's ports are from 'random sources'.

No, they aren't. There is a port maintainer looking at what gets pushed to FreeBSD, and most of the time that is not the original author of a given software package. That adds a very important layer to security.

 

[paulw]

That's ok, it's new. You can add scripts, probably best to /usr/local/etc/rc.d/*

Do you (does anyone) know how to view /etc/rc.d/ntpd at:

https://cgit.freebsd.org/src/tree/etc?h=releng/14.0

I can't find any of the usual files in /etc, including rc.d/ ?

I think this is it:

https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ntpd or

https://github.com/freebsd/freebsd-src/blob/releng/14.0/libexec/rc/rc.d/ntpd

Looks to be the same thing as /etc/rc.d/ntpd.

Sorry the first link should have been:

https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ntpd?h=releng/14.0

 

[grahamperrin]

Gentle reminder:

Sleep resume - caveats and gotchas.

Having had some trouble to get my hardware to correctly sleep/resume (and failing a lot at it) I would like this place to collect some strange things which may happen. Model: Lenovo ThinkPad A485, Ryzen5, Vega gfx. Symptom: crash during resume. Reason: BIOS tamper protection triggers at EC...

forums.freebsd.org

 

[bakul]

No, they aren't. There is a port maintainer looking at what gets pushed to FreeBSD, and most of the time that is not the original author of a given software package. That adds a very important layer to security.

Most maintainers are likely not security experts so not much of a security layer. There should be a way to control a port's access to files external to the package....

 

[Beastie7]

Most maintainers are likely not security experts so not much of a security layer. There should be a way to control a port's access to files external to the package....

The point is that third party software is audited and inspected by a trusted user before they are pushed to the tree by port committers. This "compliance" is a layer of security.

 

[smithi]

I think this is it:

https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ntpd or

https://github.com/freebsd/freebsd-src/blob/releng/14.0/libexec/rc/rc.d/ntpd

Looks to be the same thing as /etc/rc.d/ntpd.

Yes; seen from earlier work on bsdconfig, the same thing: sources of text executables are in libexec and are copied to their destination directories on installation.

Sorry the first link should have been:

https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ntpd?h=releng/14.0

Currently releng/14.0 and main are identical for this one.

[ glad cgit.freebsd.org is back! ]

 

[grahamperrin]

… There is a port maintainer looking at what gets pushed to FreeBSD, and most of the time that is not the original author of a given software package. That adds a very important layer to security.

Maintainers sometimes take no action in response to detections by portscout.

portscout - new distfile scanner

There's discouragement from reporting outdated software in these cases.

Not all maintainers are aware of the importance of VuXML entries. security/vuxml and:

VuXML

When multiple sets of release notes apply, there's sometimes a preference to omit notes at commit time. Intentional omissions do not help end users to understand things.

And so on.

 

[smithi]

Sadly I don't think 2024 will be the year of desktop freebsd, at least not for me, because of this:-
https://forums.freebsd.org/threads/intermittant-bug-in-14-0-release-dri-crocus-driver.91824/

which is this bug:-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267915
which I have been told by development is not going to be fixed.

Who is 'development' here?

In a nutshell, the bug is that switching to another VT once the gui is running kills GPU hardware acceleration and forces the system to fall back to an unaccelerated software driver.

Pruning ...

The bug also happens on suspend-resume, at least on my machine. I found after a resume, restarting the X server by logging out and back in was enough to get hardware accel working again. Whereas following a manual VT switch, the only reliable way to get accel working was a full reboot. But maybe I just got lucky with the suspend-resume case.

A pretty solid clue for a cluey developer, one would think.

Assuming you use kern.vty=vt, have you tried toggling
sysctl kern.vt.suspendswitch ?
Default is 1, ie switch to vt0 before suspending, but some systems may prefer not to.

The equivalent if kern.vty=sc is
sysctl hw.syscons.sc_no_suspend_vtswitch
which, in opposite sense, has default 0. Setting this to 1 was essential on my Thinkpad T23 for successful resume.

This may or may not have anything to do with your issue.

As things stand for users running X11, basically it's broken. All you can do is never do a VT switch and remember to restart X after suspend-resume which is a bit of a pain; or just avoid running any programs that use gpu hardware accel, which is also a major pain for a desktop.

Sounds like it needs a more committed developer.

Good luck.

 

[blackbird9]

Who is 'development' here?



Pruning ...



A pretty solid clue for a cluey developer, one would think.

Assuming you use kern.vty=vt, have you tried toggling
sysctl kern.vt.suspendswitch ?
Default is 1, ie switch to vt0 before suspending, but some systems may prefer not to.

The equivalent if kern.vty=sc is
sysctl hw.syscons.sc_no_suspend_vtswitch
which, in opposite sense, has default 0. Setting this to 1 was essential on my Thinkpad T23 for successful resume.

This may or may not have anything to do with your issue.



Sounds like it needs a more committed developer.

Good luck.

"Development" is the response I got from the developer on the bugzilla, to quote what he said:-

"It's not a mesa problem, it's due to a rewriting of the vt intergration, and the last rewrite didn't fixed it. SO yeah that's something that someone (tm) should work on but since I don't have the problem with wayland on suspend/resume and I never switch VT I don't have the motivation right now." You can read the whole thread on the linked bugzilla.

So basically he says he uses wayland, never switches VT, and wayland doesn't do a VT switch on suspend, so he doesn't see the problem. Although it seems to me that if you did do a VT switch when using wayland, the gpu hardware acceleration that the wayland compositor depends on would be off after the VT switch; and never using VT's is a major limitation.

Anyway, EXCELLENT SUGGESTION smithi on changing the kern.vt.suspendswitch , that works a treat! I actually woke up this morning wondering if there was some way to suppress the VT switch on suspend-resume, but you'd already beaten me to it I've tested it and it works; with kern.vt_suspendswitch set to 0, xdriinfo reports "crocus" following resume, and glxgears shows full performance. So that at least fixes the problem on suspend/resume, or appears to. Two heads are better than one I've added this workaround to the bugzilla.

The issue of losing hardware gpu accel after a manual VT switch is still present, but at least now the system is stable to suspend-resume cycles.

 

[smithi]

The issue of losing hardware gpu accel after a manual VT switch is still present, but at least now the system is stable to suspend-resume cycles.

Glad it helped. You could ask the developer about the sysctl kern.vt.suspendswitch? Maybe that's more the reason it works there, than using Wayland?

 

[blackbird9]

Glad it helped. You could ask the developer about the sysctl kern.vt.suspendswitch? Maybe that's more the reason it works there, than using Wayland?

I've added a note about suspendswitch workaround on the bugzilla. I think the same bug is present when wayland is used, he says he never does a VT switch, presumably to avoid this bug. Wayland compositor almost certainly needs hardware acceleration to do all the fancy eye candy.

I've asked the question on the bugzilla.

 

[getopt]

Maintainers sometimes take no action in response to detections by portscout.
There's discouragement from reporting outdated software in these cases.
Not all maintainers are aware of the importance of VuXML entries. security/vuxml and:
And so on.

I do confirm this degrading. This is a pattern of a broader picture namely the lack of enough committers and fluctuation of the port maintainers which hurts.
If FreeBSD wants to prevail the community should stop praising itself and instead take a realistic and self critical view on what needs to be improved. Marketing efforts are no help when promising a bright future without the people that have to do the "dirt work" which is coding and maintaining.

Thanks to all those who are contributing. They are the realists we need.

 

[smithi]

I've added a note about suspendswitch workaround on the bugzilla. I think the same bug is present when wayland is used, he says he never does a VT switch, presumably to avoid this bug. Wayland compositor almost certainly needs hardware acceleration to do all the fancy eye candy.

Well I'm not suggesting that your problem swiching VTs normally is related to what happens with suspend and resume - it may be, or not, and you'll have to test that.

But that his ability to resume ok may indicate his use of it.

And then, there's other hardware issues with different brands, models, even BIOS revisions, so it's always hard to be definitive about causes.

A partial win is still a win <&^}=

 

[blackbird9]

Well I'm not suggesting that your problem swiching VTs normally is related to what happens with suspend and resume - it may be, or not, and you'll have to test that.

But that his ability to resume ok may indicate his use of it.

And then, there's other hardware issues with different brands, models, even BIOS revisions, so it's always hard to be definitive about causes.

A partial win is still a win <&^}=

Yes, fully agree. I'm really pleased you found this workaround for suspend-resume, it means I can keep usiing the xorg gui for now.

 

[eternal_noob]

If you use a Raspberry PI 4, 400 or 5, the answer is "no", definitely.

 

[blackbird9]

The point is that third party software is audited and inspected by a trusted user before they are pushed to the tree by port committers. This "compliance" is a layer of security.

Hats off to anyone who audits the firefox source code, it sounds like a heroic effort You would have hoped firefox have a decent regession test suite.

 

[cracauer@]

Most maintainers are likely not security experts so not much of a security layer. There should be a way to control a port's access to files external to the package....

Still, to insert malware a software original author (or somebody who took over that account) has to convince a port maintainer to update the port before it threatens FreeBSD. And the user always knows where to get the software - from freebsd.org. That is a lot better than what random windows utilities have to offer.

 

[blackbird9]

If you use a Raspberry PI 4, 400 or 5, the answer is "no", definitely.

Do you mean you don't see the vt switch bug causing loss of gpu hw accel on the pi? If so that's really interesting..

 

[eternal_noob]

No hw accel, no sound, no wifi, crashing browsers, you name it. All in all not the best desktop "experience", imho.

 

[blackbird9]

No hw accel, no sound, no wifi, crashing browsers, you name it. All in all not the best desktop "experience", imho.

Crikey... sounds much worse than I've seen on intel. So the VT switch bug is present on the Pi too.

 

[blackbird9]

I've added a note about suspendswitch workaround on the bugzilla. I think the same bug is present when wayland is used, he says he never does a VT switch, presumably to avoid this bug. Wayland compositor almost certainly needs hardware acceleration to do all the fancy eye candy.

I've asked the question on the bugzilla.

Reply on bugzilla from developer, he says that sysctl is not changed by wayland/sway (what he is running). Interesting...

 

[bakul]

Still, to insert malware a software original author (or somebody who took over that account) has to convince a port maintainer to update the port before it threatens FreeBSD. And the user always knows where to get the software - from freebsd.org. That is a lot better than what random windows utilities have to offer.

Or creates a false sense of security. Being better than random windows utilities is a low security bar to clear!

 

[astyle]

Still, to insert malware a software original author (or somebody who took over that account) has to convince a port maintainer to update the port before it threatens FreeBSD. And the user always knows where to get the software - from freebsd.org. That is a lot better than what random windows utilities have to offer.

Have you taken a look at MASTER_SITES in any given port's Makefile? Truly random places, if you ask me!

And no, the gatekeepers (people with commit bits to the FreeBSD ports repo) are not gonna audit every single one of them... It's relatively easy to get your software to be included in the Ports collection, just follow the Porter's Handbook. This does mean that some rather useless stuff does end up in the Ports Collection.

 

[cracauer@]

Have you taken a look at MASTER_SITES in any given port's Makefile? Truly random places, if you ask me!

Protected by a cryptographic hash only served by freebsd.org.

 

[astyle]

Protected by a cryptographic hash only served by freebsd.org.

Now that doesn't even make sense... Updating the Makefile in the Ports collection's published URL is protected by that cryptographic hash... But when that Makefile is initially submitted for inclusion into the Ports Collection, you can put practically anything into MASTER_SITES (As long as it's a functional URL that you can download a tarball from)...