I think it would have been useful for them to have really made a proper effort at modularising Windows along the lines of how Linux distributions and the BSDs do things. I can't see any way of recovery from the bloated mess they have created; they can't keep cramming any more in, it's an unstable, unusable and untestable mess.

I can see print-on-demand working very well, but not until the quality issues are sorted out. Being charged top dollar for something which is substantially inferior is unacceptable.

The lack of quality in Windows is simply astonishing. And the new start menu and taskbar are terrible. Quite how a company can transform a product into such a mess in just a few years is incredible.

I think when you look at it from the perspective of how much you get out of it compared with paying a human to do the same (including yourself), it is still very good value for money whether you use it for work or for your own projects. I do both. But when I look what I can now do for my own projects including open-source stuff, I'm very time-limited, and some of the things I want to do would take multiple years. Some of these tools can take that down to weeks, do I can do more with less, and from that perspective the cost is worth it.

Have you tried the planning mode? Ask it to review the codebase and identify defects, but don't let it make any changes until you've discussed each one or each category and planned out what to do to correct them. I've had it refactor code perfectly, but only when given examples of exactly what you want it to do, or given clear direction on what to do (or not to do).

The CDDL is actually very permissive. You can combine it with anything, including proprietary licences.

The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.

This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.

The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.

The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.

* If you use auto-hide, it won't show when some applications are open. Edge in particular is bad.

* Some applications simply don't show on the taskbar at all. Teams is one. It's in the alt-tab list.

* Sometimes it stops working entirely.

The testing and QA of this stuff appears to be largely absent.

Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.

I initiated its removal to the Apache attic in 2022 in https://marc.info/?l=xalan-c-users&m=165593638018553&w=2 and the vote to do this was in https://marc.info/?t=166514497300001&r=1&w=2&n=20. It has now gone nearly four years without any commits being made.

It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.

If you compare this with what MicroPython uses, its requirements are well over an order of magnitude larger.

[I used to maintain sbuild and was the author of schroot back in the day]

The number of times I've wanted to save in their native XCF file format is... zero. But I always want to save in a standard image format, and I don't really consider that to be exporting, just saving.

I understand why they wanted this, but I don't think many of their actual users did.

The Bambu has been ideal for that reason. Every material pretty much just works, and the quality is excellent. The cloud integration and janky LAN mode is the downside, and this current topic even moreso.

Replacing key infrastructure is hard, particularly when it's working well and the cost of replacement is high, especially so when it's volunteer effort. It was cutting edge back when Perl was all the rage, but while Perl might no longer be the fashionable choice, tools written in Perl continue to work just as they always have. I found it dense and impenetrable even 20 years back, and I used to have the whole thing printed out on fan-fold paper from a dot matrix; it was about 3/4" thick and covered in annotations! Understanding several thousand lines of obscure regexes is a cautionary tale in how to write unmaintainable Perl, and was one of the motivations to clean it up, refactor it into meaningful functions, and document what it was doing so that it could be maintained with a little less effort.

Has an outright replacement for sbuild itself been considered? Given the ubiquity of modern CI systems, it seems quite possible to replace it entirely. I would have thought GitLab runners or Jenkins or any other standard CI system would work well. While I once enjoyed writing Perl, sbuild is not a great piece of code, and the problems it was trying to solve now have better and more widely-used solutions which don't require ongoing maintenance of an even older piece of Perl code.