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.
The craft is still there just like painting is still an alternative to a photograph. It's just not going to be valued by society anymore, and far fewer will learn how to do it. Natural language is the new programming language. For now, understanding the craft is still an edge in making better prompts, but already I can see that telling Antigravity "now look for ways to make this more efficient" works almost as well as guiding it specifically on how it had duplicated some code flows.
I do feel a kind of personal loss in the sense that society is in the process of stopping to value or admire the design and coding skill I've cultivated since I was 6yo. At the same time, I'm kind of thrilled that I can write a detailed readme.md and tell an agent to "make it so" and I can iterate to a utility program in 20 minutes instead of an hour. When I feel a pit in my stomach is when that utility program uses some framework that I haven't learned, and don't need to because their code worked perfectly the first time. Surely that means I'm going to basically stop learning the details, as the details I've accumulated over my life quickly begin to not matter anymore.
Honestly I'm planning to use AI to make a kick-ass retro development environment a la "Sending Modern Languages Back to 1980s Game Programmers" (https://prog21.dadgum.com/6.html) and spend my retirement having fun in it.
It's a fun article and this really doesn't matter much but `5{|+\x}\1,2` does not give the typical fibonacci sequence. Either `5{|+\x}\1,1` or `5{|+\x}\2,1` do, if the results from this random online interpreter can be believed (https://ngn.codeberg.page/k/#eJwzra7RjqmojTHUMQQAFyUDkw==).
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.
First off, the mail references far more rust adoption than just Sequoia, but since you bring it up: here is how RPM adopted Sequoia in Fedora-land. There was a proposal, a discussion with developers about the ramifications (including discussion about making sure the RPMs built on all architectures), and there were votes and approvals. Costs and benefits and alternatives were analyzed. Here's a page that has links to the various votes and discussion: https://fedoraproject.org/wiki/Changes/RpmSequoia
Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?
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.
Nah, I called out redox and another commenter pointed out ripgrep as an even better example of what I’d prefer to see, and those are also by what I would call rust enthusiasts. I don’t think of them as a monolithic group.
Where we disagree is I would not call injecting rust into an established project “writing a better version”. I would love it if they did write a better version, so we could witness its advantages before switching to it.
Exactly! People love ripgrep because of its clear advantages, and had the developers been interested in making posix mode for it, I'm certain at least some distros would have made it the default by now.
There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to".
And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.
I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting, as is always evident by the complaints it causes. I love projects like Redox that try to do their own thing... why doesn't the rust community rally around projects like that and turn them into cve-free masterpieces that people will want to use?
As a 1980's adventure game fan, I can only hope that whatever comes after AGI is called SCI. Maybe it could be "Soul-Crushing Intelligence".
Once we don't need people to make stuff anymore, we need to re-do society so people can get access to all the stuff that's being made. I doubt we do a very good job of that. But otherwise, there's no point in making anything. I guess if we are lucky, the AI overlords will keep us high on soma and let the population naturally decline until we are gone.