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.
This is not a regulators move. This is the industry slightly adjusting their recommendations to parents.
Will this change anything? Maybe it will help the industry avoid being targeted by actual regulation.
To complete your analogy:
To this day there are humans who have never in their life exceeded 300km/h outside of an airplane. Mostly people in places that had become used to driving. Used to subpar travel times, safety, efficiency and cost. In hindsight, those that saw the horses swapped for electric ones with the carriages mostly unchanged should have been more protective in their transport planning. Could have saved us from the 110 year detour that scarred almost all urban centers.
One particular chasm to keep an eye on, possibly even more relevant than Ubuntu using Rust: When it comes to building important stuff, Ubuntu sticks to curl|YOLO|bash instead of trusting trust in their own distributions.
When people say "curl|bash", this usually means secondary fetches, random system config changes, likely adding stuff to user's .bashrc
But it's not quite that bad in this particular case - they are fetching pre-built static toolchain, and running old-school install script, just like in 1990s. The social convention for those is quite safer.
(Although I agree, it is pretty ironic that they prefer this to using ppa or binary packaged into deb...)
The "issue" isn't that these new tools from Ubuntu is in Rust, that's almost irrelevant. The issue is that they are not the "standard" tools.
If Ubuntus Rust replacements aren't adopted in other distributions, or only in some of them, we get an even more fragmented Linux ecosystem. We've already seen this with the sudo-rs (which really should be called something else). It's a sudo replacement, ideal a one to one replacement, but it's not 100% and for how long? You can also think of the Curl provided by Microsoft Powershell, which isn't actually Curl and only partially provides Curl functionality, but it squats the command name.
Ubuntu might accidentally, or deliberately, create a semi-incompatible parallel Linux environment, like Alpine, but worse.
Aren't the versions of Rust in stable Linux distributions like, a century old? Or at least they were last I checked what Debian and Ubuntu LTS were distributing. I think it's because they don't like static linking.
I believe Rust is typically only used through `apt` as a dependency for system packages written in Rust, or for building system packages that are written in Rust, so that they can link against a single shared instance of the Rust Standard Library.
Debian had a new stable release 45 days ago. For now I would imagine things aren't too old there. Although a friend of mine recently ran into some ancient packages on Mint, so maybe Mint/Ubuntu are oddly behind Debian Stable right now for some things.
In practice, very rarely. Lots of 'curl | sh' do secondary fetches, and those don't come with hash checks. And even if they come with hash checks _today_, there is no guarantee next version won't quietly remove them.
> And even if they come with hash checks _today_, there is no guarantee next version won't quietly remove them.
...But you could say this about literally every security measure in literally every codebase. At any point, anyone could quietly remove anything that enhances security, or quietly add anything that reduces security. So what's your point?
Yes, technically it's all Turing-complete, but conventions matter, a lot. And Rust, being a mature project, is very likely to follow the conventions.
"static toolchain .tar.gz" means bunch of files you download and manually extract. There may be an install.sh script, but it'll just copy files around, not download extra files. And sometimes install.sh is optional, and tools can be run directly from extraction location.
"curl | bash" means "do whatever developers think gives best experience with minimal prompts", which absolutely means download extra files, but also install system packages, update ~/.bashrc, change system settings and so on.
".run installer" mean interactive installer, Windows-style, often with actual GUI. Often goes into /opt.
"deb file" means "all installed files are managed by apt, and can be examined. /etc conflicts are managed by apt. pre/post install scripts are minimal, and there is a clean uninstall command you can trust to actually work".
You can have deviations - like curl|bash used to pull a deb file or something - but no one likes surprises, so people usually stick to their lanes. If you have .deb files, it might get an officially-specified dependency, more files and maybe a post-inst script, but it won't suddenly start rewriting your .bashrc. Having static toolchain suddenly download files will make many people unhappy, so it likely won't happen either.
(One exception to this rule is enterprise software being packaged into .deb files - Google Chrome surprised everyone when they started to install apt source in their postinst, but many enterprise softwares (cough nomachine cough) do much worse things, like only using apt to unpack their installer file, an dthen running their proprietary install script in postinst)
reply