• 4 Posts
  • 73 Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle
  • 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.


  • 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.



  • 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?




  • 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.





  • 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.






  • 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.