It is kinda offtopic here, but as a pythonist since 2002, having built (and still building) huge things in it — cue in the mandatory "python is not a programming language" opinions —, I am way more concerned about the "governance" about these "new and more modern" languages.
Remember that C & Pascal were once the new kids on the block and the old timers wanted to continue using Fortran & PL/I and what not! Even earlier, there were people arguing that real programmers use assembly languages! New languages succeed or fail not solely on their merit but based on how many people end up using them, which is a function of whether they are a good fit for the programs of a given era, any “killer apps” written in them (as unix was or use of javascript in browsers), free compilers/interpreters, enthusiasm, lack of the same for older languages, support, whether “influencers” of the era praise and use them, politics, etc. etc. Also market conditions. I think Lisp certainly suffered after the second AI winter. So did Prolog. And the new AI uses Python!
www.theregister.com
Hey, can you link to that, please?
).
From: Alan Somers <asomers_at_freebsd.org>
Date: Sat, 20 Jan 2024 16:51:25 UTC
In a recent thread on src-committers, we discussed the costs and
benefits of including Rust code in the FreeBSD base system. To
summarize, the cost is that it would double our build times. imp
suggested adding an additional step after buildworld for stuff that
requires an...
Wow, now this is solid, technical information instead of uninformed political camp crap.Knock yourself out:
The Case for Rust (in the base system)
Note that this is about Rust in the base system for userland programs, not for the kernel (yet
Code:From: Alan Somers <asomers_at_freebsd.org> Date: Sat, 20 Jan 2024 16:51:25 UTC In a recent thread on src-committers, we discussed the costs and benefits of including Rust code in the FreeBSD base system. To summarize, the cost is that it would double our build times. imp suggested adding an additional step after buildworld for stuff that requires an...
Easy. Done. FreeBSD is written in C which solves real-world issues daily.
No because we use the same wpa_supplicant, written in C, which is fairly spot on in Linux."Is memory safety the reason that /etc/wpa_supplicant.conf is so uncooperative in FreeBSD???"
FreeBSD doesn't use coreutils. Thus the uutils won't be a drop-in replacement. It does use the MIT license though rather than GPL.
I suppose the difference is that they were adopted very rapidly (admittedly there wasn't much competition back then). Rust has been around for over a decade now and people are still just in the talking / wrapping C libraries stages.
So, where are YOUR patches? Does FreeBSD actually support AC wifi at this point thanks to them? Show me your code, buddy.
If BSD straight-up copied the wpa_supplicant code, written in C, from Linux, how come Linux is so much better at handling wifi?
Easy. Done. wpa_supplicant already supports AC wifi (written in C). What you are waiting on is drivers. As I described above, the wait for these is not due to language choice. More like FreeBSD doesn't have such support from companies like Intel.
Drivers.
They decided against it. If you read through that mailing list thread, you will see the rebuttals against Rust.
Which is bullshit, I have Intel wifi cards. FreeBSD has perfectly working drivers, and Linux still handles exact same wifi hardware better than FreeBSD. How come the wpa_supplicant is uncooperative even with drivers that are well-known to work? Maybe it's not the drivers?
So, what's the holdup if we're 75% of the way there?We are waiting on our Linux abstraction layer to be finished for iwlwifi(4), so we can use the same drivers written by Intel (for Linux). We are ~75% there. Rewriting it in Rust we are 0% there
No it doesn't. They don't support AC or (in many cases) roaming... You just said earlier in the thread! You do understand that a driver can "work well" but still not support every feature of the hardware correctly right? They do lack a few features, some of which you are clearly running into and blaming the wrong part of the operating system.
No. Its the drivers. AC support literally isn't complete within them. Read through the code. If by uncooperative you mean other things, then see next point:
Since wpa_supplicant is the same tool as what is working fine with other drivers and with Linux, suggests that the roaming support from the driver layer isn't in place to notify wpa_supplicant to reassociate. Remember that wpa_supplicant is just the userland counterpart, it is only as good as the stack below it. Likely lots of the required events, interrupts, etc are not in place. Our drivers are great but not perfect and nowhere *nearly* as developed and maintained as on Linux.
Oh right. Just a bit more time learning about wpa_supplicant solves it. Just be glad that we aren't using Linux where IWD is probably right around the next corner and we will need to re-learn everything again. If you don't want to use the underlying tool directly, perhaps you can find a GUI that interacts with the wpa_supplicant control socket for you?
Man power. Wifi is complex and we have relatively few developers on it. Bjoerne Zeeb was taken on by the foundation to get much of it in (Intel driver layer) and was also working on the Raspberry Pi wifi driver too if I recall
Can you give any specifics? The only thing I can think of is that memory correctness can't be verified. Turing completeness doesn't make that a necessity.
Some languages are more succinct, sure. Means very little though. Even Rust is very much a more suitable language to use in a kernel than Ruby.
whatisnuclear.com
The OS can't really do it. Sure it can use the MMU hardware, mprotect(2) / detect accesses outside of the process but imagine the following:
{
int somearray[10] = {0};
int explode = 0;
somearray[10] = 1; /* out-of-bounds write */
/* explode is now 1! */
}You realize that you have just fessed up to the shortcomings of C and the very reason that devs are considering Rust?
From the mailing list (Actually the very message that this thread linked to!), one of the things mentioned as "Impossible to do in C" is
Yeah, I guess my issue is basically "Roaming". Isn't it the job of wpa_supplicant to automate it, like everybody else already does? Even if it's ultimately not the fault of the FreeBSD wpa_supplicant implementation, roaming is an important aspect of wifi usage at all, and does deserve to be automated.