Nowadays “buggy” is not how I’d describe it, though there were certainly teething issues at the beginning. By now other DEs have learned to deal with it.

However it’s still true that the GTK4 design is ill-fitting, and very opinionated. Quite exemplary of this are the applications that hardcode the GTK file picker (like Firefox and chrome) even though it’s inferior in every way to the Qt file picker and forces the infuriating GTK “design” choice of doing fuzzy search when you type in the file list instead of jumping to the relevant file. Very annoying when dealing with organized directories especially when no other file browser on my system works that way!

• Eventually Company decides “agile will fix things”
• Developers are told to work agile but the only stakeholder they talk to is the PO, who talks to PM, who talks to Sales, who talks to Customers
• PM&Sales don’t want to deliver an unfinished/unpolished product so they give a review every sprint, by themselves, based on what they think the customer wants (they are Very Clever)
• A year or two later the project is delivered and the customer is predictably unhappy.
• Management says “how could this have happened!” and does it all over again.

Also English is an odd germanic-romance bastard child that Western Europeans tend to like because it has a decent number of cognates for everyone and a simple grammar IF you’re only aiming for simple conversational English. The barrier to entry is quite low, especially if you don’t give a shit about having a thick accent and straight up mispronouncing tricky words (as anyone knows who had a conversation in English with a non-fluent Italian/Spanish/French person).

OTOH German used to be relatively widely spoken in Eastern Europe, and Slavic languages also use declensions AFAIK, and also even post WWII German held quite a bit of momentum in academic circles.
So if the Soviet block had gone the Chinese route and become an economic behemoth instead of withering and dying at the dawn of the Information Age, German being the lingua franca (or at least giving English a run for its money) would have been a distinct possibility IMO.

Hell, pass init=/bin/yes and you’ll see even more greatly reduced RAM usage!

❯ ps aux | grep /usr/lib/sys | awk '{print $6}' | sed 's/$/+/' | tr -d '\n' | sed 's/+$/\n/' | bc
266516

So that’s 260 MiB of RSS (assuming no shared libs which is certainly false) for:

• Daemon manager
• Syslog daemon
• DNS daemon (which I need and would have to replace with dnsmasq if it did not exist)
• udev daemon
• network daemon
• login daemon
• VM daemon (ever hear of the principle of least privilege?)
• user daemon manager (I STG anyone who writes a user daemon by doing nohup & needs to be fired into the sun. pkill is not the tool I should have to use to manage my user’s daemons)

For comparison the web page I’m writing this on uses 117 MiB, about half. I’ll very gladly make the tradeoff of two sh.itjust.works tabs for one systemd suite. Or did you send that comment using curl because web browsers are bloated?

For another comparison 200 MiB of RAM is less than two dollars at current prices. I don’t value my time so low that I’ll avoid spending two bucks by spend hours debugging whatever bash scripting spaghetti hell other init systems cling onto to avoid “bloat”. I’ve done it, don’t miss it.

What? I’m not privy to RedHat/IBM/Google’s internal processes but they are all massive FOSS contributors at least some of which I assume are using Agile internally. The Linux kernel is mostly corpo-backed nowadays.

The development cycle of FOSS is highly compatible with Agile processes, especially as you tend towards the Linux Kernel style of contributing where every patch is expected to be small and atomic. A scrum team can 100% set as a Sprint Goal “implement and submit patches for XYZ in kernel”.

Also agile ≠ scrum. If you’re managing a small github project by sorting issues by votes and working on the top result, then congratulations, you’re following an ad-hoc agile process.

I think what you’re actually mad at is corporate structures. They systematically breed misaligned incentives proportional to the structure’s size, and the top-down hierarchy means you can’t just fork a project when disagreements lead to dead ends. This will be true whether you’re doing waterfall or scrum.

Is that even a stated goal? I swear we’ve been waiting for that to exist for the better part of a decade. It would solve so many issues and comes up in every discussion about Javascript, yet the powers that be seem to have zero interest in pushing this forward.

What even are GCC’s advantages in 2024, besides “we painted ourselves in a corner with proprietary extensions” (e.g. Linux)? That aside I personally only see upsides to clang, but I don’t routinely do C work and maybe I’m missing something.

I wasn’t very old then but the main thing was RAM. Fuckers in Microsoft sales/marketing made 1 GB the minimum requirement for OEMs to install Vista.

So guess what? Every OEM installed Vista with 1 GB of RAM and a 5200 RPM hard drive (the “standard” config for XP which is what most of those SKUs were meant to target). That hard drive would inevitably spend its short life thrashing because if you opened IE it would immediately start swapping. Even worse with OEM bloat, but even a clean Vista install would swap real bad under light web browsing.

It was utterly unusable. Like, everything would be unbearably slow and all you could do was (slowly) open task manager and say “yep, literally nothing running, all nonessential programs killed, only got two tabs open, still swapping like it’s the sex party of the century”.

“Fixing” those hellspawns by adding a spare DDR2 stick is a big part of how I learned to fix computer hardware. All ya had to do was chuck 30 € of RAM in there and suddenly Vista went from actually unusable to buttery smooth.

By the time the OEMs wised up to Microsoft’s bullshit, Seven was around the corner so everyone thought Seven “fixed” the performance issues. It didn’t, it’s just that 2 GB of RAM had become the bare minimum standard by then.

EDIT: Just installed a Vista VM because I ain’t got nothing better to do at 2 am apparently. Not connected to the internet, didn’t install a thing, got all of 12 processes listed by task manager, and it already uses 500 MB of RAM. Aero didn’t even enable as I didn’t configure graphics acceleration.

Wait until you learn about debhelper.

If you use a debian-based system, unless you have actively looked at the DH source, the one thing that built virtually every package on your system, you do not get to say anything about “bloat” or “KISS”.

DH is a monstrous pile of perl scripts, only partially documented, with a core design that revolves around a spaghetti of complex defaults, unique syntax, and enough surprising side effects and crazy heuristics to spook even the most grizzled greybeards. The number of times I’ve had to look at the DH perl source to understand a (badly/un)documented behavior while packaging something is not insignificant.

But when we replaced a bazillion bash scripts with a (admittedly opinionated but also stable and well documented) daemon suddenly the greybeards acted like Debian was going to collapse under the weight of its own complexity.

ls -l /proc/xxx/{fd,syscall}

Camera pans down to resource locks hiding under the floorboards

You’re describing proper incident response but I fail to see what that has to do with the status page. They have core metrics that they could display on that status page without a human being involved.

IMO a customer-friendly status page would automatically display elevated error rates as “suspected outage” or whatever. Then management can add more detail and/or say “confirmed outage”. In fact that’s how the reddit status page works (or at least used to work), it even shows little graphs with error rates and processing backlogs.

There are reasons why these automated systems don’t exist, but none of these reasons align with user interests.

To be annoyingly nitpicky, how is “unnecessary” defined in this context? Whitespace is usually “unnecessary” but I quite like it for readability.

I broadly agree with you though, the W3C spec changes things.

> Clicks on <br>
> Example is <br />

The actual thing that matters is that the / is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing /. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.

I wouldn’t recommend sway to someone who isn’t actively looking for a tiling WM, I would recommend finding a good spotlight equivalent to use on KDE as that will still be less customization work than it would require on barebones sway (which is hardly usable).

It’s not as bad nowadays that apps yielded to GNOME’s bullshit. Back when GTK2 apps were still common… Urgh. Plenty of apps were broken without it for no good reason.

I like opinionated UX - I use sway - but GNOME’s approach is incompatible with “general use” and only works (for now) because of canonical’s weight and ability to impose their vision as the only vision.

Also they didn’t replace the tray with a better way to manage background apps, so they can suck a dick on the UX front.

The fucking system tray. Which literally every other DE and mainstream OS out there supports because some apps depend on it and break if it doesn’t exist.

Last I checked GNOME devs said “no, we will never support it, because we’ve DePRecATeD the tray in GTK”.

It’s functionality so basic I have 3-6 apps which depend on it at any time on my work machine. Anyone saying it doesn’t fall under “basic functionality” is either a GNOME dev or a troll.

The kind of farming that makes any money isn’t slow work.

It is, however, tangible work with tangible results. Unlike spending months changing the polarity of nanoscopic silicon structure for the non-appreciation of an utterly clueless salesperson whose braindead ideas will have left the world in a worse state than you found it despite anyone’s best efforts.

I should seriously get into woodworking. Kidding. Sorta.

Hahaha that’s what frontend devs think, but the backend requirements are just as vague: “Just make this button work”. In my example all the requirements would actually be figured out bit by bit over months, nevermind the prescience required to foresee future architecture-breaking features or scaling requirements. At least you can make a mockup and get instant feedback, flawed as it is.

On either side it takes experienced engineers to suss out actual requirements from customers/PMs. The main difference is that the backend (especially on the infra/devops side) is only accountable to itself if everything goes well, but ironically that means no-one knows or cares about the amount of engineering that goes into keeping PMs blissfully ignorant of the risks and complexity.

I love shitting on Fullstack devs as much as the next guy. However, sometimes it really just does make sense for an (often internal) product maintained by a one-person team, and it doesn’t have to mean that the organization doesn’t value them. I’ve seen it happen.

However I would not recommend it as a career path because it’s essentially impossible to tell what you’re getting into when you get hired. Could be what I just described, could be that you inherit the full responsibility for a 20 year-old perl+php5+xhtml+angularJS mess.
I think it can only truly make sense if you work independently and get to build projects to your own quality standards, assuming you manage to find a “scope is small enough that specialization doesn’t make sense” niche. This is very hard which is why in practice “full stack” tends to mean “master of none but good enough to get a product out the door cheaply”.

Real back-end requirements: when x, y goes in (in JSON-as-an-XML-CDATA-block because historical reasons), I want you to output x+y+z+æ+the proof to P=NP.

æ will require you yo compile x+y in CSV, email it to Jenny, who will email back the answer. She doesn’t quite know how to export excel sheets though so you’d better build a robust validator. No, we don’t know what æ is supposed to look like, Rob from Frontend knows but he’s on vacation for the next 8 months.

The request must be processed under 100 ms as the frontend team won’t be able to prioritize asynchronous loading for another 10 sprints and we don’t want the webpage to freeze.

And why does your API return a 400 when I send a picture of my feet? Please fix urgently, these errors are polluting my monitoring dashboard and we have KPIs on monitoring alerts.