FreeBSD Working On Improving Its Audio Stack & Creating Graphical OS Installer

[Jumbotron]

Wasn't there an attempt 1-2 decades ago (probably by Debian) to use one of the BSD kernels with linux userland?

There have been a couple of hobbyist projects to do just that. They all died simply because….hobby.

Then there was PC-BSD which while it lasted was quite nice. I used it in the late middle 2000s. But even then it just couldn’t compete with the ease of setup, usage and lack of papercuts that Ubuntu had even back in the day. Now even the founder of PC-BSD and TruNAS threw in the towel and based TruNAS on Debian. This is a true BSD pioneer and evangelist but for his business he left BSD behind for TrueNAS and couldn’t justify the time and resources to continue with PC-BSD, because in the end BSD is never going to be Linux or MacOS or Windows and can never be because that’s the way the BSD engineers want it.

[kylew77]

Aaaaand…right at step one, just stop and leave. C is the new COBOL. It’s only good to know it for maintenance of all the trillions of unsafe lines of code out there. Every major corporation and most militaries have made it a requisite to start new projects only in memory safe code with program by contract protocols as well. C can never be that. Well, without becoming Java or Swift. And don’t even mention that engineering monstrosity C++. If you have to add not one but TWO plus signs at the end of C you have already failed in proper engineering. Even Objective-C is better.

All the BSDs need to be seen from henceforth as the last bastion of legacy Unix where the way of engineering and doing things was set in the 1960s and 70s where C and Bash scripts and X still rule. That time is over. There will still be a discernible market for all that. But an ever shrinking one. This will accelerate from 2026 onward. Why? 2026 will be the year that all major Linux distros, Ubuntu, Red Hat/Fedora and Suse will default to Wayland and in some cases, not even have X installed at all. systemd will continue to rule. Rust will continue its inevitable penetration into Linux kernel code, Linux app code and Linux driver code. OpenGL may even be deprecated in one of the Big 3 Linux distros by 2026 replaced fully by Vulkan. OpenGL has already been deprecated by Unix based MacOS as of 2018. And once OpenGL is deprecated (my guess is that it will be Red Hat) that’s it.

This will leave all BSDs in the untenable state of being nothing more than a legacy Unix way of doing things platform which will also be increasingly a security threat as they hang on to increasingly unsupported, unmaintained and even abandoned frameworks and protocols .

Here is the ONLY future you have BSDs.

Wayland/Xwayland
systemd
Pipewire
Vulkan
Rust and Swift (for those who still must have something C or C++). And replace any Python code in the BSD stack with Go.
Gnome or KDE. Preferably Gnome as it’s the default in most Linux distros and the only two that matter that being Red Hat and Ubuntu. This way someone moving from Linux to BSD or vice versa has an easier go at it. You can still have KDE as an option for anti-Gnome zealots and lovers of Windows 10.

Of course at this point one could argue that all the BSDs should just adopt Linux userland and just become a competing kernel with Linux . I believe that in the end by 2030 that’s what all the BSDs will essentially be. If they want to survive the exodus from BSD to Linux.

Thank God many of us would rather die trying than use Systemd on any BSD! Many of us use a BSD because precisely it doesn't have Systemd. Wayland might be inevitable but BSDs will stive it off as long as possible. Vulkan is actually good and supported on BSDs. C is still king though. There is even a cool song about code in C to the tune of an old Beatles song!

[Jumbotron]

Let me step you right there.

When i was in high school in the 80's I took COBOL, back then our teacher told us it was essentially a dead language and in a few years it would be the way of the Dodo. He told us the same thing about FORTRAN.

Fast forward to today, and not only are they not dead, there is massive demand for both, especially COBOL.

While i have taken classes I am not proficient enough to get a job using it but a state college near me was recently offering free college classes in COBOL on a first come first served basis to their students because there is such massive demand for it and all the current COBOL programmers are retirement age.

IBM's new z16, the only computer in the world capable of quantum safe encryption uses COBOL and these mainframes are being used by major police departments across the country as well at the DoD.

COBOL isn't going anywhere.

Thanks for making my point without realizing it. C is exactly now what COBOL became and still is. A zombie language. COBOL only exists to service the long since zombified code base in major financial, insurance and governmental agencies since the 1970s. The potential for pitfalls and huge failures in a complete rewrite of such crucial and scaled out systems that would affect entire sovereign entities breeds an inertia that is almost impossible to overcome. It’s the same for C. Trillions of lines of increasingly unreadable, unmanageable and insecure lines of C code make up the system architecture of the majority of the world’s compute platforms. That doesn’t me that C is still viable for the next 50 years because clearly it is not. You can’t make C more readable, manageable, safe or robust without making it like Swift and at that point just use Swift since it can natively read C and C++ so you can transition your code in while reengineering everything in C. And if you need to start from scratch writing a new system or kernel there is no reason under the sun you don’t start with Rust. Or even Swift. Hell, I’d rather write a kernel in Ada than C.

But don’t be butt hurt with me. Every major corporation including systems corporations like Microsoft and Apple and Google and Meta and government agencies like the American DoD have handed down the edict that all new projects will NOT…I REPEAT NOT start with C. In other words C is now functionally deprecated at all those orgs and more. Which means C is a legacy language only needing to be known for the next 50 years like COBOL….for maintenance purposes only.

[Jumbotron]

Thank God many of us would rather die trying than use Systemd on any BSD! Many of us use a BSD because precisely it doesn't have Systemd. Wayland might be inevitable but BSDs will stive it off as long as possible. Vulkan is actually good and supported on BSDs. C is still king though. There is even a cool song about code in C to the tune of an old Beatles song!

Thank God BSD will die because they don’t use systemd. C is now deprecated by every major systems corporation in the world, Microsoft, Google, Apple, Meta and the US government and the military. The Linux Kernel is slowly but surely moving to Rust as is many Linux apps and drivers.

The 1960s are over. All those guys are dead or dying. Their way of doing things, their architectures, their protocols, their languages are deprecated if not dying as well. Where they are still being used it is simply because of inertia and sunk costs. But it is demonstrably evident that C is deprecated and now is being looked at as a legacy language for systems architecture, kernels and apps. Just as Unix had been deprecated by Linux and Linux like MacOS is shedding its Unix heritage. This is a good thing .

[sophisticles]

But don’t be butt hurt with me. Every major corporation including systems corporations like Microsoft and Apple and Google and Meta and government agencies like the American DoD have handed down the edict that all new projects will NOT…I REPEAT NOT start with C.

Feel free to link to just one such edict.

[Jumbotron]

Feel free to link to just one such edict.

https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages

https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

https://security.googleblog.com/2021/04/rust-in-android-platform.html?m=1

This one from Meta shows that although C and c++ are supported Server side languages it’s hilarious they only mention C and C++ that way. After that announcement they never mention C or C++ again it’s all Rust for server side and Hack and Python for business logic with some others like Java thrown in as a mention.

https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/

https://twitter.com/markrussinovich/status/1764742104339898636

[User29]

Let me step you right there.

When i was in high school in the 80's I took COBOL, back then our teacher told us it was essentially a dead language and in a few years it would be the way of the Dodo. He told us the same thing about FORTRAN.

Fast forward to today, and not only are they not dead, there is massive demand for both, especially COBOL.

While i have taken classes I am not proficient enough to get a job using it but a state college near me was recently offering free college classes in COBOL on a first come first served basis to their students because there is such massive demand for it and all the current COBOL programmers are retirement age.

IBM's new z16, the only computer in the world capable of quantum safe encryption uses COBOL and these mainframes are being used by major police departments across the country as well at the DoD.

COBOL isn't going anywhere.

this was interesting to read. the only question is, that is this the same cobol as it was in the 70s?

i know people who are still occasionally write cobol code but mostly for providing interfaces for modern programs or interfaces to support migration to a new version of the same program written in a modern language.

i used to work for a quite big bank which at that time was very rapidly abandoning such legacy stuffs like solaris, os/400, cobol and rpg for modern hw/sw which was equally reliable and incomparably cheaper (hw, os, developer wages).

[User29]

Trillions of lines of increasingly unreadable, unmanageable and insecure lines of C code

I grew up reading scifi, so I still believe that one day we'll see an AI (LML, whatever) that will be capable of churning through this vast amount of code and producing the better (fixed, optimized, more secure) version of it in a modern language.

[roviq]

The 1960s are over. All those guys are dead or dying. Their way of doing things, their architectures, their protocols, their languages are deprecated if not dying as well.

You were able to read this reply thanks to TCP/IP a protocol created by those 1960s guys, one of which even went out and co-created Go. Respect your elders.

And yes, memory-safe languages are coming strongly and will probably replace C, and that's great, but it will not happen this decade. C is alive and well, and it needs to be maintained, the world runs on it, in many of the rankings by many metrics it is prominently in the top among C++, Java and Python. Deprecated, nope, not at all. New C code is being written every day by the thousands of lines.

It is even worthwhile today to go to college this year for four years and learn C, maybe not for writing code, but understanding the trillions of lines of it, and then port it to modern languages.

[roviq]

I agree that memory-safe languages are the way to go, and I have enjoyed using Rust in trial runs, but these links are not edicts or mandatory/regulatory bulletins at all, mostly recommendations.

https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages

Urges != Mandates

https://devclass.com/2022/09/20/microsoft-azure-cto-on-c-c/

Should be deprecated != Will be deprecated

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

"NSA advises organizations to consider making" != "NSA mandates"

https://security.googleblog.com/2021/04/rust-in-android-platform.html?m=1

Not an edict, just a tour of how Rust could help in the Android platform in 2021 (they already use it https://source.android.com/docs/setu...dules/overview), but they are not dropping C/C++ in the foreseeable future.

This one from Meta shows that although C and c++ are supported Server side languages it’s hilarious they only mention C and C++ that way. After that announcement they never mention C or C++ again it’s all Rust for server side and Hack and Python for business logic with some others like Java thrown in as a mention.

https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/

Meta develops and maintains many projects written in C, one of the most useful ones, with a lot of adoption is Zstd, written mostly in C, which they heavily use internally: https://github.com/facebook/zstd

https://twitter.com/markrussinovich/status/1764742104339898636

Agree, there is a consensus, and is the way forward, but still not an edict nevertheless, new C code is and will be written daily. Also, they stipulate "Google recently announced a $1,000,000 grant to the Rust foundation to enhance interoperability with C++ code.", which means Google expects C++ to be there for long while.

I don't see and we will likely not see something like an edict forged in mount doom that binds all developers to abandon C. There is an economic factor to all these things, and while in the long term to use memory-safe languages is optimal and will reduce security maintenance up to a point (See below *), it doesn't make sense economically to trash all existing code and start anew, it will happen very slowly, with projects like the Firefox components, Redox, and uutils.

C will be continued to be used and maintained for many years if not decades. Many of us work developing new drivers in C for the Linux kernel for example, it would be nice to do so in Rust, but as of today there isn't maturity in that area, they just integrated the tooling for it in the kernel about a year ago, without much adoption (I think the Asahi/Apple hardware only so far?).

(*) And Rust with all its memory-safety features isn't a silver bullet, for example it got a perfect critical vulnerability of 10 with this CVE: https://nvd.nist.gov/vuln/detail/cve-2024-24576

So, it will be nice, I agree it is and should be the future, but it is not happening now in 2024. Much less by edicts!