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.
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 BusyBox aims for). That's good, if distros start shipping it then. It's not really something normal users would install themselves...
Well, I mainly mean that they'd need to put in quite a lot of work to make the existing Oblivion mods work with it or to develop a new modding API. I doubt, they'd put that much work in for a cash grab remaster/remake.
I mean, I have heard of some weird constructs before, where games used their own engine for physics and whatnot, and only used Unreal for rendering. If that makes sense for them to do, that would preserve support for most mods.
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. 🙃
The thing is, the age of the engine doesn't say anything. The Unreal Engine started its development before 1998. But you do have to put in work to upgrade an engine over time and Bethesda doesn't have Fortnite money for that.
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.
At $DAYJOB, we develop an application for basically linking up low-level devices over the internet. And yeah, in one codebase, we have:
A backend
A distributed system client/peer
A CLI
A web frontend
And simulation software to flash to those low-level devices
All of that is in Rust, so it's not just not wanting to learn different languages, it's genuinely useful.
We can use the same model types in the various clients and the backend, meaning it's compile-time guaranteed that they work together. Just as well, we can generally use the same libraries. And while e.g. the web frontend and low-level software use frameworks, making it not entirely trivial to just jump into that part of the codebase, the barrier for entry is a lot lower.
And yeah, ultimately that flexibility is something I find hard to give up, especially when customer requirements are as nebulous as they usually are.
Honestly, we never had a hard reason why we should be using Rust. It was just that maybe we'd need such low-level simulation software, maybe we need the performance to process each individual network package, maybe we need to do things in the Linux kernel. The rest was just that we wanted to use Rust, because it's a cool language.
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.
No, it just isn't.
If we're somehow talking about an orchestra made up of lots of trumpet players being louder than a traditional orchestra, like alright, but then we still gotta figure out what it actually looks like in an orchestra. Does this new transistor actually use less space, for example? What's the price for it? And so on...
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...?
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.