Huge kudos to the security researchers for 1, finding an exploit, and 2, unlike copyfail, excluding a zero-day ready-to-use LPE script that anyone could have used.
I tried using this for LPE on a Rocky9 for a couple of hours and thankfully couldn't get it to work. So that means unless you have quite some free time on your hand, or are extremely good at doing what you do, you can't actually use this to get LPE on enterprise distros.
This is fascinating research. I feel this is a significant leap in interpretability research. Since we know J-Space exists and is bi-directional, we can train models on the same and come up with meta cognition abilities.
I also fear that the big corporations might use the same to run targeted ads, capitalistic shenanigans. Which they might already be doing through system prompts.
It's one thing to report a vulnerability, another entirely to make a crazy exploit available for any tom, dick, and harry to take and use. It was irresponsible of whoever came up with it to release it in the world without first giving major distros a head's up.
I was coming up with the same intuition. However, it's like a whack-a-mole. What about cronjobs and slurmjobs and other services? Is there a way to do this directly on systemd so that all other processes inherit it rather than doing it on each one?
This was bound to happen either organically or inorganically. Make sure it performs well on the benchmarks. And it doesn't really matter if it doesn't generalize outside of it right? :D
While it is true that guides and business owners are always looking for opportunities to earn extra cash, the reporting is a tiny bit off here.
Start of AMS like symptoms can easily be mistaken for walking fatigue and dehydration. It is easier to identify if you are at rest, but during the trek that is seldom the case. So when you actually start realizing something is wrong, you already are at an elevated risk. The only thing that works in these cases is to descend and as fast as possible at that.
Considering the fact that AMS will absolutely and a 100% kill you if you play around with it, guides presenting trekkers with an option of helicopter rescue is not that bad, at least if you look at the worst that can happen.
That would indeed be the case if one has never learned the stuff. And I am all in for not using AI/LLM for homework/assignments. I don't know about others, but when I was in school, they didn't let us use calculators in exams.
Today, I know very well how to multiply 98123948 and 109823593 by hand. That doesn't mean I will do it by hand if I have a calculator handy.
Also, ancient scholars, most notably Socrates via Plato, opposed writing because they believed it would weaken human memory, create false wisdom, and stifle interactive dialogue. But hey, turns out you learn better if you write and practice.
I think the 'better than googling' part is less about the final code and more about the friction.
For example, consider this game:
The game creates a target that's randomly generated on the screen and have a player at the middle of the screen that needs to hit the target. When a key is pressed, the player swings a rope attached to a metal ball in circles above it's head, at a certain rotational velocity. Upon key release, the player has to let go of the rope and the ball travels tangentially from the point of release. Each time you hit the target you score.
Now, I’m trying to calculate the tangential velocity of a projectile from a circular path, I could find the trig formulas on Stack Overflow. But with an LLM, I can describe the 'vibe' of the game mechanic and get the math scaffolded in seconds.
It's that shift from searching for syntax to architecting the logic that feels like the real win.
In the 1930s, when electronic calculators were first introduced, there was a widespread belief that accounting as a career was finished. Instead, the opposite became true. Accounting as a profession grew, becoming far more analytical/strategic than it had been previously.
You are correct that these models primarily address problems that have already been solved. However, that has always been the case for the majority of technical challenges. Before LLMs, we would often spend days searching Stack Overflow to find and adapt the right solution.
Another way to look at this is through the lens of problem decomposition as well. If a complex problem is a collection of sub-problems, receiving immediate solutions for those components accelerates the path to the final result.
For example, I was recently struggling with a UI feature where I wanted cards to follow a fan-like arc. I couldn't quite get the implementation right until I gave it to Gemini. It didn't solve the entire problem for me, but it suggested an approach involving polar coordinates and sine/cosine values. I was able to take that foundational logic turn it into a feature I wanted.
Was it a 100x productivity gain? No. But it was easily a 2x gain, because it replaced hours of searching and waiting for a mental breakthrough with immediate direction.
There was also a relevant thread on Hacker News recently regarding "vibe coding":
The developer created a unique game using scroll behavior as the primary input. While the technical aspects of scroll events are certainly "solved" problems, the creative application was novel.
Versity is really promising. I got a chance to meet with Ben recently at the Super Computing conference in St. Louis and he was super chill about stuff. Big shout out to him.
He also mentioned that the minio-to-versity migration is a straight forward process. Apparently, you just read the data from mino's shadow filesystem and set it as an extended attribute in your file.
You make a good point and I agree mostly to the point being made i.e. it is more fluid than categorical. However, I think it is not being made in good faith. I found the article highly insightful because it provides a solid starting point to those that have not started or don't know much about negotiations and how they happen. It should be safe to assume that there are plenty that have not started yet. It is also true that the more frameworks one reads and learns about, the more they realize that there are gaps in each one of them, and it is indeed fluid, not categorical, and hence reaching the same conclusion.
I think two reasons. If reactors can't function above 20%, a country having access to >20% enriched payload is a certain violation. Vs "60% enrichment is still for clean energy, my reactor works with it". 2. If you are only buying the payload and not enriching it yourself, you can't do anything with >20% . More like mixing methyl alcohol in lab available ethyl alcohol, to deter lab techs from mixing water and having a rager.
This is scary. so the extra effort to move from, say, 20% to 85% is relatively small compared with the effort to get up to 20% in the first place. Might as well build a feature into the reactor so that it only works with <=20%
Asking because I don't know. How is enrichment governed? Say for instance if a country is only using it for energy vs defense/offense. And are there elements that can be specifically used for energy vs otherwise? Last I remember, having access to enriched uranium was grounds for a country to bomb another one.
https://news.ycombinator.com/item?id=48808002
https://news.ycombinator.com/item?id=48810092