2024: The year of desktop FreeBSD?

[Sam The Ripper]

I ran Alpine Linux on my desktop. It offered a great OpenBSD-like experience with the benefits of Linux. But many large open-source projects don’t compile on musl without custom patches. Rust with aarch64 on musl throws a bunch of strange errors.

I dislike the entire Rust ecosystem as much as I appreciate the design of the language. I made the mistake of following their recommended installation method. They created a script that installs rustup, which polluted my environment variables in over 10 places. After a failed rustup installation, my shell kept showing “file not found” errors from the $PATH environment variables. I had to manually locate these files and remove the lines it added to .bashrc, .profile, .config/fish, etc. Rust doesn’t even support aarch64 properly. I can't just use rustc by itself (maybe there's a way); I'm forced to use Cargo.toml and configure everything there just to compile a simple program with a basic syscall. Then, there’s the linker issue with LLVM lld. I ended up having to use the libgcc runtime and GNU linker and be done with it. It was f*ckin ridiculous amount of work, or maybe just maybe I suck at it.

Note: Apologies for my words, but I really needed to vent. I despise __GLIBC__ with my passion but it's probably too late

The best way to deal with Rust, with its bloated and messed up toolchain, is throwing it away and don't use it.

 

[astyle]

The best way to deal with Rust, with its bloated and messed up toolchain, is throwing it away and don't use it.

Good luck with that. Even in FreeBSD's ports, a lot of upstream projects (which FreeBSD doesn't control) have dependencies on rust somewhere. Once you finish dependency resolution, there's gonna be a dependency on rust, just a few hops away from the origin. An unfortunate cancer of Open Source, because removing dependency on rust will require that everybody agree to do that - and good luck going one by one. You'll end up needing to redo the whole computing stack from ground up, because even basic compilers have rust dependencies, even LLVM.

I think GCC managed to escape depending on rust, but other projects were not that stubborn. ?

 

[fr0xk]

The best way to deal with Rust, with its bloated and messed up toolchain, is throwing it away and don't use it.

I'm in a dilemma:

* Give up on Rust: Manually handle memory in C and wrestle with cryptic template errors in C++

* Stick with Rust: Hope for a less bloated language and improved toolchain, without adding a bunch of environment variables to my local profile.

Or maybe I should try C++ with Rust-like features. Rust is also currently embroiled in a trademark dispute after python and GNOME. Business as usual I guess. I saw it already with BitKeeper, GPL3, MySQL and Maria, Nvidia binary blobs, Debian non-free, Amazon crap in Ubuntu, secure boot, etc

This is embarrassing.

 

[fr0xk]

Good luck with that. Even in FreeBSD's ports, a lot of upstream projects (which FreeBSD doesn't control) have dependencies on rust somewhere. Once you finish dependency resolution, there's gonna be a dependency on rust, just a few hops away from the origin. An unfortunate cancer of Open Source, because removing dependency on rust will require that everybody agree to do that - and good luck going one by one. You'll end up needing to redo the whole computing stack from ground up, because even basic compilers have rust dependencies, even LLVM.

I think GCC managed to escape depending on rust, but other projects were not that stubborn. ?

I think the way rustc is designed feels great, but then Cargo and rustup happened. You end up with even worse than Python-like package management and an installation script that modifies your `.bashrc`, `.profile`, `.config/config.sh` (or Zsh related files), adds custom shell completions for Fish, Zsh, and Bash, and messes with your environment variables.

Who thought it was a good idea to write a POSIX-compliant script with over 4,000 lines just to do all of this and distribute it over the internet? Why? Many Rust crates also depend on C libraries, creating circular dependencies - rust crates depends on C libraries, C libraries again depends on python scripts, then these scripts also call Rust toolchain components. Combine that with Linux distributions, where everything is dumped into `/bin`, `/lib`, and over 2,000 distributions do the same thing with different package management systems or just a different theme.

It's absurd.

Also WTF!

 

[Sam The Ripper]

Good luck with that. Even in FreeBSD's ports, a lot of upstream projects (which FreeBSD doesn't control) have dependencies on rust somewhere. Once you finish dependency resolution, there's gonna be a dependency on rust, just a few hops away from the origin. An unfortunate cancer of Open Source, because removing dependency on rust will require that everybody agree to do that - and good luck going one by one. You'll end up needing to redo the whole computing stack from ground up, because even basic compilers have rust dependencies, even LLVM.

I think GCC managed to escape depending on rust, but other projects were not that stubborn. ?

Well, it mostly depends of what you try to compile. I don't have any Rust software in any of my *BSD machines but macOS, where I use Firefox.
Also, LLVM does not depend on rust. It’s Rust which depends on LLVM.

I think you're exaggerating a bit. Rust is still a niche language. It's growing, yes, but it's not like it took the world and now there is no more C software out there.

 

[Sam The Ripper]

I'm in a dilemma:

* Give up on Rust: Manually handle memory in C and wrestle with cryptic template errors in C++

* Stick with Rust: Hope for a less bloated language and improved toolchain, without adding a bunch of environment variables to my local profile.

Or maybe I should try C++ with Rust-like features. Rust is also currently embroiled in a trademark dispute after python and GNOME. Business as usual I guess. I saw it already with BitKeeper, GPL3, MySQL and Maria, Nvidia binary blobs, Debian non-free, Amazon crap in Ubuntu, secure boot, etc

This is embarrassing.

I think the way rustc is designed feels great, but then Cargo and rustup happened. You end up with even worse than Python-like package management and an installation script that modifies your `.bashrc`, `.profile`, `.config/config.sh` (or Zsh related files), adds custom shell completions for Fish, Zsh, and Bash, and messes with your environment variables.

Who thought it was a good idea to write a POSIX-compliant script with over 4,000 lines just to do all of this and distribute it over the internet? Why? Many Rust crates also depend on C libraries, creating circular dependencies - rust crates depends on C libraries, C libraries again depends on python scripts, then these scripts also call Rust toolchain components. Combine that with Linux distributions, where everything is dumped into `/bin`, `/lib`, and over 2,000 distributions do the same thing with different package management systems or just a different theme.

It's absurd.

Also WTF!

'Re: Integrating "safe" languages into OpenBSD?' - MARC

marc.info

As always Theo de Raadt was right.

 

[Cath O'Deray]

Some great news from the FreeBSD Foundation!

Why laptop support, why now: FreeBSD’s strategic move toward broader adoption | FreeBSD Foundation

 

[Espionage724]

I think you're exaggerating a bit. Rust is still a niche language. It's growing, yes, but it's not like it took the world and now there is no more C software out there.

Yet

Push something long-enough, people cave into the idea, and it spreads. Heck I found out recently that Wayland-Rust is a thing

 

[Jose]

...They created a script that installs rustup, which polluted my environment variables in over 10 places. After a failed rustup installation, my shell kept showing “file not found” errors from the $PATH environment variables. I had to manually locate these files and remove the lines it added to .bashrc, .profile, .config/fish, etc...

Too much magic.

'Re: Integrating "safe" languages into OpenBSD?' - MARC

marc.info

As always Theo de Raadt was right.

Unfortunately some took the wrong message from that criticism:

GitHub - BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respecting your gitignore

ripgrep recursively searches directories for a regex pattern while respecting your gitignore - BurntSushi/ripgrep

github.com

GitHub - pendulum-project/ntpd-rs: A full-featured implementation of the Network Time Protocol, including NTS support.

A full-featured implementation of the Network Time Protocol, including NTS support. - pendulum-project/ntpd-rs

github.com

 

[fr0xk]

Too much magic.


Unfortunately some took the wrong message from that criticism:

GitHub - BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respecting your gitignore

ripgrep recursively searches directories for a regex pattern while respecting your gitignore - BurntSushi/ripgrep

github.com

GitHub - pendulum-project/ntpd-rs: A full-featured implementation of the Network Time Protocol, including NTS support.

A full-featured implementation of the Network Time Protocol, including NTS support. - pendulum-project/ntpd-rs

github.com

Rustaceans got attached early, going all in and now they push their enthusiastic views hard just like some of us do for UNIX. When others disagree, evangelists take it personally. This isn't unique—Windows users bash Linux, Linux users hate BSD, and BSD users throw that shit back. People defend what they invest in, but neither Theo nor Rustaceans are special in this. Theo doesn't fan around OpenBSD (a security focused research operating system according to him) actually. There's several times when he ranted openly because of inconvenience and at lack of any active well researched tangible information from the userbase who use OpenBSD to even able to do anything further.

Theo and I have the same view because we've seen the same issues. Rust claims 'low-level access with high-level ergonomics.' Right now, I can't tell if that's 'the best of both worlds' or 'the worst.'

 

[Cath O'Deray]

With added emphasis:

… push their enthusiastic views hard just like some of us do for UNIX. When others disagree, evangelists take it personally. This isn't unique—…, Linux users hate BSD, and BSD users throw that shit back.

Hatred and standalone dumping might have been commonplace a few years ago. Honestly, I don't know. If I had seen it, would have tuned out and forgotten it.

Coexistence is fine. Cultivate a culture in which people can:

• enthuse about a system
• without feeling the need to dump on another system, another group, or another person.

Get that culture – then, you'll rarely encounter an enthusiast whose evangelism spills over into needless separatism.

Some readers here might remember a past edition of the What is FreeBSD? page that shouted "please don’t call it a Linux distro".

No longer. Quote:

―​

It's not entirely accurate, but I like the Foundation's modernised overview of a project that's more than thirty years old.

I love that none of these is mentioned:

• Apple®
• certification
• Darwin
• distribution
• distro
• iOS
• Linux
• Mac OS X
• macOS®
• packages
• PlayStation®
• ports
• Sony
• Unix-like
• UNIX®
• Unixen.

That's not an entirely accurate list of omissions, because we do have this phrase:

• FreeBSD licensing allows using the code and distribution of proprietary products.

– and the phrase is hidden until after you click Open Source Permissive Licence.

FreeBSD is a distribution, or can be. An umpteenth sprawling discussion about implications of the word distro will not make the operating system more attractive.

The word kernel appears just once, only after clicking Secure by Design.

And so on … learn to love the omissions – less is more ?

 

[fr0xk]

With added emphasis:



Hatred and standalone dumping might have been commonplace a few years ago. Honestly, I don't know. If I had seen it, would have tuned out and forgotten it.

Coexistence is fine. Cultivate a culture in which people can:

• enthuse about a system
• without feeling the need to dump on another system, another group, or another person.

Get that culture – then, you'll rarely encounter an enthusiast whose evangelism spills over into needless separatism.

Some readers here might remember a past edition of the What is FreeBSD? page that shouted "please don’t call it a Linux distro".

View attachment 20525No longer. Quote:

―​

It's not entirely accurate, but I like the Foundation's modernised overview of a project that's more than thirty years old.

I love that none of these is mentioned:

• Apple®
• certification
• Darwin
• distribution
• distro
• iOS
• Linux
• Mac OS X
• macOS®
• packages
• PlayStation®
• ports
• Sony
• Unix-like
• UNIX®
• Unixen.

That's not an entirely accurate list of omissions, because we do have this phrase:

• FreeBSD licensing allows using the code and distribution of proprietary products.

– and the phrase is hidden until after you click Open Source Permissive Licence.

FreeBSD is a distribution, or can be. An umpteenth sprawling discussion about implications of the word distro will not make the operating system more attractive.

The word kernel appears just once, only after clicking Secure by Design.

And so on … learn to love the omissions – less is more ?

This answer is an example of high quality community response in my honest opinion.

Even https://sysdfree.wordpress.com considered *BSD technical focused, and requested migrators to avoid politics

Those prepared to read about the various OS at least some of the above links, as well as man pages and documentation might want to proceed further, those who just want a “works out of the box” system should move on. Those wanting a “just like Linux” system should move on. Those wanting to complain that *BSD isn’t ready yet or is “too difficult”, or “years behind” Linux, should just move on. I could equally claim that Linux is “years behind” Windows or macOS – and in some respects I’d be right. That’s it.

Those who dabble with a *BSD because they ‘hate’ something else – e.g. Linux or systemd, etc should also move on.

The various *BSDs have been built by UNIX professionals for UNIX professionals. We are “along for the ride”, we get to use the free stuff, we don’t really need to complain about it

 

[canihazsekooriti]

Hatred

Hatred = RedHat if you just switch the syllables. :-O

I really wish FreeBSD was able to do (some basic important) things that Linux can. I think I already mentioned it in some earlier reply on the forums here. Crypto + device mapper functionality, for one. It's such a fundamental functionality that is so crucial.

 

[astyle]

Crypto + device mapper functionality, for one. It's such a fundamental functionality that is so crucial.

Now this is something that FreeBSD is very much capable of. It's even covered in the Handbook. Currently, it's chapters 20 and 21, covering disks and disk encryption. Handbook is the officially designated, actively maintained place to start getting familiar with FreeBSD, and what it's capable of.

And if something is not in the Handbook, please feel free to ask on these Forums, and you'll be pointed in the right direction.

Some things are just a design difference between FreeBSD and Linux - like the systemd init system... and then there are things that FreeBSD can do just as well as Linux (like virtualization, storage/file encryption, and more). I think it's kind of useful to know the difference.

 

[canihazsekooriti]

Now this is something that FreeBSD is very much capable of. It's even covered in the Handbook. Currently, it's chapters 20 and 21, covering disks and disk encryption. Handbook is the officially designated, actively maintained place to start getting familiar with FreeBSD, and what it's capable of.

And if something is not in the Handbook, please feel free to ask on these Forums, and you'll be pointed in the right direction.

Some things are just a design difference between FreeBSD and Linux - like the systemd init system... and then there are things that FreeBSD can do just as well as Linux (like virtualization, storage/file encryption, and more). I think it's kind of useful to know the difference.

No, I already asked on the forums. FreeBSD is not capable of plain mode encryption, for example.

 

[astyle]

No, I already asked on the forums. FreeBSD is not capable of plain mode encryption, for example.

You either got some bad answers or misunderstood the answers you got. That's not out of question, since this is a public forum, and there's a good chance that somebody is just pretending to be knowledgeable when in fact they are not. There's also a good chance that it was not FreeBSD Forums where you asked.

Please provide links to where you asked. The answers you got can be either confirmed or debunked that way. My personal suspicion is that somebody misread a manpage. FreeBSD should be perfectly capable of handling any kind of encryption, because it's done in userspace anyway.

 

[Barney]

For the record, I woke up my MAC this morning and started working away; fully integrated with my iPhone and FreeBSD servers.

Nothing proves that “FreeBSD as a desktop” is pure religion than this thread; a desktop OS is supposed to turn on and let you do your work. You shouldn’t have to write python scripts to get it behave properly. I shouldn’t have to compile some port that requires some version of python I don’t have installed, or some PERL library that isn’t the current version in the PKG system.

 

[chrislongros]

I hope that the AMD, Dell and FreeBSD collaboration will significantly improve the desktop usability of FreeBSD

 

[fr0xk]

For the record, I woke up my MAC this morning and started working away; fully integrated with my iPhone and FreeBSD servers.

Nothing proves that “FreeBSD as a desktop” is pure religion than this thread; a desktop OS is supposed to turn on and let you do your work. You shouldn’t have to write python scripts to get it behave properly. I shouldn’t have to compile some port that requires some version of python I don’t have installed, or some PERL library that isn’t the current version in the PKG system.

Agreeing with the statement. FreeBSD is not primarily a desktop operating system; it excels as a command-line OS. Users can configure FreeBSD for desktop use, similar to how Python syntax can be adapted to resemble Rust with types and immutable data classes. But when FreeBSD evangelism promote FreeBSD as a desktop solution, it creates unrealistic expectations for users familiar with Linux. Using FreeBSD on a laptop clearly lacks the smooth experience found in macOS or Windows for applications. FreeBSD serves primarily as a server, appliance, and high-performance operating system, focusing on advanced networking and storage, with its roots in BSD. That's where the money flows in too.

An operating system's value lies in its effectiveness for specific use cases; I suggest to set aside childish Linux bashing "FreeBSD way is better because I feel so" debates and focus on mature, technical discussions grounded in real results. This is getting embarrassing otherwise. Also remember, you become who you hate!

Note: I use FreeBSD on my ThinkPad every day, but I do not speak for the majority of laptop users. I hold great respect for those who invest the time and effort to configure FreeBSD/HaikuOS/RedoxOS as a desktop or multi-purpose workstation alternative

 

[Beastie7]

For the record, I woke up my MAC this morning and started working away; fully integrated with my iPhone and FreeBSD servers.

Nothing proves that “FreeBSD as a desktop” is pure religion than this thread; a desktop OS is supposed to turn on and let you do your work. You shouldn’t have to write python scripts to get it behave properly. I shouldn’t have to compile some port that requires some version of python I don’t have installed, or some PERL library that isn’t the current version in the PKG system.

Shh! You're going to enrage the FreeBSD "desktop" zealots here with that logic.

Btw, the new iPhone mirroring feature in Sequoia is a game changer. The usability gap widens.

 

[LibreQuest]

Agreeing with the statement. FreeBSD is not primarily a desktop operating system; it excels as a command-line OS. Users can configure FreeBSD for desktop use, similar to how Python syntax can be adapted to resemble Rust with types and immutable data classes. But when FreeBSD evangelism promote FreeBSD as a desktop solution, it creates unrealistic expectations for users familiar with Linux. Using FreeBSD on a laptop clearly lacks the smooth experience found in macOS or Windows for applications. FreeBSD serves primarily as a server, appliance, and high-performance operating system, focusing on advanced networking and storage, with its roots in BSD. That's where the money flows in too.

An operating system's value lies in its effectiveness for specific use cases; I suggest to set aside childish Linux bashing "FreeBSD way is better because I feel so" debates and focus on mature, technical discussions grounded in real results. This is getting embarrassing otherwise. Also remember, you become who you hate!

Note: I use FreeBSD on my ThinkPad every day, but I do not speak for the majority of laptop users. I hold great respect for those who invest the time and effort to configure FreeBSD/HaikuOS/RedoxOS as a desktop or multi-purpose workstation alternative

FreeBSD is a masterfully solid OS for running as a "desktop" in my experience. I honestly think that voicing your dislike of the operating system on the forums is not constructive. It appears to me that you want to express negative ideas that are not intended to improve the project but rather to create a negative perception of the project in a certain use case, "desktop", and I believe that's completely unwarranted in the case of FreeBSD.

 

[Cath O'Deray]

… It appears to me that you want to express negative ideas that are not intended to improve the project …

Realism is not always negative.

… when FreeBSD evangelism promote FreeBSD as a desktop solution, it creates unrealistic expectations for users familiar with Linux. …

There's some truth, some reality, in that observation.

The word evangelism is relevant, however discussion has led to disappearance of at least one topic, so let's not over-dissect.

 

[Cath O'Deray]

… focusing on advanced networking and storage, …

The goal of the FreeBSD Project is somewhat different.

the clear and unwavering goal of the FreeBSD Project is not what's in the current edition (of the FreeBSD Handbook)

 

[canihazsekooriti]

You either got some bad answers or misunderstood the answers you got. That's not out of question, since this is a public forum, and there's a good chance that somebody is just pretending to be knowledgeable when in fact they are not. There's also a good chance that it was not FreeBSD Forums where you asked.

Please provide links to where you asked. The answers you got can be either confirmed or debunked that way. My personal suspicion is that somebody misread a manpage. FreeBSD should be perfectly capable of handling any kind of encryption, because it's done in userspace anyway.

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.

 

[fr0xk]

FreeBSD is a masterfully solid OS for running as a "desktop" in my experience. I honestly think that voicing your dislike of the operating system on the forums is not constructive. It appears to me that you want to express negative ideas that are not intended to improve the project but rather to create a negative perception of the project in a certain use case, "desktop", and I believe that's completely unwarranted in the case of FreeBSD.

If you're not a native English speaker or didn’t have time to fully read my previous message, that’s understandable. Otherwise, what you said sounds like the same type of evangelism I mentioned before, which doesn't really help the FreeBSD project. FreeBSD is a general-purpose operating system, not desktop operating system. A general-purpose OS (FreeBSD leans more toward servers evident by tools it ships with - ZFS, PF, IPFW, IPFILTER, Jails, Bhyve, design of rc, design of user/privilege management etc), can serve as the foundation for building other systems on top of it, (for example macOS, GhostBSD, and ravynOS/Orbis OS) either by modifying it's source code or by adding a userland.

One can always modify any operating system (as long as he has access to source code) and extend it's use case. Once I've ported Xorg to FreeRTOS, that doesn't make FreeRTOS a desktop operating system. My smartTV (powered by Linux kernel) has a browser, it plays and stream music & videos. Should I call it desktop operating system then?

I already said, I daily drive FreeBSD myself & I know what I'm dealing with