Yeah, that’s kind of the advantage and disadvantage of Markdown. It’s so simple that alternative implementations can be easily created, which helps with adoption. But because those alternative implementations exist and because there is a need to add more features, those alternative implementations will see custom changes for the format, ultimately making the format less standardized.
Yeah, it doesn’t make a whole lot of sense here. Codeberg uses a Markdown flavor which honors single line breaks and it kind of surprised me how well that is working. Like, if you’re used to Markdown, you can put those two spaces and they’re just ignored. If you’re not used to Markdown, it works like you’d expect.
I guess, the downside is that either each client needs to configure their Markdown renderer to behave like that, or I guess, the server software has to pre-process the Markdown to add in the double-spaces.
That’s more of a problem for Lemmy than it is for Codeberg, because there is a number of different clients available.
It’s the way Markdown works, for reasons, which is what Lemmy uses for its comment syntax.
If you want a regular line
break, you can put two spaces
at the end of a line.
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?
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.
The difference is the amount of trash and that more of it is not organic, so will not break down. A small hole in someone’s garden, which largely decomposes over a few decades, is a very different thing than a mountain filled with trash that stays there for the next generations.
For example, groundwater can get contaminated by landfills, if they’re badly planned, or when an earthquake tears the ground under them apart.