Rust dev, I enjoy reading and playing games, I also usually like to spend time with friends.
You can reach me on mastodon @sukhmel@mastodon.online or telegram @sukhmel@tg
That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive. Only Linux kernel isn’t a bank, and maybe will not have as much money to pay to rare developers capable of maintaining C codebase
The hard part is “that add value”. Not only it’s hard to measure, but highly depends on scope of what is done
Cosmic balance, sort of 😅
I forgot that last time was in 2023, although the previous one was in 2016. SO had a lot of moderation drama and point-grinders that (imo) led to community becoming more toxic, to the point where it’s not too pleasant for me to participate in.
To be fair, they still have some good answers, and sometimes they can provide a useful answer, but edge-case rare obscure problems that seemed to be the very reason for SO are rarely answered now, as I see it
Sort of, but e.g. in case of MacOS you’ll have some apps that can’t be installed as Nix packages and some things that can’t be configured in OS
Also was not mentioned, since every dependency is unique you should have no trouble discerning versions that look the same, but in fact configured different or depending themselves on different versions of things, and introducing breakages that way. If you find that some specific configuration of dependency is causing you trouble, you can switch to a different one even if another package depends on this troublesome version.
I’m not familiar with slackware but why is specific kernel called generic, while generic one is not called generic? I’m puzzled
The main issue is that it tries to fix government trust issues with private actors trust issues. It’s still trust issues
only one man understood that thing
You will not, indeed, it’s going to be abstractions all the way down from now on
It’s easier to fix bugs that you just introduced to be able to cover that KPI, too 🌚
True, there is a spectrum of options, and some will work much better than what we have now. It’s just that when I read about holding people accountable I don’t quite imagine it’s going to be implemented in the optimal way, not in the first hundred years or so
That’s just covering up, like a disclaimer that your software is intended to only be used on 29ᵗʰ of February. You don’t expect anyone to follow that rule, but you expect the court to rule that the user is at fault.
Luckily, it doesn’t always work that way, but we will see how it turns out this time
with billions of dollars in losses
But the real question we should be asking ourselves is “how much did tops saved over the course of the years without proper testing”
It probably is what they are concerned about, and I really wish I knew the answer to this question.
I think, this is absolutely not the way to do business, but maybe that’s because I don’t have one ¯\_(ツ)_/¯
This might help in some regard, but this will also create a bottleneck of highly skilled highly expensive Engineers with the accountability certificate. I’ve seen what happens when this is cornerstone even without the accountability that would make everything even more expensive: the company wants to cut expenses so there’s only one high level engineer per five or so projects. Said engineer has no time and no resources to dig into what the fuck actually happens on the projects. Changes are either under reviewed or never released because they are forever stuck in review.
On the other hand, maybe we do move a tad bit too fast, and some industries could do with a bit of thinking before doing. Not every software company should do that, though. To continue on the bridge analogy, most of software developers are more akin to carpenters even if they think about themselves as of architects of buildings and bridges. If a table fails, nothing good is going to happen, and some damage is likely to occur, but the scale is very different from what happens if a condo fails
Well, you can make daily a torture, too
But really, feels good when there’s time to actually work instead of just talk
No, that was what I meant, I thought they didn’t, I was wrong, it turned out
Made easier to use like in when their codebase was leaked and no one had successfully built a game from it?
in-house tools often encourage making a mess heavily reliant on those tools or working around their limitations, in my experience
Oh, it impacts indeed. And I would expect that to be partially to keep the devs from hopping away, as they will have a hard time transferring
On the other hand, onboarding is longer and wastes more time and money of the company ¯\_(ツ)_/¯
I would say, the easiest path is: use it, and if you find something lacking of incorrect, report and maybe help fixing/testing. Even on this path may lie quite a lot of obstacles, though
Unfortunately 😅