I expect Rust to be inevitable in embedded development, but yeah, that space moves slow, so give it another ten years or so. I will say that embedded is practically jumping on Rust, compared to how glacially it normally moves. You’ve got big vendors committing to offering Rust APIs, because many of their customers just don’t want to code C/C++ anymore.

I’ve been enjoying Fira Sans and Fira Mono for far too long: https://mozilla.github.io/Fira/

On openSUSE, I’ve apparently got at least this thing for looking at SystemD services:

Allows viewing the services for the different boot targets, as well as the service files. You can also start/stop services or change their start mode (on boot vs manual).

Well, and there’s a JournalD viewer with filtering:

Not the most developed GUIs, but…

Yeah, I guess, at some level this is satirizing that technical interviews almost demand golf code. When you’re writing such a small program, there’s an upper limit of how good “good code” can be. To look better than other candidates, you need to apply ‘clever’ (derogatory) strategies, where you solve it with a slightly more efficient solution. No one would care about this efficiency in a real-world scenario…

Goddamn, I realized this was referencing the Microsoft forum just from reading the first paragraph and I’ve hardly used Windows in the last decade…

I guess, this is why they think the incessant rambling from ChatGPT is in any way acceptable.

I mean, Rust has the additional thing that a reference is a pointer + a borrow, so it’s not quite as similar to a pass-by-value.

And as for the dereference operator, occasionally you can use it to turn a reference into an owned value, often by making a copy of the value (but in that case, you can usually also use .to_owned()).

A case where I don’t think there’s an alternative to the dereference operator, is if you’ve got a mutable reference and you want to replace the value that’s underneath: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=04621490e1d0fd6fe1af7f2e843547fb
At the very least, if you remove the asterisk, the compiler will tell you very precisely that you need to add it back.

I think, your expectations are off for what a native integration would achieve. A kernel which has both a Linux API and a Windows API would be an insane maintenance effort. You’d naturally want the Windows APIs to simply be translated to the respective Linux API calls. This is what WINE does.
In theory, if it’s directly integrated, you could do some dirtier stuff, i.e. call kernel-internal APIs, but you want to avoid that as much as possible, since those kernel-internal APIs are not nearly as stable as the public APIs.
It should also be said that writing kernel-level code is hard. You cannot ever crash, you cannot ever make mistakes when managing memory, you cannot allow yourself any vulnerabilities. Again, you want to avoid writing kernel-level code, if you can.

WINE has some additional ugly workarounds, like a virtualized filesystem. There’s not terribly much you can do about that. Windows applications may simply expect certain folders to be in certain paths. You can’t directly map that to a UNIX filesystem.

As far as I can tell, pretty much the only advantage of natively integrating it, would be that it’s installed by default, which can be achieved in other ways (distros), and due to those ugly workarounds will not be popular at all. As much as I’m touting its horn right now, I do not want WINE on my system, unless I need it.

It’s easy to be frustrated with WINE, because it does not handle all applications perfectly, and then think that the approach is just wrong. But yeah, no, some really smart folks came up with that approach. It’s just insanely hard to get the exact (undocumented) behavior of the Windows kernel APIs correct, whether you do a mapping or implement them natively.

Zero-setup snapshotting, GUIs for system settings, more sophisticated repo management, less custom-patching of software, more utilitarian than minimalist.

I mean, yeah, I wrote it kind of humorously up there, but I do actually think state diagrams are a good idea and modelling the known error paths is part of real software engineering.

However, I’ve never been in a project where anyone knew nearly enough about what we’re supposed to build, to be able to draw a state diagram before we got started. We would rather do a refactoring halfway through and then we would design a state machine to fit the requirements…

One time, we were drawing a state diagram of how the core loop in our application should behave. So, you know, first you have the preparation state, then when that succeeds, you go to the getting-things-ready state, then into the actual doing-things state, then the result-reporting state and so on. So, there was exactly one happy path.

Then we figured, we should also diagram all the error scenarios. If an error occurs in the preparation state, we should transition to the result-reporting state. But if an error occurs in the getting-things-ready state, we’ll need to go to an intermediate cleanup state before we go to the result-reporting state, and so on.
As we added more and more error paths, the arrows had to curve more and more, until the whole diagram eventually looked like an onion. That’s when I knew, we were doing real software engineering. 🙃

To me, it’s just death by a thousand papercuts. It doesn’t have any unique selling points that I’m aware of, and it’s slightly worse than my preferred distro in every way that the two differ, at least as far as I can think of.

My mum had these dried chili flakes, which were a few years past their best-by date. And honestly, I couldn’t imagine these really going bad, so long as they remain dry. I mainly tasted some before throwing it into my food to test whether it even still tasted hot. But yeah, they were good.

Never quite knew what to do with these, when I still lived there, but that made me consider buying some. I cook with more veggies now, where the chili really hits the spot.

That honestly feels like a random, implicit thing a very shallow-thought-through esolang would do …

Nope, you’re far from the truth there. Most functional programming languages have this feature, but it’s also definitely not shallowly-thought-through, as it’s essentially an extension of how maths works.

Basically, in most cases when you see braces { } (excluding things like for-loops and imports), you can think of them as an expression, where the whole brace-scope will evaluate to just one value, similar to how “3+5” evaluates to a value. That one value is this last value at the end of the brace-scope.

So, to give a very simple example:
{ 3 + 5 } / 4 evaluates to
{ 8 } / 4, so then the whole brace scope evaluates, which gives us
8 / 4 and that’s then
2.

In maths notation, you know that as (3+5)/4, with parentheses instead of braces.
Within this simple example, they do the exact same thing (and Rust does also allow you to use parentheses for this purpose).

Where braces and parentheses differ, is that braces allow you to write multiple statements within them, so in theory, you could do:

{
    let x = 3;
    x + 5
} / 4

Obviously, this is where this simple maths example largely stops making sense, but in real-world programming, there’s a lot of use-cases for this.

It does take some getting-used-to, when you’re coming from hardcore procedural languages like C/C++, but yeah, it’s really not new for anyone who knows maths.

I did consider posting a screenshot of just all the applications on my PC… 🙃

But yeah, not much OP can do with hundreds of recommendations that don’t work on their OS.

Reminds me of how frequently folks get color blending wrong (using linear blending results in darker colors). Or also volume sliders (using a linear scale results in much stronger volume changes near supposedly-silent volumes).

It just looks/sounds vaguely right and then no one ever questions it…

Oh wow, did they maybe search for someone with skills of a “server” and the Indeed algorithm soup got that mixed together with skills in server technologies…?

I know that QMMP has a built-in visualizer, and the webpage says that the visualizer is call projectM, which you can apparently also run standalone: https://github.com/projectM-visualizer/projectm

Today, a colleague couldn’t do docker login for an internal registry. Constantly got an error which just said “unauthorized”.
The password couldn’t be the problem, because you actually generate a token on the registry webpage, so we tried all the different ways to spell his username (uppercase, lowercase, e-mail address) and tried different URLs for specifying the registry, tried toggling the VPN, a reboot etc., even though we knew what should work, because the login worked for me.

Eventually, we gave up and figured there must be some permission problem in the registry. Ten minutes later, he tells me that it works, without doing anything different. Now I’m wondering, if the IT saw our desperate login attempts and quickly fixed the problem. 🫠

It won’t rise much beyond that, since you only get one update per package. Whether it’s upgrading Firefox from version 120 to 121 or to version 130, it doesn’t change much in terms of download size, nor the number of updates.

At least, I assume, Arch doesn’t do differential updates. On some of the slower-moving distributions, they only make you download the actual changes to the files within the packages. In that case, jumping to 121 vs. 130 would make more of a difference.

If you do want lots of package updates, you need lots of packages. The texlive-full package is always a fun one in that regard…

Thanks. 🙂