Notoriously difficult to portray correctly in EU money-shuffling statistics. Some money not granted to the grand duchy still filed under "beneficiary country: Luxembourg" due to some program or institution being headquartered there. And it is essentially impossible to compare apples to apples what happens in actual EU budget and what happens in Kirchberg, home to EIB.
I found that reducing my "Linux" lines from ~21000 (including net-pf-16-proto-21) down to those ~3000 I might actually use (e.g. udp_tunnel) to be a fairly effective method of not having to care about each and every newly discovered memory safety hazard.
I remember my earlier days of Linux of having to compile a kernel module to read from cdrom. Seems like Linux has gone too far in the other direction of having modules that you will probably never need.
That's the same thing that people say about MS Office: nobody uses more than 15% of its feature set, but everyone uses a different 15%. "Linux" having these modules is what keeps it relevant and prevalent in different fields and niches. Whether distro's should ship this many modules by default is a different question, but then we're no longer talking about Linux the kernel.
Not just shipping features - that part is little more than disk space, for features already neatly isolated into modules. I see potential in improved tooling to express "do not autoload anything below this tree" in a more reliable and manageable manner. I know my 15% (far below that, actually), and many more users could express theirs in some deploy config..
If only that did not incur the cost of watching upstream changing things for no reason, or for the recurring reason of kconfig being a fairly error-prone method of expressing & validating dependency trees.
Ubuntu is not really targeting multi-user any more. Security update installation is deliberately delayed for all users, until at some point all unprivileged users ended all processes launched from the vulnerable snap image. (Firefox RPC breaks when you replace the binary, so having to reopen your browser to keep opening tabs simple because security upgrades were applied in the background would be inconvenient)
This is much bigger than subsidies. IONOS is already making serious money in selling "we host FOSS for you" to both users and (though generally: small) companies. They can expect to gain substantially greater revenue from acquiring larger commercial and municipal/federal customers.. IF the full package attains sufficient interoperability to withstand the usual anti-competitive tactics.
Has there ever been a GDPR fine that actually exhausted all applicable legal challenges within a sufficiently short delay from initial violation to actually matter?
Short delay: depends on your DPA, I doubt any country is fast enough. On the other hand, this is the legitimate interest of GitHub, so it would require investigation, maybe even litigation.
> dependency resolution. conda could take 30-60 minutes
Quite literally this is what first raised the alarm bells for me. Dependency resolution complexity is more of a symptom. If that delay ends up being the point where Ops finally agrees that things have gone very wrong, then fixing that delay is not really helping hire the maintenance folks that can make those dependencies.. well, "dependable" again.
Have you looked at the .github/ folder of any actively developed python packages lately? It has become difficult to find one where there isn't a few interesting people with code-execution-capable push/publish/cache-write access somewhere along the blown up transitive dependency/include chains.
Its weird that still so many consider bug triage a problem to be circumnavigated, somehow in the way of "actual" contributions. Those are actual contributions! Even if they never make it into structured documentation or even python code. And especially so since that work can less usefully be augmented with newly available tool use.
A number of times now, I have found real value in someone just dropping into the bugtracker to restate the bug description in clearer terms or providing a shorter reproducer. Even if the flaw in Django had been fixed right away, I would not have pulled patches from master anyway. So the ticket comment was still a useful contribution to django, because I could use it in resolving the issue in how my software triggered it.
reply