2024: The year of desktop FreeBSD?

There is a review process and guidelines a maintainer must follow before their port is submitted; regardless of where the source tarball came from. Maintainers are obligated to work with upstream and other maintainers on this. Many maintainers are even upstream developers. You’re being pedantic for the sake of it.
 
There is a review process and guidelines a maintainer must follow before their port is submitted; regardless of where the source tarball came from. Maintainers are obligated to work with upstream and other maintainers on this. Many maintainers are even upstream developers. You’re being pedantic for the sake of it.
The review process and guidelines as outlined in the Porter's Handbook - it amounts to making sure the software compiles, runs, and installs properly on a recent FreeBSD system. That alone is quite a bit of work. Hosting the source tarballs is a plenty important detail in the development process. Apple and Microsoft do bother to have that detail buttoned down much more tightly than Free Software world. And in case you forgot, security is a tradeoff between convenience and pedantism :P
 
You’re oversimplifying the matter. Go ahead and read chapter 3.2 of this document. Given what’s outlined, your argument is still invalid. Ports on FreeBSD are from freebsd.org, not “random sources”. There is a lot of vetting involved. It is not comparable to an .exe or .dmg experience.
 
An update on the subject of the VT switch bug I have discussed in this thread today: from the bugzilla #267915, it has been confirmed that this bug does NOT occur in the Wayland case, they say it's only a problem when X11 is used as the gui. As far as I know so far, only on an intel or ARM cpu platform, but testing is suggested to make sure it happens on your system. So using Wayland instead of X11 is another fix.

When X11 is used, I've been testing the fix for the suspend-review case suggested by smithi all afternoon and can confirm that it does appear to fix the problem of suspend-resume knocking out hw accel. So the only remaining problem in the X11 gui case is doing a manual switch to a different VT and then back to X still knocks out gpu hardware acceleration, at least that's what I'm seeing here.

Just to recap, the fix for the suspend-resume case with an X11 desktop is to set
sysctl kern.vt.suspendswitch=0
Then as long as you don't do a VT switch, gpu hardware accel should stay up.

Thanks to smithi for coming up with this fix. He has mentioned that setting this sysctl may have adverse effects on some systems, so that's something to be aware of.
 
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)...

So?

The point is no file can reach a user's system without passing a cryptographic check controlled by FreeBSD.org. At that point it doesn't matter what the original source of the file is and even whether it uses https or not.
 
You’re oversimplifying the matter. Go ahead and read chapter 3.2 of this document. Given what’s outlined, your argument is still invalid. Ports on FreeBSD are from freebsd.org, not “random sources”. There is a lot of vetting involved. It is not comparable to an .exe or .dmg experience.
oh? looks like you completely ignored what goes into MASTER_SITES section of a port's Makefile... It's not vetted beyond making sure the tarball actually existng at the URL... Do you seriously think that FreeBSD maintains some kind of whitelist of vetted sites where it's OK to look for a source tarball? ?

What do you think a 'port' even is? It's essentially nothing more than a Makefile and a distinfo...

Most of the vetting is automated anyway. If a port fails to compile, the system will let the maintainer know.

The point is no file can reach a user's system without passing a cryptographic check controlled by FreeBSD.org. At that point it doesn't matter what the original source of the file is and even whether it uses https or not.
That's only for tarballs that got dumped into distcache.freebsd.org... do you seriously think that freebsd.org is even designed to scan every single tarball that any given user's system requests (via the ports system) ??? freebsd.org is not Google, come on...
 
That's only for tarballs that got dumped into distcache.freebsd.org... do you seriously think that freebsd.org is even designed to scan every single tarball that any given user's system requests (via the ports system) ??? freebsd.org is not Google, come on...

No, it's not. There is a cryptographic checksum check on all distfiles retrieved, no matter where from.

This is getting quite ridiculous.
 
Just to recap, the fix for the suspend-resume case with an X11 desktop is to set
sysctl kern.vt_suspendswitch=0
Then as long as you don't do a VT switch, gpu hardware accel should stay up.

Beware of generalising. Keep mentioning that this bug is only with specific driver/s and not with the general case of "an X11 desktop", ok?

At message #12 on the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267915
is said:
"Downgrading to drm-54-kmod can fix the problem."

Also, the notion that wayland or anything else might mess with that sysctl is bogus; it's only something a sysadmin might change for a particular system, and some systems may fail if it's changed from the default setting.

cheers
 
No, it's not. There is a cryptographic checksum check on all distfiles retrieved, no matter where from.

This is getting quite ridiculous.
I'm sorry, but that checksum is only used to verify the size of the tarball... and it's definitely NOT controlled by freebsd.org... I realize that we're not on the same page about how the ports infrastructure even works.
The point is no file can reach a user's system without passing a cryptographic check controlled by FreeBSD.org. At that point it doesn't matter what the original source of the file is and even whether it uses https or not.
If a source tarball (which my system downloads via the Makefile call from a MASTER_SITES random source without ever checking in with freebsd.org, BTW) has a size mismatch, and does NOT pass the md5sum checksum, did that file reach my system? Does freebsd.org even know I even tried to download that specific tarball? Buddy, my copy of the ports system has no reason to call home!

A size mismatch reported by my system has absolutely nothing to do with security practices in place at freebsd.org...

I agree, it is getting ridiculous...
 
Beware of generalising. Keep mentioning that this bug is only with specific driver/s and not with the general case of "an X11 desktop", ok?

At message #12 on the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267915
is said:
"Downgrading to drm-54-kmod can fix the problem."

Also, the notion that wayland or anything else might mess with that sysctl is bogus; it's only something a sysadmin might change for a particular system, and some systems may fail if it's changed from the default setting.

cheers
Eh? All I've done is tested 14.0-RELEASE, which is supposed to be the very latest, stable, fully working release on an intel cpu laptop using the intel integrated gpu, which is by far the most common, base level hardware platform anyone is likely to use. And being a thinkpad pretty much as industry standard a laptop as you can get, not some crazy alienware type thing with arcane hardware. Now you say I am 'generalising?' And someone else on here (eternalnoob) said he tried the same test on his r-Pi which is ARM and said it's broken there too?

As for your suggestion of downgrading to some previous-level driver, what's the point of using the latest "stable" release if I have to fudge around after installation putting some old backlevel driver on the damn thing to try to get it to work? Do we even know for sure that works? Has that old driver been fully tested with 14.0-RELEASE? Will putting the old driver on introduce other bugs? Who knows, but I'm not going to waste any more of my time testing that scenario, that's for sure. What a pile of crap!

As the thing stands, as far as I can tell, for anyone else installing 14.0-RELEASE on an intel laptop and then trying to use an X11 desktop, they will still see this crappy bug where it loses hardware acceleration after a mere suspend and resume, unless they discover the sysctl to set via this forum. And forget about using VT's if you want your gpu hardware acceleration to keep working, since they've said in the bugzilla that they're not going to fix that.
 
I'm sorry, but that checksum is only used to verify the size of the tarball...
I don't think that's right. Here is a snippet of Mk/Scripts/checksum.sh where we can see that checksum verification applies to each distfile's contents.

sh:
if [ -f "${dp_DISTINFO_FILE}" ]; then
        cd "${dp_DISTDIR}"
        OK=
        refetchlist=
        for file in "${@}"; do
                ignored="true"
                for alg in ${dp_CHECKSUM_ALGORITHMS}; do
                        ignore="false"
                        eval "alg_executable=\$dp_${alg}"

                        if [ "$alg_executable" != "NO" ]; then
                                MKSUM=$($alg_executable < "${file}")
                                CKSUM=$(distinfo_data "${alg}" "${file}")
                        else
                                ignore="true"
                        fi

                        if [ $ignore = "false" -a -z "$CKSUM" ]; then
                                ${dp_ECHO_MSG} "=> No $alg checksum recorded for $file."
                                ignore="true"
                        fi

                        if [ $ignore != "false" ]; then
                                continue
                        fi

                        match="false"
                        for chksum in $CKSUM; do
                                if [ "$chksum" = "$MKSUM" ]; then
                                        match="true"
                                        break
                                fi
                        done

I also see limited description in the Porter's Handbook where they state in 13.18 that checksums are there to guard against retrieved distfiles being tampered with after a port is published.
 
I don't think that's right. Here is a snippet of Mk/Scripts/checksum.sh where we can see that checksum verification applies to each distfile's contents.
Well, when I saying that, I obviously meant 'any source distfile(s) downloaded by the port'. Yeah, distfiles come in different formats that the ports infrastructure needs to be able to deal with. Guarding against size mismatch (or lack of a reported distfile size, as per your script) is just one of many ways to check that the port downloaded the correct thing.

[For those who didn't read the entire thread and missed the point because of that] Man, my original point was that the FreeBSD Ports Collection collects the software from far more random places than what you'd see in Windows or Apple. If you know where to look (the Makefile's MASTER_SITES section), you'd find what I'm basing that statement on.

In spite of the wide variety of places where the Ports Collection downloads the sources from, this mechanism is a much safer bet on FreeBSD or Linux than on Windows or Apple - thanks to the basic UNIX security model that is VERY different from Windows or Apple.
 
I'm always confused by this discussion.
My laptop is desktop or not? (rethorical question). What's desktop anyway? Why so many disagreement over a very subjective matter?
For me, really, desktop is either:
1- A kind of utopia. In the sense that "desktop" will never realize.
2- A kind of tool (intentionally or not) that keeps the mVery S. the only true desktop OS ever 'status quo'
B.S.

Usability, user friendly installation, driver/software support, accessibility and many other subjects are each it's own business subject. Mixing things and inability do define 'desktop' clearly just leads to #1 above.

I have SUPER key, and efficient window management, ^C ^V works, ALT+TAB works. Can open a multitude of programs in a multimedia environment, and is blazingly fast (God bless XFCE4).
For me I can stop waiting desktop for FreeBSD because I have it already.
 

Attachments

  • Desktop.jpg
    Desktop.jpg
    650.6 KB · Views: 136
the Porter's Handbook - it amounts to making sure the software compiles, runs, and installs properly on a recent FreeBSD system.

There's more, not least <{link removed}>.

Parallel to the FreeBSD Porter's Handbook, procedures include:
  • <{link removed}> three mentions of security, but not in relation to prioritisation
  • <{link removed}> for prioritisation of security-related reports.
 
Last edited:
Now you say I am 'generalising?'

I said "beware of generalising".
Beware of inaccuracy.

As for your suggestion of downgrading to some previous-level driver, what's the point of using the latest "stable" release

Not my suggestion; I just referenced where to find something I thought might help. Beware of inaccuracy, especially with attributions.

Who knows, but I'm not going to waste any more of my time testing that scenario, that's for sure. What a pile of crap!

Fortunately there's a money-back guarantee on this OS ;-)

As the thing stands, as far as I can tell, for anyone else installing 14.0-RELEASE on an intel laptop and then trying to use an X11 desktop, they will still see this crappy bug where it loses hardware acceleration after a mere suspend and resume,

Nothing 'mere' about suspend and resume code, but that was not the issue. vt(4) has issues; complain or contribute.

unless they discover the sysctl to set via this forum.

Don't thank me, I was happy to help, don't mention it ...

But please also mention that it may have bad consequences on other systems, which is why it's not the default setting.

It was your choice to install a brand new .0 release expecting everything to work to your satisfaction immediately.

BTW Also your choice to deny yourself a root console within Xorg. Only members of wheel can su to root, so simply don't put untrusted users in wheel, no more need to switch VTs.

smithi out.
 
For me I can stop waiting desktop for FreeBSD because I have it already.
For 2024 there is lot more scope for development in improving color, style ,theme etc and few for fast changing hardware side. Lot of software/packages are required for only easy visual/graphics way.
I would be very interested in hearing of your reasons why people do or don't daily drive FreeBSD
Only reason is that it is not discussed in generally available popular channels. It is not 'ready to use' after install. You have to have some basic command line aptitude and ready to solve problems. That is why it is not popular among dev's . If we study the percentage use case of MS is only their business policy and PR. Though opensource OS is 'free', the big commercial/educational houses and government go for the easy way.
 
If a source tarball (which my system downloads via the Makefile call from a MASTER_SITES random source without ever checking in with freebsd.org, BTW) has a size mismatch, and does NOT pass the md5sum checksum, did that file reach my system? Does freebsd.org even know I even tried to download that specific tarball? Buddy, my copy of the ports system has no reason to call home!

With that level of knowledge, just asking would be a lot wiser than claiming nonsense.

1. MASTER_SITES certainly isn't "random". Port maintainers make sure an "authentic" source is used in the first place. How exactly depends on the upstream project, maintainers are expected to know something about that project. Submissions from contributors are double-checked by the committer.

2. A FreeBSD port doesn't just check a size! It's using a checksum of course, and no, not MD5 either, but the (currently) cryptographic secure hash SHA256. This makes sure any modification is perfectly reliably detected.

3. A distfile failing the check is never kept on your system.

As cracauer@ already stated, the only thing this can't protect from is a case where someone sneaks malware into a new release(!) of some upstream(!) project and the port maintainer doesn't notice upgrading the port. This can never be solved 100%. But if a distfile just "randomly" changes (the "expected" scenario for your common malware attack), this will be detected, and any port maintainer will have a very close look (exact comparison of old and new distfile) before even thinking about "fixing" this by just updating the distinfo file.
 
Every single port committer
Cool that you KNOW and TRUST everyone committing to ports. I don't.

 
Cool that you KNOW and TRUST everyone committing to ports. I don't.
Then you probably shouldn't use anything created/maintained by anyone you don't know personally?

Which is related to changing 3rd-party distfiles ... how?

It's getting even more ridiculous, I'm out.
 
Nobody inspects anything in the ports. (I maintain a couple of ports, by the way.) My most recent source of disappointment is editors/lapce with its oh so very convenient plugin download feature. That is, it downloads compiled binaries, there is no sandboxing and I suspect no vetting either.
useful to know; one to avoid!
 
Back
Top