richard_todd

Honestly -- and I know this project is just a toy/fun experiment -- with modern AI, I think this is the correct approach to Rust-ifying projects. Just fork it and do an AI-assisted wholesale conversion, and run in parallel for a while to make sure all the regressions are found. Then you can compare to the original for benefits and drawbacks, and you get a more idiomatic code-base... instead of trying to convince longstanding projects to go into a half-rust Frankenstein model, which is what I usually see.

The author assumes the way to keep segments going with larger memory would have been to change the amount of overlap, but it would have also been possible to make an 80286 where the segment registers were > 16bits, and everything else is 16 bits like before. Now you have extra segments that are still paragraphs apart and existing software could still function (you'd need new instruction variants to move data into and out of the enlarged portion of the segment registers.. call them ECS, EDS, or whatever). Anyway, just a thought.

I agree, it would be way more interesting to see a table of original GIF sizes versus the improved size. I'm left wondering how bad the plain greedy version is on a typical image.

I agree this is great, but I also feel like it's an intermediate step to just asking Claude for whatever file edits you want... and then you don't even need the text editor.

Well at least for what I do, success depends on having lots of unit tests to lean on, regardless of whether it is new or existing code. AI plus a hallucination-free feedback loop has been a huge productivity boost for me, personally. Plus it’s an incentive to make lots of good tests (which AI is also good at)

Even if I were retired and financially set now, that would mean nothing in 10 years if an unemployed society collapses around me. Apathy is not on the menu today.

Lately I just ask an LLM to teach me things interactively. It will be interesting to see if that stops working so well, when authors stop writing books for LLMs to absorb. Maybe as long as there is some kind of canonical reference, the LLM can bridge the gap to decent educational material. If so, that's kind of sad, but also kind of awesome at the same time. It's definitely an interesting time to be alive. I wish I was just a little closer to retirement, though...

If I'm considering becoming a drug runner, and I hear "sometimes they arrest you" I'd say "so what?" If I hear "sometimes you get shot at", I'd take my chances and shoot back. But if I keep hearing about missiles obliterating drug runners with no warning... maybe I just stay home.

I think the problem with XSLT is that it's only a clear win to represent the transform in XML to the extent that it is declarative. But, as transformations get more complex, you are going to need functions/variables/types/loops, etc. These got better support in XSLT 2 and 3, but it's telling that many xslt processors stuck with 1.0 (including libxslt and the Microsoft processors). I think most people realized that once they need a complex, procedural transformation, they'd prefer using a traditional language and a good XML library to do it.

I don't like seeing any backward compatibility loss on the web though, so I do wish browsers would reconsider and use a js-based compatibility shim (as other comments have mentioned).

If you think a situation where everyone had access to ipchains for 3 years to figure out how to migrate is similar to a situation where some architectures will be killed in six months without ever having had access to the new product then I don't know how to help you. What can affected ports do? Implementing a toolchain backend is a tall order.

We didn't talk about your gcc-to-c++ example, but if you read up on it you will know they took the pulse of affected developers, started experimental branches, made presentations, and made sure no architectures were left behind. All of which this Debian developer is failing to do.

Look I don't even disagree with the ultimate result... I don't think Debian needs to indefinitely support every strange port it has built up over the years. The way it's being done, though, doesn't sit right. There are far more mature ways to steer a big ship. Your own examples are showing the way.

On their github you can see all three changes identical to x.org's happened on October 28th (same day as the advisory). So, they were not already fixed, but the fixes were applied immediately.

ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences.

They certainly did NOT say "I'm replacing ipfirewall with ipchains in six months, and if your distro can't handle it you should sunset your distro."

It shouldn't be controversial to request a measured approach when making major changes to software lots of people depend on. That's part of the burden of working on important software. Note I'm not against apt or anything moving to rust.

edit: spelling