2024: The year of desktop FreeBSD?

[getopt]

the basic UNIX security model that is VERY different from Windows or Apple.

How do you define basic "UNIX security model" and why is it "VERY" different?

 

[blackbird9]

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



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



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



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



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.

Well, I guess I may have flown off the handle a bit there, it's the frustration that arises from discovering this mess. Of course I know the implementation of suspend-resume is not simple, but from a user standpoint it absolutely is a standard operation that is expected to "just work". No serious modern desktop o/s would not support a reliable suspend-resume function. And I am of course grateful to you for finding the sysctl fix, I did say so earlier, more than once.

Yes I've sorted out root access from X, that's easy. As for this being a .0 release... well, this IS supposed to be the stable branch, after all, this isn't the development branch. The same bug appears to have been in both the last two 'stable' releases (13.1 and 13.2) as well, going by the bugzilla history, and those were not .0 releases. Someone put 14.0 up on the web and said "here it is, this is our latest stable release, its all ready to use, come and get it!".

And VT switching is a fundamental feature that has been in the *bsd's and linux for decades, it should be mature by now, no-one expects to find bugs in that area. If this was a bug in the new wayland stuff for example, then sure, you would expect to find bugs in newer code, but the VT handling should be rock solid. I don't think I've EVER seen a VT handling bug in linux.

As for "contribute or complain.."... well, I've just spent the best part of 2 days of my time testing 14.0-RELEASE and reporting findings, doesn't that count as a contribution? The company I work for pays a lot of money to people for doing this kind of skilled test work...

 

[getopt]

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?

IT basics. There is no IT-Security, it is an illusion that can be sold. You can try hardening your systems.
Do not trust. You should not have to trust. You can use but this does not mean that you need to trust.
People are not trustworthy just because they belong to your community. They can fall bad at any time.

 

[zirias@]

IT basics. There is no IT-Security, it is an illusion that can be sold.

You can simplify things enough to turn them wrong, this is an example. There's no IT security as a state, there certainly is security as a continuous process (of analysis, mitigation, defense, ...)

Do not trust. You should not have to trust.

This is technically impossible (unless you create and/or fully review everything yourself, starting at the CPU microcode, GPU and chipset firmware, etc, so, impossible).

You should chose wisely whom you trust. Among others, transparency of processes is an important clue. FreeBSD ports won't analyze 3rd-party software, it's (as much as possible) delivered "as is". What you can trust FreeBSD ports with is delivering you untampered original software, and I'll repeat it here, any port maintainer will have a very close look on unexpected distfile changes. It happens rarely and it's a red flag. This is already more than you got in the past from certain "app stores", btw.

BTW, in a b2b environment, you'll additionally make sure to negotiate liability.

People are not trustworthy just because they belong to your community. They can fall bad at any time.

There's never a 100% measure against that, once again leading to the theoretical thought outlined above.

 

[getopt]

You can simplify things enough to turn them wrong, this is an example. There's no IT security as a state, there certainly is security as a continuous process

I did not "simplify". If you'd read carefully, the word "hardening" would have come to your attention. Hardening is a process. And yes, if done well a continuous process.

 

[astyle]

How do you define basic "UNIX security model" and why is it "VERY" different?

As an example, Windows has several 'roles' built-in, like TrustedInstaller, Administrator, and a few others. Here's a good overview, but the basic difference is that Windows is per-object (file, service, whatever, and even top-level admin accounts can't always override one another), while UNIX has root to override friggin' EVERYTHING, and security model is based on system accounts like root, mysqld, etc.

Windows security model for driver developers - Windows drivers

The Windows security model is based primarily on per-object rights, with a small number of system-wide privileges.

learn.microsoft.com

You should chose wisely whom you trust.

That's the important part.

I actually read the article that eternal_noob pointed out in post #147... and I think it does a decent job laying things out in a coherent story. I think the story does demonstrate my point that FreeBSD ports do in fact draw sources from perfectly random places.

You can look at the Ports infrastructure as a factory that processes raw materials into consumer goods. Source tarballs are the raw material. Even a high quality factory will produce duds from time to time because low quality material slipped in through the supply chain.

As a side note, that ArsTechnica article did explain to me why 13.0-RELEASE had to do friggin' 6 RC's and was so behind schedule.

 

[getopt]

That ArsTechnica article from Mar 26, 2021

Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

40,000 lines of flawed code almost made it into FreeBSD's kernel—we examine how.

arstechnica.com

is still worth reading after 3 years:

We take some heart in the fact that FreeBSD Core team's expressed a commitment to improving processes, refining tooling, and making code reviews more effective—but it's impossible to ignore the fact that this commitment comes as an afterthought to attacking "public discourse" that highlighted the need for those improved processes, refined tools, and more effective reviews in the first place.

The FreeBSD community is great on self censing. Critics are not welcome which makes them not better than any other communities.
See style of arguing there:

Ars Technica article focused on Wireguard regarding FreeBSD

https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/ This article is kind of negative, but I don't know what to make of it. The title says it's about FreeBSD, but it's really focused on something related to Wireguard for criticisms of...

forums.freebsd.org

Now what has changed since? Did the FreeBSD Core team improve on
a) processes (which?)
b) refining tooling
c) more effective code reviews

Any hints on where to lookup changes after Mar 26, 2021?

 

[Jose]

...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%...

This does happen, unfortunately, but it's hardly a problem related to or unique to Freebsd:

Developer Alert: NPM Packages for Node.js Hiding Dangerous TurkoRat Malware

Two npm packages, nodejs-encrypt-agent and nodejs-cookie-proxy-agent, were found to harbor the TurkoRat malware.

thehackernews.com

It's much easier to conduct this kind of attack against interpreted languages than compiled ones, but compilation is not a sufficient guarantee of safety, either.

It's much harder to get malware on your Freebsd system by clicking a link in a SPAM email or an ad you see on the Web. Heck, there ads designed to look like a download button all over the Web. I'm 99.999% sure the malware downloaded that way will not work on my Freebsd machine, but will work on most Windows machines.

Cool that you KNOW and TRUST everyone committing to ports. I don't.

Ars Technica article focused on Wireguard regarding FreeBSD

https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/ This article is kind of negative, but I don't know what to make of it. The title says it's about FreeBSD, but it's really focused on something related to Wireguard for criticisms of...

forums.FreeBSD.org

You really want to re-litigate this?

Ars Technica article focused on Wireguard regarding FreeBSD

If he hadn't made it public, and FreeBSD 13 was out today And, again, none of that happened.

forums.FreeBSD.org

 

[Jose]

This is technically impossible (unless you create and/or fully review everything yourself, starting at the CPU microcode, GPU and chipset firmware, etc, so, impossible).

Don't forget the compiler!

https://wiki.c2.com/?TheKenThompsonHack

 

[eternal_noob]

You really want to re-litigate this?

No, but i just wanted to give a reason why i think that having a commit bit doesn't equal trustworthiness.

 

[Jose]

I actually read the article that eternal_noob pointed out in post #147... and I think it does a decent job laying things out in a coherent story. I think the story does demonstrate my point that FreeBSD ports do in fact draw sources from perfectly random places.

I read it too, and arrived at the conclusion that it's yellow journalism garbage:

Ars Technica article focused on Wireguard regarding FreeBSD

No luck involved. Another Freebsd committer reached out to Donenfeld (lead author of Wireguard) with concerns about the implementation. The two of them plus an Openbsd developer that worked on the Openbsd WG implementation then worked together to come up with an alternate implementation. Nope...

forums.FreeBSD.org

 

[grahamperrin]

sysctl kern.vt_suspendswitch=0

Please see:

Intermittant bug in 14.0-RELEASE DRI/crocus driver?

I upgraded 13.2-RELEASE to 14.0-RELEASE a couple of days ago. Hardware is a thinkpad X201 with intel integrated graphics. I am loading i915kms.ko in rc.conf. I'm running a simple setup using windowmaker as the window manager. My uid is in the video group. From cold start, running a glxgears...

forums.freebsd.org

Page 2.

 

[getopt]

that having a commit bit doesn't equal trustworthiness.

This boils it down to a single bit.

But again: Were did the changes the FreeBSD Core team promised in March 2021 happen?

 

[Zare]

A notebook with Windows is standard issue in my organisation, that'll not change any time soon.

There's equally good support (IMHO) for macOS, however Mac hardware is no longer purchased without senior authorisation of a business case. I assume that the resulting dwindling use is mostly due to overpricing by Apple.

I have the same as you.

I hear that Microsoft has way better results in making organizations move to their new model than the orgs have power over the vendor. Office365 moving is being done all around and it's being done in government agencies in Europe too.

Actually, I was referring to the metaphorical desktop Linux kept 'chasing' through the years. That goal post has moved beyond. Tomorrow's desktop OS will be almost always online, "AI" laden thing. Free true desktop OSes like most of Linux world and FreeBSD don't need to hit that target. We can target what Windows 7 was easily, just with contemporary games and application support. Steam movement will be good for games. But productivity software is a big thing and in separate fields like image authoring, video, audio, etc. there are separate levels of issues of why we still don't have most of those titles supported. Sometimes it is just a business decision, sometimes is really about differences in technology.

As for instance I don't believe helmet VR games will ever become mainstream, because there is no reason to believe so - we've been gaming since 70 years or so and it's always been in front of the screen in human environment. Unlikely to change, fork yes, but change, no, and there will still be monitors and GPUs around in 10 years and there will be still major games and programs Windows can use and we can't, although Windows in 2034 won't be anything like the one we're running today.

 

[astyle]

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

I did recently encounter a few sloppily generated distinfo files where editing the size by hand proved to be the difference in extracting the sources and compiling the port. If that kind of detail will slip by a port maintainer without safeguards or verification, what can you expect next? Especially when you consider that MASTER_SITES will often have listed several mirrors as a backup plan... If one mirror serves up a corrupt tarball or no tarball, the ports system will just try the next mirror listed. And that mirror can be any location on the Internet... If that's not 'random', I don't know what qualifies as 'random', then...

Point being, the ports system does draw sources from random places, it's just that on FreeBSD, it's a safer bet than on Windows.

 

[cracauer@]

I did recently encounter a few sloppily generated distinfo files where editing the size by hand proved to be the difference in extracting the sources and compiling the port.

Which port in which git revision?

 

[astyle]

Which port in which git revision?

A valid and reasonable question, but these details are not something I made a note of... I do recall spending about an hour troubleshooting a weird compilation failure that came down to a consistent size mismatch. I guess I can keep my eyes peeled next time I start compiling my way to KDE...

 

[freebsd.flypaper706]

I would actually love trying out FreeBSD on all my devices as a full time developer, but there is especially one thing that prevents me from doing that: Docker! We use Docker to spin up our infra for local development purposes, so that is pretty much a must-have... Also I don't think there is a .NET SDK and runtime for FreeBSD, but I've heard that FreeBSD has the equivalent for WSL to run Linux. If that's the case, and I can run docker via that linux VM, then I'm very keep to give it a try as my main OS.

Also, while not a desktop, I have a homer server that I would also instantly install FreeBSD to if I had the choice, but I created my server infrastructure in docker compose there as well, so I'm currently running Ubuntu Server. Virtualizing Linux there, if possible, I think is a bad idea due to performance reasons probably.

 

[Deleted member 13721]

Make sure you you have a lifebelt usable then.

Absolutely. I've got mine and know the procedure too.

 

[grahamperrin]

Recommended reading (I didn't look at the mid-December RFC until today):

RFC - Work on FreeBSD's Audio Stack

– via emaste@

Ed Maste (@emaste@mastodon.social)

🎵 The @FreeBSDFoundation is contracting work on the FreeBSD audio stack and is looking for comments and feedback https://lists.freebsd.org/archives/freebsd-multimedia/2023-December/002087.html 🎵

mastodon.social

Last week:

[Development report #1] Audio Stack Improvements

 

[grahamperrin]

BSD and FreeBSD popularity​

… There was a poster on here who I haven't seen in years, Oko,

(Oko <https://forums.freebsd.org/members/oko.2361/> last seen in 2018.)

who was impressed by the fact that at, if I remember correctly, an OpenBSD developer meeting, they were all running OpenBSD on their laptops, whereas at a FreeBSD meeting, everyone he saw was running Macs. …

Defocusing from those types of meetings, from <https://survey.stackoverflow.co/2023/#section-most-popular-technologies-operating-system> in the Stack Overflow Developer Survey 2023:

Windows is the most popular operating system for developers, across both personal and professional use.

BSD: considerably more popular for personal use than for professional use. Respectively:

• 0.96% (839 of 87,222 responses)
• 0.59% (517).

Both much higher than the (FreeBSD) 0.01% desktop operating system market share worldwide, which was mentioned on page 2.

Partial screenshot attached. To my eye, the strangest measure is iOS more than twice as popular as iPadOS. FWIW, I usually I think of myself as using the former when truly, I'm using the latter (a mindset that's hard to shake, from the era when iOS was distinct from Mac OS X with nothing from Apple in-between).

---

gtewallace just FYI (and I'm not conflating anything here with regard to enterprise use of FreeBSD).

 

[piizog]

Sorry to kind of necropost, but the article has now been published in the Skrolliin magazine and has been generally received well.

Thanks for all the comments and resources pointed to here. I mention the forum as a very good source of info and problemsolving in the article.

The whole thing will be available for free with a 9 month delay, at which point I'll provide a translation of the whole thing, but here's a picture of the fist page in Finnish. The article spans two spreads, so 4 pages of FreeBSD evangelism.

 

[dr3mro]

IMHO FreeBSD to be used as desktop it needs more testers and users, a lot of bugs are out there undiscovered in all DEs on FreeBSD, but if you use a window manager you can get it right easily, especially things like DWM which I use as my daily driver with FreeBSD 14, I have tried XFCE, GNOME and KDE and all of them has a lot of issues that can only been explained by lack of testing.

 

[grahamperrin]

… I have tried XFCE, GNOME and KDE and all of them has a lot of issues that can only been explained by lack of testing.

Can you describe one of the issues with KDE on FreeBSD?

I'll not report an issue in Bugzilla for FreeBSD if there's a likelihood that the issue is reported upstream.

 

[grahamperrin]

… The whole thing will be available for free with a 9 month delay, at which point I'll provide a translation of the whole thing, but here's a picture of the fist page in Finnish. The article spans two spreads, so 4 pages of FreeBSD evangelism.

Thank you!

Graham Perrin (@grahamperrin@bsd.cafe)

2024: Työpöytä-FreeBSD:n vuosi? (2024: The year of desktop FreeBSD?) 2024.1 - Skrolli - Tasavallan tietokonelehti <https://skrolli.fi/numerot/2024-1/> From <https://forums.freebsd.org/posts/649216> (page 7): ❝… The whole thing will be available for free with a 9 month delay, at which point...

mastodon.bsd.cafe

2024: Työpöytä-FreeBSD:n vuosi?

(2024: The year of desktop FreeBSD?)

2024.1 - Skrolli - Tasavallan tietokonelehti <https://skrolli.fi/numerot/2024-1/>

…