FreeBSD dev here — I don't like this line of argument. It is always used to rationalize any defect in FreeBSD. Sometimes we just have defects! That's just the truth of things; we don't need to pretend we're defective on purpose. Many developers run FreeBSD on their daily driver laptops or workstations because it is (perhaps tautologically) one of the best platforms to develop FreeBSD on.
Our wifi support isn't 100% and this is a weakness. I believe that desktop usability is a large part of why Linux is as successful as it is today, and the modern laptop is so similar to the modern server that it's a bit of a moot distinction.
I don't think the person you responded to was claiming or implying that FreeBSD's wifi support is incomplete on purpose. Rather giving a reason for why resources have not (yet?) been expended in that area.
I have FreeBSD running on my home desktop workstation and everything is working fine, but I wouldn't try to install it on my laptop. Laptop hardware is just too variable and non-standard. Touchscreens, esoteric Wi-Fi chipsets, fingerprint readers, brightness controls, bluetooth, power management, suspend on lid close... I'd be quite surprised if FreeBSD supported all of this out of the box, so I stick with Ubuntu.
That's a very charitable read of GP's remarks. Kudos for the generosity, but I didn't get the same impression from the statements and the context. The phrases GP is repeating aren't novel; they're repeated time and time again in any messageboard discussion that ever touches on a missing feature in FreeBSD. You could say FreeBSD is missing SATA support (just for example; it isn't really) and someone would chime in with "FreeBSD isn't trying to be all things..."
As far as laptops, it all tends to be a bit specific to the model. There aren't too many different wifi chipsets these days; bluetooth is pretty simple from the software side of things. Power management and lid suspend work on most systems (as they say, resume is the hard part). Brightness controls should also work well. I don't know about fingerprint readers. Recently we landed Thinkpad PrivacyGuard support from software, for example. It's not particularly significant in isolation, just as an example of random modern laptop features that might exist in only a handful of models, which we still try to support in FreeBSD.
Ah, it's sort of a running joke. Like "the fall doesn't kill you — it's the landing."
Our resume support is hit or miss, to be completely fair. I don't even try to use it myself due to bad experiences in the early days with Linux in 2000's and lack of need. Shutdown and startup is fast enough for my travel laptop that I don't care; and my workstation I never turn off. But I recognize a lot of people do really care about suspend/resume, and it works for some people but not everyone.
Please try to be charitable online and consider not engaging if you can't bring yourself to. Nobody can give 100% of the context needed to satisfy everyone that might be reading it. We all seem to want everybody to read our own contributions charitably but don't want to give others the same benefit. Makes interaction not fun.
I do. I think you misread the comment you replied to in an uncharitable way if you arrived at the conclusion that your subsequent reply was responsive.
> Nobody can give 100% of the context needed to satisfy everyone that might be reading it.
That was never the criticism. Your response is a non sequitur.
I really wanted to run FreeBSD in my T470s and the lack of hardware support pushed me over to Ubuntu. I loved setting up FreeBSD and it felt snappy for a lot of stuff but it would be cool if some of the devs who do live on laptops would just release a package they tune for their particular hardware.
And for the T470s in particular (yes, it's somewhat sparse, and the links suggest a non-ideal amount of effort required, but purportedly it seems to work at the end): https://wiki.freebsd.org/Laptops/Thinkpad_T470s
How difficult would it be to flesh out this rough spot? For others, it seems like a FreeBSD dev might not at all be able to get ac support for hardware with the drivers as locked down as they are. But if I knew the problem was tractable I might try my hand at it someday. Could be a good resume driven project.
I can't begin to answer this question, sorry! I mostly don't work on network drivers at all, and the 80211 family/stack is its own beast that I am utterly unfamiliar with.
Linux desktop is great in 2020, especially if you buy the right hardware with solid support, the experience is totally smooth and super-high performance with stuff like ArchLinux.
Boots up immediatley, no annoying MacOS updates or having to install XCode while having multiple versions of core unix packages, because it pre-installs a bunch of out-of-date ones you replace immediately with brew. This causes problems, especially for newbies new to working with terminals, as it falls back onto the old ones when stuff isn't linked or set up properly.
Nothing beats having a clean minimal /usr directory with only the stuff you decide to install and extremely fast startups with good battery use.
I get Macbooks for work but use a Linux one on the side
(which I used for 5+ yrs when I was working freelance) and I plan to convince my boss to let me get a thinkpad or dell for the next laptop update.
So I used to be a Linux mint/ubuntu/fedora user (I distro hopped a bit), but I really like how homebrew on macs is per user account rather than system wide, and I can just delete the folder to reset it for the most part (minus running programs, some GUI casks, and shortcuts). AFAIK, apt-get and most if not all linux package managers only work system wide, and I can't install something just for a specific user. Maybe arch is different? Homebrew definitely has issues though, agreed.
Incidentally I ran all of those distros on a T430... which still works fine when I boot it up. Thinkpads are great linux machines, and just great easily repairable machines in general.
AFAIK, apt-get and most if not all linux package managers only work system wide, and I can't install something just for a specific user.
Not all. Nix and guix allow you to install packages into your own profile as an unprivileged user. Best of all, packages that are installed by multiple users are shared in the Nix store.
Per user installs are unnecessary for most users. Firstly most machines are single user. In multi-user machines installing additional software/libraries system-wide has no downsides. If a particular piece of software can't be installed globally without conflicting with other software it probably needs stronger isolation than your user account and you have multiple better options to achieve this.
The sole case that leaves are cases in which your company doesn't allow you the necessary privileges to install software which is an organizational challenge not a technical one.
That said something like nix can allow you to install software per user.
I think you should not compare package managers like that.
The way I see it, a system is a stack: that is you put a number of layers on top of each other.
The kernel is a layer at the very bottom, on top of which you stack a distribution. This distribution is managed through a package manager. On top of this distribution you could stack a user package manager.
In this view, you cannot compare apt or yum to home brew, they don’t belong to the same layer.
If you think about it, that makes sense. User package managers have to rely on the underlying layer to provide tools for e.g. compiling user packages.
Now I agree that in real life, the limit between layers can be more blurry:
- system package managers distribute end users softwares. Because most desktops are single user so having an extra layer is often not necessary.
- some system package managers are re-purposed to be stacked as user package managers. E.g. you can use gentoo prefix.
Still, to have a clear picture in mind the layers should be considered.
That being said, there are a bunch of user package managers you can also use on Linux. Have a look at spack for instance. I think the nix package manager can be used like that also.
