Posts by MikeTheHill

Re: Why?

> Can someone give me a summary of just what about Rust is causing the translation problems?

Data structures and ABIs. Rust has its own way of representing data structures and its own way of calling functions - it needs this as part of its borrow/checker stuff and possibly other reasons.

That means the cross-over between Rust and C/C++ is a pain as there has to be an unsafe conversion in both directions. And in some cases there are no easy conversions so the C function has to adapt and thus all the callers of that C function also have to adapt.

So if you are completely replacing a standalone C/C++ executable *and* all its dependencies at the same time, then no big deal. But, if you are replacing a single source module in a morass of C/C++ then it's much harder as you have to write unsafe Rust wrappers for every C/C++ function called and for every C function you replace. And you may have to adapt some C functions to suit Rust.

This is why Rust in Linux is so hard as essentially every source module in Linux calls many other C functions so replacing even a single source module with a Rust version requires writing a fleet of unsafe Rust wrappers and potentially modifying the C functions to be more amenable to Rust callers.

Even if someone goes to the trouble of writing a bunch of wrappers to, say, the networking stack in Linux, that's not the end of the job by a long-shot. Quite the opposite in fact.

The question arises as to who changes these Rust wrappers when the networking folk want to change their C interfaces? The networking folk argue they don't know Rust, so they can't do it, but if they push their change to the repo, suddenly the kernel build fails due to the now-incompatible Rust wrappers.

So do the networking folk just sit around and hope there is a Rust developer on hand to respond to their every whim? That's a pretty uncomfortable and risky dependency if you're trying to get your code out the door. Or are the networking folk expected to learn Rust so that they can spend time changing the wrappers? And it's not just the wrappers they'll have to change, they have to change the Rust code which calls the wrappers and the associated test programs. And if one of the Rust tests now fails, who debugs and fixes that?

Whichever way you look at it, the C developers end up with brittle dependencies, stalls in their work-flow, more work and possibly a whole other language to learn that they may not want to learn.

In an Open Source project that unwelcome burden is highly likely to disengage many C programmers, not a great strategy where engagement is already a problem. In an Enterprise environment, you can probably coerce your C/C++ programmers to learn enough rudimentary Rust to support the gun Rust programmers writing the cool stuff, but that is a pretty risky manoeuvre unless you are absolutely certain of the cost/benefits.

Which brings up the resource issue. Once you start down the Rust path, the end result is that ultimately you expect to be able to completely replace your C/C++ workforce with a Rust workforce and that 10 years down the road, when your code-base is predominantly converted, that Rust is still popular with the cool kids. If I were a CTO, I'd want to think long and hard about the implications, costs and risks of that little jaunt into the unknown.

"..just recompile a few million projects".

Excepting that's not how it will work. The rewritten C++ compiler will be much stricter and as a consequence it will barf up an extraordinary number of warnings and errors when compiling exisiting projects because most of those projects will contain code which is verboten in this stricter world. For example any program which uses pointers or indexes into arrays may well fail to compile.

More likely is that if a safe C++ profile can be created a more likely target will be new code, such as that one might put into a kernel wishing to move on from C to something safer.

Re: I've Used GhostBSD

I see this as a feature, not a bug.

Building and testing your application on any *BSD instead of just a Linux is often a great way to discover how many unwanted and non-standard assumptions have crept into your code base.

If your project is well structured with a good amount of automated testing, which they all should of course, it shouldn't take much more than an "rsync; make test" to test on a *BSD platform. This could easily be part of your CI flow.

Reminds me of the old days of SMTP programming. Everyone tested their new code against sendmail and if it worked with sendmail it was deemed to meet the standard. But sendmail accepted all manner of non-standard cruft and was very forgiving. The story goes that when Wietse first connected VMailer (now Postfix) to the net it could hardly exchange mail with any SMTP server or client. Why? Because Wietse wrote to, and tested against, the standards, not to what sendmail accepted.

Same same for just developing on Linux. Bad habits, narrow dependencies and assumptions creep in over time. *BSD can help keep that in check for you.

Re: Why should they feel obligated to refund anyone?

> You bought a product off them, that product no longer works, you can claim a refund

You could argue the product still works, just that you no longer have access to the inputs it needs to run.

If you buy an electric blanket and your electricity gets cut off, do you have a right to a refund on the blanket?

If you buy an Internet connected device and you lose access to the Internet, do you have a right to a refund on the device?

If you buy a twitter app and you lose access to Twitter APIs, do you have a right to a refund on the app?

Electricity, Internet and Twitter APIs are all services delivered by 3rd parties independent of the vendor who sold you product. So where do you draw the line?

FreeBSD13/aarch64 runs on them too!

Yeah, I have stable results running a couple of FreeBSD13/aarch64 pi4b servers. I just use the Raspberry PI Imager app to burn the iso, and Bob's your Uncle.

Mainly running network monitoring and DNS, so pretty light-weight stuff, but perfect for a bit of systemic diversity on low wattage h/w.

I also use them as a cross-platform check that code compiles and runs in different environments. If my applications compile and run on an Intel Debian and a 64bit Arm FreeBSD, I feel pretty confident that I've covered most system dependencies. Important for me as I mainly work in the cli/server space.

Re: Rusty scuppers?

"Not even NASA is stupid enough"

Wait what? I thought we were fixing NASA's design flaws.

Are you telling me that, bear with me here, NASA may have thought about rain when they designed these dishes?

Say it's not so.

Here I was ready to expose my genius level skills by denigrating those stupid engineers and scientists who have deployed the largest dishes all over the planet, and now you tell me they actual might know what they are doing?

This keyboard warrior is so disappointed about a missed opportunity. Anyone got any suggestions for other areas I can excel in? I hear vaccines are big right now. Maybe I'll mosey on over to the immunology department and use my genius to point out their obvious errors.