Protip, if you have access to the computer: `lsb_release -a` should list both release and codename. This command is not specific to Ubuntu.
Finding the latest release and codename is indeed a research task. I use Wikipedia[1] for that, but I feel like this should be more readily available from the system itself. Perhaps it is, and I just don't know how?
That's only if the distro is recent enough; sooner or later, you'll encounter a box running a distro version from before /etc/os-release became the standard, and you'll have to look for the older distro-specific files like /etc/debian_version.
> you'll encounter a box running a distro version from before /etc/os-release became the standard
Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.
> the oldest Red Hat still in extended support, also has it.
You would be alarmed to know how long the long tail is. Are you going to run into many pre-RHEL 7 boxes? No. Depending on where you are in the industry, are you likely to run into some ancient RHEL boxes, perhaps even actual Red Hat (not Enterprise) Linux? Yeah, it happens.
Yes, they do. You'll be surprised by how many places use out-of-support operating systems and software (which were well within their support windows when installed, they have just never been upgraded). After all, if it's working, why change it? (We have a saying here in Brazil "em time que está ganhando não se mexe", which can be loosely translated as "don't change a (soccer) team which is winning".)
> was it a security vulnerability? I'm pretty sure it was "just" a crash.
It's a race condition resulting in memory corruption.[1][2] That corruption is shown to result in a crash. I don't think the implication is that it can result only in crashes, but this is not mentioned in the CVE.
Whether it is a vulnerability that an attacker can crash a system depends on your security model, I guess. In general it is not expected to happen and it stops other software from running, and can be controlled by entities or software who should not have that level of control, so it's considered a vulnerability.
It is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been used in production", "this really is an example how fantastic Rust is").
There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did.
Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen.
I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.
> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."
Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.
If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.
> it is not "Safe Rust" which is competing with C it is "Rust".
It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power.
Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive throughout the program. That’s a significant difference from how C’s unsafety works.
But there are more than 2000 uses of "unsafe" even in the tiny amount of Rust use in the Linux kernel. And you would need to compare to C code where an equally amount of effort was done to develop safe abstractions. So essentially this is part of the fallacy Rust marketing exploits: comparing an idealized "Safe Rust" scenario compared to real-word resource-constrained usage of C by overworked maintainers.
The C code comparison exists because people have written DRM drivers in Rust that were of exceedengly high quality and safety compared to the C equivalents.
Even if you somehow manage to ignore the very obvious theoretical argument why it works, the amount of quantitative evidence at this point is staggering: Rust, including unsafe warts and all, substantially improve the ability of any competent team to deliver working software. By a huge margin.
This is the programming equivalent of vaccine denialism.
So kernel devs claiming Rust works isn't good enough? CloudFlare? Mozilla?
Your're raising the bar to a place where no software will be good enough for you.
> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.
The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.
Is it any more or less amusimg, or perhaps tedious, watching the first Rust Linux kernel CVE be pounced on as evidence that "problems .. did not magically disappear"?
Does anyone involved in any of this work believe that a CVE in an unsafe block could not happen?
The TLDR is that this race condition happened with unsafe code, which was needed to interact with existing C code. This was not a vulnerability with Rust's model.
That said, you can absolutely use bad coding practices in Rust that can cause issues, even for a regular programmer.
Using unwrap without dealing with all return cases is one example. Of course, there is a right way to dealing with return methods, but it's up to the programmer to follow it
Hasn't this been the Russian agenda for decades? I don't think it's a secret, or a fringe theory. They have worked on it long term, and seemingly finding success now.
I don't think China is against this change, but their agenda seems to be more focused on international trade and internal growth, rather than specific strategy against the US.
The EU is definitely not benefiting from it in the short term. While some argue it needs this change in the long term, it is difficult to imagine that the EU wants it to happen so arbitrarily and quickly.
Those holding any meaningful power in the US are either benefiting from this change, at least in the short term or personally, or oblivious to it, possibly also due to influence from the agents of change.
It's an opportunity for other states to gain influence. And in particular for Russia to advance their geopolitical ambitions, since this is from their playbook.
It would be in the interests of the United States to alter the course, and regain the influence already lost. The leaders seem to have chosen to ignore her interests, though.
Maybe the legislation allowing their import should take their special status in to account.
I would suggest mandatory semi (or full) trailer truck drivers' license required for anyone who operates these. In addition, they should be indicated as a new category of "recreational trucks", with harsh penalties specific to them especially regarding road accidents.
For example, if found guilty of reckless driving, or causing accidents, the vehicle would be permanently confiscated. (On top of personal fines, loss of license etc as already sentenced by law.) Perhaps the law enforcement could then be given access to such confiscated vehicles, creating also some incentive to enforce the law.
> Perhaps the law enforcement could then be given access to such confiscated vehicles
That is… not how we do things around here. It sounds like a baked-in conflict of interest and a wonderful way of making them chase the money instead of doing their policing job.
Old Androids do reportedly, and from experience, get slower over time. Maybe that's just bloat in the user installed apps when they are updated. But I would not be terribly surprised if it wasn't also malware consuming resources.
I would imagine to lesser extent government policy changes and news articles, and to larger extent online discussions on topics relevant to these instruments. Models then attempt to extract signals with predictive value from all the noise. Probably contains non-trivial amount of history to correlate words to market performance in the past, say 20 years or more.
But it's really just a guess, I haven't worked in this domain.
Finding the latest release and codename is indeed a research task. I use Wikipedia[1] for that, but I feel like this should be more readily available from the system itself. Perhaps it is, and I just don't know how?
[1] https://en.wikipedia.org/wiki/Ubuntu#Releases
reply