Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc
Posted Dec 6, 2019 19:22 UTC (Fri) by nim-nim (subscriber, #34454)In reply to: Soller: Real hardware breakthroughs, and focusing on rustc by Cyberax
Parent article: Soller: Real hardware breakthroughs, and focusing on rustc
It "scales" because you do not maintain anything, you just push code blindly.
Distributions do not only push code, they fix things. When you fix things, keeping the amount of things to be fixed manageable matters.
If you don’t feel upstream code needs any fixing, then I believe you don’t need distributions at all. Just run your own Linux from scratch and be done with it.
Please report to us how much you time you saved with this approach.
Interested? I thought not. It‘s easy to claim distributions are inefficient, when adding things at the fringe. Just replace the core not the fringe if you feel that’s so easy. You won’t be the first one to try.
Posted Dec 6, 2019 19:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
> It "scales" because you do not maintain anything, you just push code blindly.
There was also a mechanism to deprecate versions to nudge other teams away from aging code, recommendation mechanism, etc.
> Distributions do not only push code, they fix things. When you fix things, keeping the amount of things to be fixed manageable matters.
> If you don’t feel upstream code needs any fixing, then I believe you don’t need distributions at all. Just run your own Linux from scratch and be done with it.
Posted Dec 7, 2019 8:58 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
And that’s exactly what major distributions do, when the language tooling makes it possible without inventing custom layouts like Nix does.
Upstreams do not like distribution custom layouts. The backlash over Debian or Fedora relayouting Python unnilateraly, would be way worse, than the lack of parallel instability in the upstream Python default layout.
> Incorrect. In that companies libraries are maintained by their owner teams.
It’s awfully nice when you can order devs to use the specific versions maintained by a specific owner team.
Of course, most of your complaint is that you *do* not* *want* to use the specific versions maintained by the distro teams.
So, it’s not a technical problem. It’s a social problem.
Posted Dec 7, 2019 9:05 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> when the language tooling makes it possible without inventing custom layouts like Nix does.
> Of course, most of your complaint is that you *do* not* *want* to use the specific versions maintained by the distro teams.
It's just that right now these kinds of repos are useless, because they move really slowly for a variety of reasons. The main one is the necessity to upgrade all versions in the distribution in lockstep.
Posted Dec 7, 2019 9:47 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link]
> Then this tooling needs to be implemented for other languages. As I said, I've seen it done at the largest possible scale. It doesn't even require a lot of changes, really.
Then don’t complain at distros, write a PEP, make upstream python adopt a parallel-version layout.
Major community distributions will apply the decisions of major language upstreams, it’s that simple. Major community distributions collaborate with major language upstreams. Collaborating implies respecting upstream layout choices.
In a company, you can sit on upstream decisions and do whatever you want (as long as someone finds enough money to fund your fork). That’s ultimately completely inefficient and counter productive, but humans do not like to bow to the decisions of others, so, that’s been done countless times and will continue to be done countless times.
Soller: Real hardware breakthroughs, and focusing on rustc
Correct.
Incorrect. In that companies libraries are maintained by their owner teams. The difference is that they typically maintain a handful of versions at the same time, so that all their dependants can build it.
In my experience, they mostly break things by updating stuff willy-nilly without considering downstream developers.
That's pretty much what we'll be doing eventually. The plan is to move everything to containers running on CoreOS (not quite LFS, but close enough).
Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc
Except that it's impossible to use it, because it's not possible to parallel install libraries.
Then this tooling needs to be implemented for other languages. As I said, I've seen it done at the largest possible scale. It doesn't even require a lot of changes, really.
Incorrect again. I would love to see a distro-maintained repository with vetted package versions, with changes that are code-reviewed by distro maintainers.
Soller: Real hardware breakthroughs, and focusing on rustc