Oh, it said “By ~2026, it will be 100% compliant”, which seems to just be an estimate based on the trend for how many tests they passed over the past years. My bad.
But yeah, probably still useful to get it onto real systems now to find any other remaining bugs.
Yeah, which is why pairing works so well. Suddenly, you’ve got two people who were there when it was created and might know why certain design decisions were made.
Which is why making code readable is so very important. Our juniors and students will think we’re ridiculous, when we spend a long time cleaning up some code or choosing the least misunderstandable name for a type. But you fuck that up and then others, as well as your future self, will be wasting many more minutes misunderstanding what your code does.
Spamming comments is rather controversial, especially in high-level languages. Problem is, they only show up in one place, so they’re just not very useful, but also have a high chance of becoming inaccurate over time. In particular when you spam them to explain relatively trivial stuff, people will stop reading them, meaning they won’t update them.
The ‘what’ can be documented with meaningful variable/function names, log/error/assert messages and perhaps most importantly unit/integration tests (which should be understood like a specification that checks automatically that it’s applied correctly).
Comments are indispensible for explaining the ‘why’, though, whenever that is not obvious.
Worst part is when the un-refactored code continues to confuse other devs, meaning it keeps causing additional work, but you still don’t get time to actually fix it.
Heard just this week that uutils apparently has 100% compatibility with the GNU coreutils (so more than musl aims for). That’s good, if distros start shipping it then. It’s not really something normal users would install themselves…
My workplace set up a social event to get people to talk to each other and watching management try to name it without calling it “alcohol consumption event” has been very funny. I think, they eventually just gave up and it’s now called “After Work”.
That’s kind of the problem. If it was before work, they could name it after a more socially acceptable drug: Morning coffee. 🙃
Your donation money does not go towards the salary of the Mozilla Corporation CEO. But yes, it does not go to Firefox development either. The Mozilla Corporation, which develops Firefox, needs to have enough money independent of donations, because the devs’ livelihoods depend on that. Well, and the donation money isn’t nearly enough to cover those costs anyways.
So, the Mozilla Foundation (which owns the Mozilla Corporation and which you donate to) uses the donation money instead for political activism, for community work (which may lead to more contributors to Firefox) and sometimes they award some of that money to other open-source projects, which are also vital for an open web, but which are not visible enough to collect donations.
It is kind of cool, when you’ve actually written your own software and use that. But realistically, I’m still getting the compiler from the internet…
Sure, but so it’s still non-sensical to compare a transistor to a whole chip. That’s like saying a trumpet is louder than an orchestra.
Am I stupid or is a transistor a very different thing from a chip? Like, a chip has lots of transistors on it, but comparing them is still rather non-sensical…?
Well, I did mean accessible in terms of feeling semi-confident to contribute to a project with users. If you end up writing code that takes longer to review than it would’ve taken the reviewer to write it themselves, that’s always kind of unfortunate…
Yesterday, we had a presentation at $DAYJOB, where we showed off our software project at a high level to another department. That department does lots of low-level work, including with C.
A team lead from that department, who knows our project, had provided the initial draft for the presentation slides. And they threw a sentence at the end of the slides “By the way: $PROJECT powered by Rust”. We were also not the only project there, which explicitly mentioned Rust, even though it wasn’t strictly relevant.
And yeah, that’s just kind of insane to me. When even management understands that their techies get excited about working with Rust, that’s not anymore just a few select voices that call for it. That’s a whole department discontent with C, where an alternative is presented.
Which is why I would be extremely surprised, if not something similar happened with the Linux kernel.
Obviously, those who’ve coded C for twenty years might not understand the issue, but there’s so many people for which low-level development becomes accessible for the first time with Rust. The stream of people wanting to contribute Rust code will just not cut off any time soon.
Well, I don’t know what we’re counting here. Generally, if FOSS apps have notifications which one might perceive as annoying, they’ll have a checkbox in the in-app settings, so I don’t need to *block* them.
There is one scenario, where I’ve blocked notifications, which is when an app wants to run in the background, then it has to put up a permanent notification. I hadn’t counted that, since that’s an Android requirement.
Aside from that, IMHO it’s pretty clear-cut whether notifications are either necessary or subjective or not a good idea, so apps with user interests in mind can get that right quite well.
Well, it shouldn’t. Both C and Rust can achieve the same performance. There’s also no overhead for calling Rust from C or vice versa. Theoretically, some detail-optimizations look less horrid in C, but on the other hand, writing parallel code is significantly easier in Rust. Graphics drivers tend to be all about parallelism, although I can’t say how relevant it actually is in this case.
Having said that, it is likely that the initial versions of this new driver will have worse performance, until the code base matures more.
I only use FOSS apps, so never had to block any apps from sending notifications.
Sure. If I knew what the scope of this offer even was, I might have suggested doing that.
To be fair, the contract has a statement in there, that we don’t actually have to complete the features written down, we just need to put in the amount of work that this money pays for. The customer is more or less within our own company, so it’s not like anyone’s going to sue the other side anyways. But yeah, it still just feels weird to hear management talking about fictitious features for a random amount of money.
Sometimes, I am worried that if the customer is dissatisfied one day, that management will be angry at us for giving such a bad estimate, even though we didn’t. For example, as far as I’m aware, the current offer contains the complete list of features from a meeting where we explicitly brainstormed what would still be required. We did not discuss how much of that we could complete within the budget we’re given. But if I now notice that management is offering the whole list for far too little money, am I supposed to intervene or are we doing the bullshit charade again?
One time, some person from high up the hierarchy came to our department meetup. So, a room full of people who have this job, because they enjoy coding. And the guy said something along the lines of “with AI, you won’t have to do coding anymore” like that’s a good thing. Yeah, dude, wrong audience for that speech…
Last week, we sent out an offer for 102k and then the customer asked us, if we can please lower it to 99k, so they don’t have to go to their boss to get clearance.
Logically speaking, that is not how any of this works. It’s still going to need the same amount of budget to complete the task. But no one asked us devs how long it’ll take anyways, so I guess, that’s not my problem after all.
Hmm, I wonder what the idea with the Rust interface is. There is already a Rust wrapper for the C library libgit2 (libgit2-sys) and a well-maintained library with a nicer/Rustier API on top of that (git2).
I’d expect libgit2 to be pretty much just an API around the code that’s within Git anyways. So, is the Rust interface that again, just in Rust?
I guess, you don’t need to take the route through libgit2, so potentially less things that can break there? Maybe they can somehow offer a nicer Rust API when they have internal access? Or maybe they’re just thinking, we want to official support Rust anyways, so might as well move the maintenance work into our code base?