2024: The year of desktop FreeBSD?

[Argentum]

Using FreeBSD on a laptop clearly lacks the smooth experience found in macOS or Windows for applications.

That is the point - most users do not use the Operating Systems these days. They are using the Desktop Environment or GUI. FreeBSD does not prescribe any of these as macOS or Windows do. This is entirely on the user. That explains the low usage on desktop machines, but does not diminish the value of the FreeBSD as an OS.

BTW, ZFS is perfect for desktop machines also and, personally, I am using Bhyve on the desktop machine (which actually pretty powerful, compared to many servers two decades ago...).

 

[PMc]

That is the point - most users do not use the Operating Systems these days. They are using the Desktop Environment or GUI. FreeBSD does not prescribe any of these as macOS or Windows do. This is entirely on the user. That explains the low usage on desktop machines, but does not diminish the value of the FreeBSD as an OS.

"smooth experience" was the keyword here.

I am currently trying to port a web application.
I have an understanding that a web application should have (at least) two users. One for deploying it and one for running it. The deployment creates the filesystem structure and the database schema, while the running application does only change the content, and should not need to write the filesystem at all (except specific upload etc. directories outside of the application's executable tree).
This is a very obvious difference, and therefore a simple means for a bit more genuine security.

But it is almost impossible to implement it as such, and that is because of the "smooth experience": The application can dynamically change, it can detect new features and activate them - and this is done by moving things around in the filesystem etc.
On a desktop this is not so much of an issue, because there is only one user. With a web application it is more delicate from a security perspective.
But there might be a rule to propose: the more "smooth" the experience shall be on the surface, the more weird and chaotic it becomes in the guts.

 

[astyle]

You are dissecting my word usage and opting to misread it. I didn't mean capable as in capable in some nebulous space. I meant capable as an out-of-the-box solution in the userspace. As it stands now, plain encryption mode is not available in FreeBSD.

There's a difference between 'Not provided in base or packaging' and 'not capable'. The latter means, 'not capable by design'. As in, a '32-bit architecture is not capable of running 64-bit binaries'.

Now, 'plain mode encryption' is most likely a feature that needs to be turned on. It might not be available in pre-compiled packages, but should be available as an optional feature that can be turned on if you compile a port.

It's not out of question that a feature in a FreeBSD port/package is not available for some reason - like a deprecation for security reasons.

If something is important enough that you do research, it really helps to learn the importance of using precise terminology when defining a problem. You just might discover that there's a stupid simple solution to the problem, after all.

But offhand casual bashing based on limited information - that's not nice.

 

[canihazsekooriti]

You just might discover that there's a stupid simple solution to the problem, after all. But offhand casual bashing based on limited information - that's not nice.

FreeBSD failed in its mission to deliver. Let's port Linux to FreeBSD. Prove me wrong anyway.

 

[Beastie7]

FreeBSD failed in its mission to deliver. Let's port Linux to FreeBSD. Prove me wrong anyway.

Terrible idea. We're better off forking KDE Frameworks and turning that into a stable API application developers can hack against. Especially for kernel level features. IBM pretty much owns GNOME/GTK.

 

[Espionage724]

Using FreeBSD on a laptop clearly lacks the smooth experience found in macOS or Windows for applications.

I'm still kind of curious how trying to deal with wpa_supplicant on a laptop on-the-go would compare to years of conveniently selecting an AP with GUI NetworkManager on Linux (the little I messed with this would just have wifi ignore the specified passworded AP and connect to a random open one)

That was a concern very early on when I installed FreeBSD, and I forgot it over the weeks with trying to wrangle down other stuff for a desktop experience. I figure that'll be something I'll mess with later if the scenario arrives, and worst-case I can USB tether my phone and SYNCDHCP real quick.

 

[astyle]

We're better off forking KDE Frameworks and turning that into a stable API application developers can hack against. Especially for kernel level features.

That, there's no real need - KF5 and KF6 run fine on FreeBSD. I can use Dolphin to get to my USB sticks no problem.

I'm still kind of curious how trying to deal with wpa_supplicant on a laptop on-the-go would compare to years of conveniently selecting an AP with GUI NetworkManager on Linux (the little I messed with this would just have wifi ignore the specified passworded AP and connect to a random open one)

You can try bsdconfig wireless. If it sees your card, it should work. But I agree, the wpa_supplicant details do need to be nailed down so that rank-and-file users don't have to do PhD-level research and experimentation just to get wifi working correctly even on the limited subset of 802.11 hardware that FreeBSD does support.

 

[kpedersen]

so that rank-and-file users don't have to do PhD-level research and experimentation just to get wifi working correctly even on the limited subset of 802.11 hardware that FreeBSD does support.

Honestly a PhD takes a little more than 6 lines in a config file:

network={
           ssid="home"
           scan_ssid=1
           key_mgmt=WPA-PSK
           psk="very secret passphrase"
}

The "research" involves typing man wpa_supplicant.conf and skipping to the EXAMPLES section... If they can't do that, they probably aren't enjoying their FreeBSD experience from inception and are basically playing with the wrong toy.

It takes much more effort to close all the Windows 11 popups when trying to connect to a network. Why this is not an option on Linux, is purely because it is too unstable to stick to a single WPA injector. They are already itching to get IWD to replace it.

As an observation, I notice that we have had a tonne of newbies join the forum recently which is great. But jeez guys, read the damn handbook some day!

 

[Espionage724]

The "research" involves typing man wpa_supplicant.conf and skipping to the EXAMPLES section... If they can't do that, they probably aren't enjoying their FreeBSD experience from inception and are basically playing with the wrong toy.

Does that require all those spaces and key_mgmt and scan_ssid?

I was under the impression that key_mgmt should be automatic, and scan_ssid only required for APs that hide/don't broadcast the SSID (haven't seen a hidden AP in years and mine broadcasts). I had ssid and psk, it was plaintext-correct, but didn't just-work after a network reload and complete reboot (still connected to some random open AP). Even with key_mgmt and scan_ssid added.

Basically, 4 lines of text with some spaces weren't enough to get that working consistently, hence Ethernet'ing and going off to doing other "more important" stuff

 

[astyle]

Honestly a PhD takes a little more than 5 lines in a config file:

network={
           ssid="home"
           scan_ssid=1
           key_mgmt=WPA-PSK
           psk="very secret passphrase"
}

The "research" involves typing man wpa_supplicant.conf and skipping to the EXAMPLES section...

It takes much more effort to close all the Windows 11 popups when trying to connect to a network. Why this is not an option on Linux, is purely because it is too unstable to stick to a single WPA injector. They are already itching to get IWD to replace it.

Would be nice if that worked reliably no matter the card, or past configuration mistakes. Not everybody knows the vocabulary even within those 5 lines or has the inclination to spend the time to learn it.

I did a lot of research and experimentation, those 5 lines are sometimes just not enough to turn off undesirable behavior like automatically connecting to the wrong hotspot. Connecting to wifi shouldn't be an adventure in research and experimentation. And BTW, I don't get 11 popups when connecting a win11 laptop to a new hotspot. Those annoying details have been cleaned up by MS.

 

[kpedersen]

Would be nice if that worked reliably no matter the card, or past configuration mistakes

It does work reliably. No matter the supported card. If your card has hardware or other past configuration mistakes, even a GUI tool would obviously fail too (since it just uses wpa_supplicant underneath).

I would even suggest that using wpa_supplicant directly is the *only* solution that works reliably. It cuts out a wide range of classic problems with i.e dbus, control interface errors. Especially from beginners who are unable to pick apart the IPC technology.

Does that require all those spaces and key_mgmt and scan_ssid?

If you copy from the example manpage I linked and you don't end up with that same number of spaces, your copying process is inadequate.
As with most things in UNIX, whitespace is used for tokenizing and ignored unless quoted.

I had ssid and psk, it was plaintext-correct, but didn't just-work after a network reload and complete reboot (still connected to some random open AP). Even with key_mgmt and scan_ssid added.

Basically, 4 lines of text with some spaces weren't enough to get that working consistently,

Then the configuration generated by the GUI would also fail. You clearly have other (driver?) problems with your setup. Try not to blame a tool for something outside of its control.

hence Ethernet'ing and going off to doing other "more important" stuff

Yes, you need to use different hardware rather than your unsupported wifi card. "Rip out the broken shite and replace it with something that works" is always the motto these days since hardware is dead cheap.

 

[astyle]

It does work reliably. No matter the card.

OK, how would you get the card to stop constantly and automatically connecting to the wrong wifi hotspot that is not even mentioned in /etc/wpa_supplicant.conf?

Every time I issue a service netif restart, that issue (of connecting to the hotspot the system should know nothing about) crops up.

 

[kpedersen]

OK, how would you get the card to stop constantly and automatically connecting to the wrong wifi hotspot that is not even mentioned in /etc/wpa_supplicant.conf?

Every time I issue a service netif restart, that issue (of connecting to the hotspot the system should know nothing about) crops up.

Whats your solution with a GUI alternative?

This is a known issue with *nix wifi in general. Nothing to do with wpa_supplicant vs GUI or user-friendlyness.

https://forums.freebsd.org/threads/...to-connecting-to-any-open-access-point.59992/

Really, it sounds like it is working fine and that it is simply a design decision that you (or I) simply aren't fond of. FreeBSD is for more people than you (or I), we can't expect its defaults to be completely tailored to us.

(Note: To avoid this behaviour, don't restart netif wholesale, instead use # /etc/rc.d/netif restart <iface> (or the semi-recent NOAUTO flag in rc.conf(5) and bring it up manually). The command line specifically provides us with these solutions compared to some inflexible GUI).

 

[Espionage724]

As with most things in UNIX, whitespace is used for tokenizing and ignored unless quoted.

Yeah I kind-of get that, but I assume 4-8 extra spaces (or tabs) is only to make it look more-pretty and not practical to the code itself.

Basically, why wouldn't this work?

network={
 ssid="myssid"
 psk="mypsk"
}

I also tried it with the example spaces and didn't have it do anything differently, and assumed whatever was going on wasn't related to the amount of spaces

 

[kpedersen]

Yeah I kind-of get that, but I assume 4-8 extra spaces (or tabs) is only to make it look more-pretty and not practical to the code itself.

Basically, why wouldn't this work?

As mentioned, whitespace is largely ignored in UNIX config files. Two spaces should work fine.

The only place that I have come across where this matters is Makefiles where the rule body needs to be a single tab rather than N spaces.

That said; as per the wpa_supplicant.conf(5) manpage:

note the leading "network={" may have no spaces

 

[Espionage724]

The only place that I have come across where this matters is Makefiles where the rule body needs to be a single tab rather than N spaces.

Would it be impossible to use spaces there if I wanted to anyway?

I never understood Tab beyond it being nice for spacing a new paragraph in literature writing, and jumping around input text boxes on websites ; in Linux I avoided using it in confs entirely and used 4 spaces.

 

[kpedersen]

Would it be impossible to use spaces there if I wanted to anyway?

Not on POSIX compliant make. I haven't come across a make tool that allows it yet.

I never understood Tab beyond it being nice for spacing a new paragraph in literature writing, and jumping around input text boxes on websites ; in Linux I avoided using it in confs entirely and used 4 spaces.

Yeah, I tend to use spaces for most things too. Tab is variable size per editor, per console so basically opens you up to formatting issues.

 

[astyle]

Prevent wlan0 from auto-connecting to any open access point

(reposting from freebsd-wireless@: https://lists.freebsd.org/pipermail/freebsd-wireless/2017-March/007543.html) Hi, I have a pretty basic question, but was unable to find any useful answer in the Handbook or man pages. I would like to prevent a USB Wifi card from automatically connecting to an...

forums.freebsd.org

Yep, this thread has a bug listed at the very end, and it's still open: PR 256957

The bug describes the very issue that we were talking about (and everybody's struggling with).

This is the kind of research that not everybody even knows how to do. And yes, it will make a difference for FreeBSD to be on par with other OSes in regard to reliable wifi management - not just the people who can stomach playing with wpa_supplicant details (and making mistakes along the way), but people who may be new to BSDs in general, but know what Android is.

There's people who give up on Xorg because they could not make a go of it - so just installing Xorg and GPU drivers and loading them via rc.conf is actually all it takes. I wouldn't want to dig very deep into the kernel and tell it to load the driver at exact address in RAM specified in hex. Same with wifi - it shouldn't be an adventure playing with details, it should be as easy as on an Android. Do it once, do it right.

 

[Jose]

Now, 'plain mode encryption' is most likely a feature that needs to be turned on.

I have no idea what that means, TBH. I lack enough interest to even google it.

 

[Cath O'Deray]

… try bsdconfig wireless. …

" … cannot join a network or edit an existing network, …"

 

[Cath O'Deray]

… still open: PR 256957

… the kind of research that not everybody even knows how to do. …

Is it a bug? I no longer know

 

[kpedersen]

The bug describes the very issue that we were talking about (and everybody's struggling with).

This is the kind of research that not everybody even knows how to do. And yes, it will make a difference for FreeBSD to be on par with other OSes in regard to reliable wifi management - not just the people who can stomach playing with wpa_supplicant details (and making mistakes along the way), but people who may be new to BSDs in general, but know what Android is.

If this bug was present on Windows, I don't feel that their "user-friendly" GUIs would be in any better position to tackle it or protect users from "research" any more than FreeBSD's direct wpa_supplicant approach.

I.e we can't really say that "I think we need an easy to use GUI because it will fix all bugs". That will not be the case. If anything wpa_supplicant makes it much easier to diagnose by those who can.

A bugs a bug. Nothing to do with wpa_supplicant being the standard WiFi config tool.

There's people who give up on Xorg because they could not make a go of it - so just installing Xorg and GPU drivers and loading them via rc.conf is actually all it takes. I wouldn't want to dig very deep into the kernel and tell it to load the driver at exact address in RAM specified in hex. Same with wifi - it shouldn't be an adventure playing with details, it should be as easy as on an Android. Do it once, do it right.

Installing i.e GPU drivers is accepted as a task on Windows, so I don't think newbies really have a problem with that.
Getting an AMD, NVIDIA or Intel driver working on Android is extremely complex. I don't think any platform should strive to be like Android ever. Yes, you can buy a preconfigured Android system and skip the scary stuff but honestly, you could do the same with FreeBSD too, it would just be a bit wasteful because it is *much* easier and user-friendly to compile / install than Android.

 

[tingo]

I'm still kind of curious how trying to deal with wpa_supplicant on a laptop on-the-go would compare to years of conveniently selecting an AP with GUI NetworkManager on Linux (the little I messed with this would just have wifi ignore the specified passworded AP and connect to a random open one)

There is a command for that - wpa_passphrase(8). I simply do wpa_passphrase ssid, input the password it asks for and get a finished stanza to put into the wpa_supplicant.conf(5) file. If I want fewer steps, I could just do # wpa_passphrase ssid >> /etc/wpa_supplicant.conf - all done.

 

[fr0xk]

FreeBSD failed in its mission to deliver. Let's port Linux to FreeBSD. Prove me wrong anyway.

Actually, if you go through the KPI of *BSDs, then you'll see FreeBSD and OpenBSD is porting Linux KPIs so that drivers can be easily ported into *BSDs too

 

[fr0xk]

I'm still kind of curious how trying to deal with wpa_supplicant on a laptop on-the-go would compare to years of conveniently selecting an AP with GUI NetworkManager on Linux (the little I messed with this would just have wifi ignore the specified passworded AP and connect to a random open one)

That was a concern very early on when I installed FreeBSD, and I forgot it over the weeks with trying to wrangle down other stuff for a desktop experience. I figure that'll be something I'll mess with later if the scenario arrives, and worst-case I can USB tether my phone and SYNCDHCP real quick.

In my analysis, I've noticed that Linux distributions focus on seamless integration with desktop environments, Free/Open/NetBSD on the command-line interface (CLI). Even the FreeBSD Handbook guides users through configuring desktop environments, requiring manual mounting of procfs for using major desktop environments. Linux networking was once a complex affair with ifconfig (not to be confused with BSD ifconfig). But now, iproute2 provides a BSD-like integration with various networking components, including WiFi, Ethernet, VLAN, support for multiple IP addresses per interface, and policy-based routing, significantly enhancing network management compared to the older ifconfig (Linux). NetworkManager simply automates network management through a graphical interface or a command-line frontend (nmcli) for iproute2 and wpa_supplicant to desktop environment/window manager users.

The only thing I don't like is switch from man to info. Writing an info page with a C code example sucks.