You can step up and be the maintainer of GTK2 (or anything else that would keep the 'deletionists' at bay) any time you want. Go on...I'm sure you have unlimited time and resources like all the other Debian maintainers.
Nonsense. You just need to make building the gtk2 unit optional, so that the distros can still build it. Almost no one needs gtk2, just Lazarus. Usually debian maintainers are happy to patch the build system to do that. They got a bad one.
The harder part is to upgrade Lazarus to qt6. Until that happens, Lazarus needs to be shipped as snap, flatpack or appimage with the gtk2 so's.
Exactly. "Let me explain how some else needs to do this thing, and how easy it is, and how that someone else needs to get right on that for my convenience". Because you're here to condescend, not to actually do anything.
You apparently never had to share a 3B20 (around 1 MIP) with 200 other CS1401 students desperately trying to get their Pascal project to compile before the midnight deadline. 15m for 'hello world'? If you're lucky.
Eeeeeep. I was lucky that my big CS courses were done on a Sequent Balance 8000 equipped with six NS32032 CPUs and room for six more. Yup, SMP in the mid-1980s. That machine positively flew on loads that would bring the neighboring Pyramid 90x to its knees.
I had an account on a 3B20, and it did not impress me in the least, but the 3B2/400 boxes in one lab were pretty reasonable for being small systems. What a shame that the WE32000 didn't get any traction.
Before I went down to UIUC, the junior college had a Prime 650, and all compile jobs were run through a queue precisely to avoid having the machine get crushed.
That's kinda funny...we musta lived in parallel worlds.
The 3B20 might have been slow, but it had a solid I/O subsystem so you could load it up with users, and was generally reliable (it was originally built as a telco switch control processor looking for 5-nines uptime). But by the later 80s the industry had moved on, and we were in the process of migrating those CS classes from the 3B20 to either a Sequent Symmetry (follow-on to the Balance with something like 16x i386) or a Pyramid 90x, depending on the class. The Symmetry was...not reliable. The 90x was worse. The wails of a lab full of undergrads realizing the shared machine had just taken a dirt-nap and all their work with it was a far too common sound. Good times.
We also had a bunch of 3b2s, most with an AT&T 5620 'windowing terminal' attached, which is a really fascinating 'what might have been' if bitmapped workstations and X11 hadn't taken over that niche. I ended up with a Sun 3/160 for most of that time, and the rest is history.
Strange that the Balance was largely reliable. I recall one or two hiccups, but nothing that caused me lost work. There were other machines floating around, but they were pretty much reserved for faculty/staff/grad students, and undergrad plebes weren't welcome to use what passed for the internet at the time (but Usenet was was available, albeit via Ray Essick's "notes" software). Also, any student could get an account on the CDC Cyber 170, but few courses used it for actual coursework by the time I was there. Then there was PLATO, a world unto itself... it also ran on CDC hardware, with bespoke way-ahead-of-its-time touchscreen plasma display terminals, online forums, instant messaging, and multi-player online games.
We only had a few of the 5620s in the 3B2 lab, and I remember a wacky mechanical mouse with a metal ball that I can't imagine would have held up in the long run. The PLATO touchscreens were optical, with a grid of infrared beams to pick up touches.
Yes, I will put this right over here next to my group file editor, printcap editor and separate dot file editor. And motd surely has it's own. Obviously, I now need a standalone fstab editor, which clearly can't be the same editor I use on grub.conf files.
Totally fair. I'm not really aiming to compete with general purpose editors.
The motivation for Hedit was more about workflows, like syncing from remote sources or shared lists. So Hedit is closer to a small system utility rather than "yet another editor".
So you've replaced a <10 line shell script (which is what I've been using to workflow host blacklist updates and similar for...oh...25 years) with an entire application. Fair enough...but I thought it was only mobile shoveling "EVERYTHING MUST BE AN APP" down on us. The more you know.
This is a good point. I think we get a couple of emails a week for exactly this kind of bottom feeder 'consulting firm' 'offering' to tell us all about some massive security issue they found, as long as we sign up for a 'consulting engagement'[1]. On the other hand, we generally ignore them, not threaten to sue them.
[1] We get about as many 'pay us a bounty or we'll tell the world about this horrid vulnerability we found'. I have suggested to legal we treat those like extortion attempts to make them go away and stop wasting our time but legal doesn't want to spend time on it.
Back in the day, Alpha and HPPA were commonly used as examples of 'with all this extra stuff is it still RISC?'. These days, I think the CISC/RISC divide is largely an historical artifact.
I think the idea of simplicity is still relevant, but the problem is not as simple as (no pun) having a certain look to your ISA anymore. ISA transformed to something unrecognisable 2-3 steps into the pipeline, the rest of the CPU doesn't see much of the ISA.
Maybey we should abandon "reduced instruction set" and instead evaluate how ISA is suitable for out of order execution or speculative execution or backtracking and so on
Fair. Personally, I think the idea of simplicity is still relevant for pedagogy (as it always is), but one you rope in 'suitable for out of order execution or speculative execution or backtracking and so on' as criteria, 'simple' is harder to achieve (at least for practical commercial designs). YMMV.
reply