Hacker Newsnew | past | comments | ask | show | jobs | submit | Avamander's commentslogin

Can Livepatch mitigate this or is it already? I don't know where to look this up.

I used the mitigation from this CVE report to turn off AF_ALG.

These things were caught and basically all of them weren't covered by any test suite (not even GNU coreutils'). It's a bit bold to claim that it's actively worsening it when it's not an LTS.

That's generally what you call introducing new semantic bugs.

> It's a bit bold to claim that it's actively worsening it when it's not an LTS.

It is LTS now. And not LTS releases are releases.


This is where I kind-of like the idea of PowerShell, it's just that I dislike almost all other aspects of it and around it.

Same - psh has one good idea and it’s this. The next evolution of shells needs to include it.

can either of you elaborate what you mean? are you talking about support for structured data passing between scripts/programs?

Yes - https://devblogs.microsoft.com/scripting/working-with-json-d...

Tons of bugs in scripting in Unix come from the fact that data and metadata are interspersed in the same stream (you can mitigate somewhat with stderr vs stdout but hardly anyone does). Examples include things like trying to handle random filenames from * expansions.

It’s a bit more annoying to deal with sometimes, but for actual scripts it’s much more foolproof.

xargs is one of the programs that is designed to work around the original issue.



Yes, structured data between scripts and programs. No xargs, tee, awk, sed, grep mangling. No "argument list too long" errors.

So many problems are avoided, but at the same time the Windows ecosystem is just so far from providing an properly usable terminal experience. Things are still really not designed to be used from PowerShell.


right, see my response to the sibling comment.

> but they'll still hold hostage of the vast swathes of average white collar workers with Office, people that don't care at all about technology as long as they have Word and Excel.

I can't wait for the anti-trust lawsuits. M365 and O365 are already super shady in terms of being able to migrate out or be interoperable with other solutions. "Accidental" roadblocks almost everywhere.


There won't be any.

I'm old enough to remember this happening: https://en.wikipedia.org/wiki/Standardization_of_Office_Open...

Basically, Microsoft furiously bribed their way into formally standardizing the utterly broken MS Office formats, so EU and potentially other regulators couldn't mandate them to be "interoperable" with existing standards (e.g. OpenDocument, based on OpenOffice, which was on its normal way to become standardized with no fast tracking and no bribing). They even called it "Office Open" to foster confusion.

They can do whatever they want and get away with it because a big part of their business model is, much like Oracle and SAP, based on bribing government bodies across the world.


Yes, but this time there’s the additional driving force of countries trying to become more self reliant and not get locked into US software giants (France and Germany for example). A long way to go, but it’s gaining more traction than the past half-assed attempts.

> See also: modern practices and sanitizers and tools and test frameworks to avoid writing memory errors in C, and the reality that we keep writing memory errors in C.

I think there's a difference in how trivial some of these things are to detect and how difficult others are. IDOR and SQLi aren't nearly as complex as C unsafety is.


> I tried Elfeed2 immediately after the announcement, well, it's nowhere near the experience of elfeed in Emacs.

Isn't that kinda expected with a new software release, that it doesn't have a 100% feature parity?


My understanding of the context is the author is no longer using Emacs, and is very excited about the productivity from AI.

My experience with LLM technologies is it does make generating the code a really quick part. It may be reasonable to take much more time to specify things up front (rather than emergently as you would by hand). -- I mean, if you've got a well crafted description of what you want, you'll be able to get a working program MUCH quicker with an LLM, today, compared to writing it out by hand.

Would it really be surprising/shocking if an LLM was able to rewrite (most) features from an existing software, to a new software?

It seems like the reality today is, we've gone from a maintained software in a niche ecosystem with happy users, to a more fragmented one where everyone has an LLM write their own half-baked one.


On the other hand, given there is prior art in Elfeed, why wouldn't it rapidly converge on feature parity?

Probably because it's closer to a reimplementation than anything else, and in Emacs you can use libraries with much less friction than in self-contained languages.

> llm allows for easier fragmentation..

I also suspect it allows easier consolidation. Moving from a deprecated lib to a new (and better) one for example.

Implementations will likely homogenize a bit as well, but on the other hand boy am I glad not to see an increasing amount of bizarre naïve hand-rolled implementations for some things.


There's the SVG Tiny profile that some implementations use, like BIMI/VMCs.

Dirac Live BC or Dirac Live ART? I would love to know how much these room correction approaches differ in practice.

I think I may have been thinking about ART, indeed.

> The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.

Unfortunately there's something akin to a conflict of interest with both RNP and OpenPGP. OpenPGP guys have gpgsm, and RNP people also maintain the S/MIME part in Thunderbird. Both have stagnated and are holding back what would have otherwise moved on.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: