radonek

Small phones do exist. I'm quite happy with my Unihertz Jelly.

Umm, if I read it correctly, your barman pours Guinness into 100MB glass and empties rest of the bottle into drain. I'd rather drink straight from the bottle. Like, you know, the cat does it.

Just look at the project site (which at this point is a README on github). I see a few lines about upgrade issues, absolutely nothing about project itself. What improvements or changes over Xorg are implemented? Roadmap of future changes? Why should I pick this over Xorg?

Instead, we get pageful of whining about how bad bad big tech pissed on authors cornflakes. Hate? I don't see any reason to hate the guy. But I also don't see a single bit of reason to take him seriously.

Thanks for reference. This pretty much confirms what is written between lines on linked site.

ORM is not as much solution to a problem as it is way of doing things. Certain kind of programmers observe that SELECT is kinda like getter, UPDATE is like setter and so on… It looks like cool abstraction, relatively straightforward to implement and most people working with databases toy with their own ORM code, have fun and thinks themselves very clever. Think of it as a rite of passage if you will.

…until they try to do JOIN. Or subselect. Or CTE. Or just about any other powerful SQL feature. Materialized views, triggers, sharding, atomic operations, you name it. At which point ones who are actually clever realize this idea has some serious limitations and drop it. Not because it can't be done – there are some nifty and well working ORMS out there – but because its bound to end just as complicated as sql itself. So why bother?

IMO main reason for existence of the ORM libraries is because back in the day, true object databases failed to take off for various reasons.

Absolutely. I've hardly ever done bieliptic transfer in KSP, but I stick to bieliptic plane changes for almost every big inclination change. Δv savings can be huge.

Services should be designed either as providers, which herd data and do nothing on their own, and workers which actually do stuff but hold no data of their own. Think daemon with a REST api, siting on a database and cronjob implementing some business logic.

This pattern avoids transitive dependencies, especially "errors from faraway lands".

Executive summary: "Kernel devs refused to drop everything and immediately start rewriting their code in Rust, which means that linux is inevitably doomed."

This seriously reminds me of Java zealots in worst days of Java Everywhere circus.

I'd say find some screenshot of Windows 95 with multiple applications running and marvel at it. Google Workspace administration console is good example of UI in many ways less capable and useful then what I used twenty years ago. To name just a few:

- listviews are limited to 50 items. MSDOS apps running on 640kB memory could do better back in eighties.

- Adding a new item does not refresh listview. I had wits to do that when I was 13yo toying with qbasic.

- UI "windows" are just floating <div>s that can't be moved, with controls wherever UX monkey happened to have dropped them. Heck, even the (fake) close button can't have consistent left or right position. Compared to that mess, Windows 3 apps look like work of art.

- Many actions take long clock-to-display time. How come that rendering a few lines of text and some buttons is slower on gigahertz class multicore machine then pitiful 200Mhz celeron?

- Even the early, amateurish web apps from nineties, pushed through pathetic dialup internet had the common sense to check session timeout BEFORE displaying a form for user to fill in. Google today? Not so much.

I could continue, but this makes me sad.

I hate the way GUI apps are devolving back to nineties. Resizable windows, clipboard, theming, menus, keyboard shortcuts… stuff that made computers easier to use is disappearing. Apps nowadays are created by graphic designers who don't know what color contrast is and UX specialists who never heard word ergonomy, directed by people who consider wheel reinventionalism to be height of innovation.

That was fun. But I miss some.

105102414410138859640127147104

Once upon a time, I was tasked to rewrite build scripts for windows based team from .bat files to bash scripts (via a git-bash). People on that team were not exactly unix fans, in fact they resisted hard almost everything coming from us linux weirdos. But reduction in build time was so big they asked for this and embraced it with genuine love.

I, for one, see this as improvement, affixed cap is convenient most of the time. If it's not, its easy to tear it away.

IMO real problem with caps is that this was not invented by VC backed startup, which makes it ideological challenge to some people.

to quote about distro packages: "To be blunt, this dependency management system never should have been allowed. It caused no end of confusion for everyone…"

Yeah, package management that actually works must be terribly confusing to some people.