FreeBSD system and its share of worldwide use - July 2024

...snip... There's still no official Firefox release for FreeBSD.. go figure.
What do you mean by that? There is a Firefox port www/firefox which builds and works just fine. What do you mean by "official"?

BTW, with Firefox, the browser string correctly reports "FreeBSD" to the web server. With Chromium on FreeBSD, the browser string reports "Linux".
 
BTW, with Firefox, the browser string correctly reports "FreeBSD" to the web server. With Chromium on FreeBSD, the browser string reports "Linux".
Why do I keep getting Linux in my user agent?
Code:
Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
 
Why do I keep getting Linux in my user agent?
Code:
Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
Good question. Did you build the Firefox by yourself from port?

Anyway, what comes to worldwide statistics, I suspect that many FreeBSD machines contribute to the Linux system count.
 
Yes. If it's origin is latin.
Lina if it had greek roots.
... BS! 😅

My memory might be a bit fuzzy about that (and other things *cough*),
but as I remember the main reason for the beginning rise of Linux with the end 1990s/starting 2000s
wasn't its desktop-capabilites,
but its reliable stability, and because of that its usage in servers and internet-infrastructure.
And because of its network config was done by network/Unix-standards, not what Microsoft had made up on its own.

What Microsoft had to offer that time?
Right. The bluescreen of death.
I remember we were putting up our first LAN (warstorys about IPX, and coaxial cables)
Everybody had/brought a 95/98 machine. One installed a headless Linux-NAS with Samba.
Everything was working ... - well, it was working in some way.
Then one attached a Windows NT machine to it. Game over.
The NT-machine said:"Okay, you amateur enthusiast maggots. This here is a professional machine within your little pathetic tinker network. Now I'll show how things are done in a real network!" Yeah, great, nothing at all!
We simply got no LAN up an run again anymore until we banned that NT-machine from our LAN.
Exemplary professional indeed.

FreeBSD was something simply nobody knew. There was not much to read about it in computer-magazines that time.
But 'Linux', 'Linux', 'Linux', Linux everywhere; everybody was talking Linux, only.
 
In my experience non-server driver support is much better than people think. Speaking about Intel wireless, iwm(4) works perfectly in my case and even the installer configured the card and worked first time. The lack of USB3 support is a real problem, though. Yes, the port works but the speed is absolutely not comparable to what I was able to obtain with Linux.
 
However I would say that FreeBSD has had to take one step back so it can take a giant leap forward. For example with the iwlwifi(4) driver, it is still fairly buggy, but once this is in place, it will offer a far superior feature-set to OpenBSD's offerings and will be in a closer lockstep to the vendor's drivers.
I get how iwlwifi should work on FreeBSD, but that would still only limit the entire stack to 802.11g levels of connectivity. So WiFi on FreeBSD has two problems: hardware driver support as well as the underlying plumbing to use 802.11 revisions beyond g. I'm honestly nog seeing any leaps forward at this point in time. Am I looking in the wrong places? Are there any revolutions on the horizon? Most of what I can find regarding these developments seems to have fizzled out around 2022 but I *REALLY* hope I'm missing things.
 
This kind of statistics are often inaccurate / unclear.
How the data are collected? Crawling among servers?
Record and analyze user agents/robots and so on which connected to their website?
For the former, it depends on how wide-spreaded / randomly they crawled.
For the latter, it perfectly depents on users/robots interested in their website.
As far as I remember, there were no statistics make the facts clear.

And as cracauer noted, the latter has problems with mimiced user agents.
 
At least there are very well supported WiFi cards like Atheros AR9462. I can get 100Mbps download (thats the maximum i can get at home) with that card on my desktop. I use mini pcie to pcie x1 adapter to put that card in.
 

Attachments

  • 1723044097307.png
    1723044097307.png
    135.7 KB · Views: 27
I get how iwlwifi should work on FreeBSD, but that would still only limit the entire stack to 802.11g levels of connectivity.

Isn't the whole point of iwlwifi vs iwn, wpi, iwi, etc that it *will* support the 'n' standards and respective speeds?

From the manpage:

While iwlwifi supports all 802.11 a/b/g/n/ac/ax the compatibility code
currently only supports 802.11 a/b/g modes. Support for 802.11 n/ac is
to come. 802.11ax and 6Ghz support are planned.

Apparently this is infeasible with the previous intel drivers. I notice OpenBSD's has a note in the CAVEATS section.

802.11n operation is currently limited to data rates MCS 0 to MCS 7.

That said, I am undecided which approach is better. FreeBSD's compat wrapper layer, or OpenBSD's brute force implementation approach. Thats why I am very glad that BSDs are doing things differently to find out.
 
A simple fact on free open-source operating-systems like BSD, or Linux is,
you do not have always every hardware supported, especially not the bleeding edge.
Never was, and presumbly never will.
Anybody with small experience on BSD, or Linux know that, and trys to look for supported hardware before it's bought, and live with not to have the bleeding edge in most cases.

Some may did not experienced the time until app. ~2005(?), when app. every couple of years CPU-frequencys doubled, and every new OS version means: "Buy a new computer! 'cause yours is three years old ancient, obsolete garbage!"
Today you may want the newest, fastest things, but you don't have to anymore. I see people here running FreeBSD on over fifteen year old machines. That's great! That's also a form of progress!

If you want all newest hardware supported use Windows.
But with Windows you may f4kked if you want/need to run some old hardware.
I heard there were people threw away their perfectly working scanner, just because they got a newer version of Windows which didn't support it anymore, so they had to buy a new one. Just a rumor I heard...

After all
as drhowarddrfine also pointed out:
It's up to the hardware's developers, to either deliver support for their hardware, or to provide their sources for others to deliver it.
NVIDIA did it. Now produces FreeBSD drivers by its own.
Twenty years ago that was something you hope for, that companys would support Linux, or even BSD. That was a dream.
So an important start is made.

Additionally
it's a question of prioritys, available resources; things needed to be done, things can be done.
FreeBSD does not have unlimited resources; there are decisions to make:
What will be done, and what needs to wait. Projects with cash flows get priority.
It's that simple.
And one may think to join FreeBSD developer's force instead of just demanding.

And last but not least there are policys.
I guess one of FreeBSD policys is not to become the most famous OS.
For that you need to go the Windows Way, or those of Linux' turn-key-distris.
For that you need to be set up completely different, have some dictator or so.
Anybody ever did any computer-support for Karen Everyuser will for sure not want this nightmare become reality here.

And even if so:
Who then will do the good, the right, the professional OS for the ones who do not depend on everything is working automatically right out of the magic box, but able to do some things themselves on their own, paying this price for transparency, and independency, and other things?
Right.
 
A simple fact on free open-source operating-systems like BSD, or Linux is,
you do not have always every hardware supported, especially not the bleeding edge.
Never was, and presumbly never will.
Same with macOS and yet people still seem to like that.

Plus, with the fact that Windows drops older hardware and an increasingly rapid rate, open-source is the *only* way you can guarantee the widest hardware support.
 
I want UEFI 3.x (or different spec superceding UEFI 2.x) to be much, much more hypervisor (or monitor on mainframe) like, in other word, revive of I2O with much modern and extensible way both in performance and functionality.

100% prohibit (even for Windows!) direct control of devices other than CPU instructions itself and force usage of its runtime service calls.
 
The share of FreeBSD usage in the world generates a hope of light in the face of the advancement and modernization of other systems used in the world.
Please don't forget that "The share of FreeBSD usage in the world" includes all sorts of FreeBSD-based devices, like OPNsense, PFsense, the late, great M0n0wall, the Asterisk and FreeSwitch VOIP PBXs (IIRC, one of those two may have switched to Linux), FreeNAS, and several others.
 
Same with macOS and yet people still seem to like that.
Yes, but Apple has another policy: It's a sect.
You join it, and then you use Apple-Hardware exclusively, only.
Apple provides everything you need, and therefore it works.
What Apple does not provide you don't need.
Therefore you're part of Apple. Better than all others. Elite.
And like any other sect, you pay for it.
With lots of money, and other things.
It gets hard if you want do things different, 'jail-break',... well then you had better started with BSD, or Linux in the first place 😁

Plus, with the fact that Windows drops older hardware and an increasingly rapid rate, open-source is the *only* way you can guarantee the widest hardware support.
Ain't it what I said?
 
In case you forgot, the FreeBSD foundation is spending money to pay a person to work on wifi.
Next step should be to pay someone to work on a proper suspend|hibernation and resume setup. Not only in the fact that the whole thing don't work in most setups, but also in some configurations, for example S5 doesn't power off when the lids close, only when it is opened again. Leaving the system running in a limbo state in the middle of a power off. If the note it is in a bag, the heat can be damaging for the hardware. Also, since the resume don't work, most of the time the shutdown processes gets stuck when you open the lid again, at that point only a hard reset can make the system boot again (but this part also happens to suspend|hibernation).
 
Next step should be to pay someone to work on a proper suspend|hibernation and resume setup. Not only in the fact that the whole thing don't work in most setups, but also in some configurations, for example S5 doesn't power off when the lids close, only when it is opened again. Leaving the system running in a limbo state in the middle of a power off. If the note it is in a bag, the heat can be damaging for the hardware. Also, since the resume don't work, most of the time the shutdown processes gets stuck when you open the lid again, at that point only a hard reset can make the system boot again (but this part also happens to suspend|hibernation).

That would be some orders of magnitude more difficult. Because it is BIOS and ACPI that is responsible for most of the failures. And you'd need a developer with a house large enough for a couple hundred laptops.

However, there is an alternative. You could aim at doing suspend/resume without the help of the firmware the way that Linux does it with its kernel-base suspend-to-disk. On resume you boot the kernel normally, but then you reconstruct the suspended state entirely in the kernel, under your control.

Having said that, this way of suspending doesn't seem to be very popular among Linux users. It worked for me when I used it, but I have no recent experience. Maybe there is something fundamentally wrong with it.
 
That would be some orders of magnitude more difficult. Because it is BIOS and ACPI that is responsible for most of the failures. And you'd need a developer with a house large enough for a couple hundred laptops.

However, there is an alternative. You could aim at doing suspend/resume without the help of the firmware the way that Linux does it with its kernel-base suspend-to-disk. On resume you boot the kernel normally, but then you reconstruct the suspended state entirely in the kernel, under your control.

Having said that, this way of suspending doesn't seem to be very popular among Linux users. It worked for me when I used it, but I have no recent experience. Maybe there is something fundamentally wrong with it.
Well, I don't know anything about this level of system code. That being said, hibernation|suspend and resume always worked for me on OBSD, even when the battery runs dead, when I boot back I get every open file and or application in the same place as I left it (tested only in my T430 and X220). Do you know anything about their implementation?
 
You join it, and then you use Apple-Hardware exclusively, only.
Apple provides everything you need, and therefore it works.
I suppose if every FOSS download page lists ThinkPad Laptop or HP Workstation as the *only* supported hardware, open-source could claim 100% hardware guarantee in the same way as Apple.

But alas, it ultimately wouldn't improve anything. Since open-source isn't a business, there is no benefit to this kind of behaviour.
 
Well, I don't know anything about this level of system code. That being said, hibernation|suspend and resume always worked for me on OBSD, even when the battery runs dead, when I boot back I get every open file and or application in the same place as I left it (tested only in my T430 and X220). Do you know anything about their implementation?

No. Is the same laptop not suspending with FreeBSD?

OpenBSD at least has the advantage that it is not GPLed, so code can be taken from there.
 
Back
Top