Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc
Posted Dec 6, 2019 8:39 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
> system-wide is a limitation of python's own packaging system.
> No it's not. Python supports venvs, custom PYTHONPATH and custom loaders.
None of this works at scale. It’s all local dev-specific workarounds:
– venv is poor man's containerization (you can achieve the same with full distro containers, if venv “works” then distros work too)
– PYTHONPATH is the same technical debt engine which has made Java software unmaintainable¹
– custom loaders are well, custom. they're not a generic language solution
A language that actually supports multi versioning at the language level:
1. defines a *single* system-wide directory tree where all the desired versions can coexist without stomping on the neighbor’s path
2. defines a *single* default version selection mecanism that handles upgrading and selects the best and most recent version by default (ie semver)
3. defines a way to declare, an application-level exception for a specific set of components
Because, as you wrote yourself:
> the major problem was "migration campaigns" when a central dependency had to be upgraded and individual teams had no bandwidth to do it.
Therefore, anything manageable at scale must keep semver exceptions as exceptions, not the general case.
Most languages do not support multi-version (that’s a *language* not a distribution limitation). Some languages do:
– the “backwards” C/C++, because of shared lib versionning
– Go, because Google wanted to create an internet-wide Go module repository, so they had to tackle the version collision problem
Probably others.
You can trick a mono-version language locally by installing only a specific set of components for a specific app. That does not scale at the system level, because of the version combination explosion at initial initial install time, and the version combination explosion at update decision time.
The other way that devs, that like to pretend the problem is distribution-side, workaround mono-version language limitations, is to create app-specific and app-version-specific language environments. That’s what vendoring, bundling, Java PATHs, and modularity tried to do.
All of those failed the scale test. They crumble under the weight of their own version contradictions, under the weight of the accumulated technical debt. They are snowflakes that melt under maintenability constrains. They only work at the local scale (app or company-specific local scale, limited time scale of a dev environment).
You want multi-version to work for foo language, ask foo language maintainers for 1–2–3. You won’t get distributions to fix language level failures by blaming them while praising at the same time the workarounds language devs invented to avoid fixing their runtime.
¹ Both distro *and* enterprise side, I have a *very* clear view @work of what it costs enterprises; and it’s not because of distros since everything Java related is deployed in non-distro mode
Posted Dec 6, 2019 8:50 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
Pretty much all of its software is built this way, with dependency closures sometimes having many hundreds of packages. The build/packaging system supports Python, Ruby, Go, Rust, Java and other languages with only minor changes to the way binaries are launched.
So I can say for sure that this approach scales.
> A language that actually supports multi versioning at the language level
> Therefore, anything manageable at scale must keep semver exceptions as exceptions, not the general case.
> All of those failed the scale test. They crumble under the weight of their own version contradictions, under the weight of the accumulated technical debt. They are snowflakes that melt under maintenability constrains.
In reality, commercial ecosystems and even Open Source language-specific ecosystems are already solving the problem of multiversioning.
Posted Dec 6, 2019 11:20 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (7 responses)
When you attain this size you can afford the combination explosion. Most entities (starting with community distros) can not.
So yes it does not scale. With astronomic resources you can brute-force even an inefficient system.
Go modules respect my requirements. I should know, I spend enough months dissecting the module system. They will work as multi-version. Python does not. It's not a multi version language.
Java has not solved anything. Which is why its adoption outside businesses, is dismal. Businesses can afford to pay the not-scaling tax (in app servers, in ops, in lots of things induced by Java software engineering practices). Community distros can not.
>> Therefore, anything manageable at scale must keep semver exceptions as exceptions, not the general case.
Because each exception is an additional thing that needs specific handling with the associated costs. That’s engineering 101 (in software or elsewhere).
Rules get defined to bring complexity and costs down. Exceptions exist to accommodate an imperfect reality. A working efficient system allows exceptions without making them the rule.
Posted Dec 6, 2019 18:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> So yes it does not scale. With astronomic resources you can brute-force even an inefficient system.
I.e. if you own a package AppA that uses LibB then you don't care about LibB's rdepends. You just use whatever version of LibB that you need. If you need a specific older or newer version of LibB then you can just maintain it for your own project, without affecting tons of other projects.
This approach scales wonderfully, compared to legacy distro packages. Heck, even Debian right now has just around 60000 source packages and is showing scaling problems. The company I worked at had many times more than that, adding new ones all the time.
> Because each exception is an additional thing that needs specific handling with the associated costs. That’s engineering 101 (in software or elsewhere).
> Exceptions exist to accommodate an imperfect reality. A working efficient system allows exceptions without making them the rule.
Posted Dec 6, 2019 19:22 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (4 responses)
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.
Posted Dec 7, 2019 10:00 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link]
> I maintained several projects there and spent way less time on that than maintaining a package for Ubuntu and coping with it being broken by Python updates.
That "works" because you do not care about the result being useful to others. But wasn’t your original complaint, that the python3-theano maintainers didn’t care that their package was not useful to your commercial app?
So you want a system that relies, on not caring for others, to scale, to be adopted by distributions, because the distributions should care about you?
Don’t you see the logical fallacy in the argument?
Al the things that you found too much work in the Ubuntu package, exist so the result can be used by others.
Soller: Real hardware breakthroughs, and focusing on rustc
I worked in a company that is in the top 10 of the world's companies and has the name starting with an "A" and the second letter not being "p".
Nothing of this is needed. Nothing at all. Please, do look at how Java works with Maven, Ruby with Gems, Go with modules, or Rust with Cargo. They solved the problem of multiversioning in the language tooling without your requirements.
I don't follow. Why?
So far this is basically your fantasy. You are thinking that only seasoned distros that can wrangle the dependency graph into one straight line can save the world.
Soller: Real hardware breakthroughs, and focusing on rustc
> I worked in a company that is in the top 10 of the world's companies and has the name starting with an "A" and the second letter not being "p".
> I don't follow. Why?
Soller: Real hardware breakthroughs, and focusing on rustc
I maintained several projects there and spent way less time on that than maintaining a package for Ubuntu and coping with it being broken by Python updates.
There's nothing inefficient there. It allows to efficiently place the onus of evolving the dependencies on the correct people - package owners.
What is "semver exceptions" then?
What are "exceptions" in the system I'm describing?
Soller: Real hardware breakthroughs, and focusing on rustc
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
Soller: Real hardware breakthroughs, and focusing on rustc