ragnese

I read them, but I'm not sure what point you're trying to make, or why it's directed at my comment. I mean that genuinely.

This Xfce dev says that GTK4 is less capable than GTK3, and they feel that GTK5 will continue in that direction. They also acknowledge certain things in the first comment:

> [0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me.

>

> [1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.

If the GNOME guys took out stuff from GTK4 or 5 for bad reasons, then I don't like that, either. Which is basically exactly what I said. However, it sounds like some of these changes would be hard to do and maintain well, such as cross-process embedding. Perhaps the GNOME devs made a decision to focus their surely limited resources toward things they think will be long-lasting. And, perhaps, by their estimation, trying to support Wayland and X11 by adding (and maintaining) tens of thousands of lines of code would be a big burden--especially if they believe that X11 is not going to be super-relevant in the near future. I don't agree with that estimation, and I assume that it'll be a very long time before X11 isn't necessary anymore, but so be it.

All that said, it still has nothing to do with Mutter, which is why I replied to the comment that I did. Because GTK, and Mutter, and GNOME Shell, and GNOME apps, and non-GNOME GTK apps, are all different things, and this post was about Mutter.

Point taken on GTK, and I can't really disagree since I haven't even poked at writing a GTK GUI in many years.

But, you still couldn't resist complaining about the UI implementations, which sounds more like complaints about GNOME apps and GNOME Shell. Who cares if you think that GNOME Shell looks like it accommodates touch screens? Firefox, for example, uses GTK and doesn't seem to look like a touch screen UI to me as I'm typing into this text box.

There are multiple angles. As the stewards of GTK, they should, IMO, try to keep it flexible and customizable to whatever extent is manageable and reasonable. This post is about Mutter, which is a window manager, which should have very little to do with the app "ecosystem". They can, and should, do whatever the hell they want with Mutter, GNOME Shell, Nautilus/Files, etc.

Even in the link you posted, they're talking about GNOME, not GTK.

Probably yes. And, good. It's free software. I still use GNOME Shell, and the minute the make a change that I don't want to deal with, I'll change to something else. Easy as that.

Yes. The first time I heard/read someone describe this idea of managing parallel agents, my very first thought was that this is only even a thing because the LLM coding tools are still slow enough that you can't really achieve a good flow state with the current state of the art. On the flip side of that, this kind of workflow is only sustainable if the agents stay somewhat slow. Otherwise, if the agents are blocking on your attention, it seems like it would feel very hectic and I could see myself getting burned out pretty quickly from having to spend my whole work time doing a round-robin on iterating each agent forward.

I say that having not tried this work flow at all, so what do I know? I mostly only use Claude Code to bounce questions off of and ask it to do reviews of my work, because I still haven't had that much luck getting it to actually write code that is complete and how I like.

Well, that's how Mr. Stenberg described it, but he wasn't the one using them. I don't know how the contributor feels about his AI tool(s).

It was AstroTurfed to hell and back here and on Reddit. I know that much.

> Setting aside the objections some have to exceptions generally: Checked exceptions, in contrast to unchecked, means that if a function/method deep in your call stack is changed to throw an exception, you may have to change many function (to at least denote that they will throw that exception or some exception) between the handler and the thrower. It's an objection to the ergonomics around modifying systems.

And if you change a function deep in the call stack to return a different type on the happy path? Same thing. Yet, people don't complain about that and give up on statically type checking return values.

I honestly think the main reason that some people will simultaneously enjoy using Result/Try/Either types in languages like Rust while also maligning checked exceptions is because of the mental model and semantics around the terminology. I.e., "checked exception" and "unchecked exception" are both "exceptions", so our brains lumped those two concepts together; whereas returning a union type that has a success variant and a failure variant means that our brains are more willing lump the failure return and the successful return together.

To be fair, I do think it's a genuine design flaw to have checked and unchecked exceptions both named and syntactically handled similarly. The return type approach is a better semantic model for modelling expected business logic "failure" modes.

I'm with you when it comes to checked exceptions. I have several ranty comments on this site about how everyone has been wrong to cargo-cult hatred of the feature for the last decade or so.

But, I'd still rather have safe/correct null type checking, because at the end of the day, I can always write MY code to return a Result/Try/Either type instead of throwing unchecked exceptions for expected business logic "failure" paths.

That's a fair point. You don't have to write Java with giant graphs of objects-in-objects-in-objects and heavy mixing of (often mutable) data and logic in the same classes, but it's hard to deny that the culture, conventions, and idioms in the Java ecosystem can be quite different from the culture, conventions, and idioms in Kotlin.

On the other hand, when I see Kotlin code that's not written by JetBrains (especially on the backend), it often does just look like Java code with cleaner syntax...

That's a whole huge can of worms, too. Coroutines and the suspend keyword were a great innovative feature at the time (very clever implementation on the JVM and good API design given the limitations of the implementation and syntax design constraints), but now that Java has so-called virtual threads, you don't "need" Kotlin for convenient(-ish), simple(-ish), scalable, structured concurrency like you used to, either.

One could rightly debate over whether Kotlin's coroutines design and APIs are better than Java's virtual threads for writing asynchronous code. But, at the core, the story used to be that Kotlin had coroutines and lightweight structured concurrency "built-in" (with a blessed first-party helper library for the actual concurrency part) and Java did not have anything that accomplished the same goals. Now it does.

EDIT: Forgot to confirm that I do, in fact, use Kotlin for a fairly large and moderately complex backend system (multiple deployed systems, including one HTTP REST-ish API).

I'm of two minds about it.

I started working with Kotlin back when Java was still a very ~~stagnant~~ stable language. I definitely find Kotlin's syntax to be much more comfortable, expressive, and in many ways much more simple than Java's.

But at this point, the only big technical features that still put Kotlin over Java for me is the handling of nulls by the type system (which is, admittedly, mitigated decently well in practice by Java tooling configurations and ugly annotations), and value types (zero heap-allocation wrapper classes).

Another thing to keep in mind is that now that Java is actually adding features again, the Kotlin developers will have to also play "catch-up" to Java in ways that it didn't have to when it first gained popularity. It puts Kotlin in an awkward spot when Java's implementation of sealed classes and interfaces was initially better and more flexible than Kotlin's, or when Java's `switch` is now more powerful than Kotlin's `when`, etc.

Kotlin is also betting heavily on their multi-platform stuff, which I'm skeptical about. It seems to me that it will further slow the ability to add useful features to the language if you have to cater to the lowest-common-denominator between Java and JavaScript (and Objective-C? -is that how it works for iOS?) runtimes. Instead of being the best language for a given platform, it'll just be a pretty good language for a few platforms. I wish them all the best in dethroning JavaScript from infecting every computing platform and domain, but I'm just skeptical.

So, honestly, I don't actually recommend people start new projects in Kotlin. I'd suggest going for Java, or something that's meaningfully different in semantics and philosophy like Clojure or Scala. I say this, but I'm not actually sure that I'd be able to follow my own advice, because I really don't want to have to stomach Java's syntax, idioms (way too many annotations), and stupid null handling.

Well, 4:3 is less wide than 16:9 or 16:10 or whatever else we're doing these days.

But, I do agree that this was likely never the driver. In fact, I've always thought the "obvious" explanation is simply that window controls and title bars are at the top, and since tabs are like nested windows inside a window, they would follow basically the same patterns...

I always felt the same way while I was in grad school. The fact that my tuition was covered by working as either a teaching assistant or as a research assistant on a grant, AND that I actually got a paycheck that was mostly-enough to survive on, was something that I was very grateful for.

It was not something one could live on long-term (no chance to save money whatsoever, could never buy a home or decent car, etc). But, I wasn't starving and I wasn't taking on debt.

At the same time, it is a sacrifice. Most of my friends the same age were making "real" money, buying homes, going on nice vacations, saving for retirement, etc. So, I get extra irritated and defensive when I hear people who have no idea what they're talking about repeat conspiracy theories about science and academia. If I wanted to be a rich scam artist, I'm pretty sure there were better options than a science PhD...

Is this different than how military spending is spread, though? That's not a rhetorical question- I'm not tuned in enough to know.

Even though I've seen military bases in the middle of nowhere, I've certainly seen some bases and defense contractors (Raytheon, Lockheed, etc) in non-rural areas.

I'm cynically, and pessimistically, kind of assuming that it's really just about what's being funded in this case. Military spending is pretty much always supported by both politicians and the public, whereas there is a VERY strong anti-science and anti-academia wave in our culture at the moment (even more so than I always used to think there was...).

You probably know better, and I probably should know better than to bother engaging, but...

Why would you conflate giving a computer an objective command with what is essentially someone else giving you access to query a very large database of "information" that was already curated by human beings?

Look. I don't know Elon Musk, but his rhetoric and his behavior over the last several years has made it very clear to me that he has opinions about things and is willing to use his resources to push those opinions. At the end of the day, I simply don't trust him to NOT intentionally bias *any* tool or platform he has influence over.

Would you still see it as "censoring" a LLM if instead of front-loading some context/prompt info, they just chose to exclude certain information they didn't like from the training data? Because Mr. Musk has said, publicly, that he thinks Grok has been trained on too much "mainstream media" and that's why it sometimes provides answers on Twitter that he doesn't like, and that he was "working on it." If Mr. Musk goes in and messes around with the default prompts and/or training data to get the answers that align with his opinions, is that not censorship? Or is it only censorship when the prompt is changed to not repeat racist and antisemitic rhetoric?

Thank you for sharing that experience. It certainly meshes with my suspicions. I'm actually currently experiencing almost the same phenomenon in my house. My refrigerator was here when I moved in five years ago. It has a service sticker on it from 1997! I don't know exactly when this model left the factory, but if it's "only" 28 years old that would mean that things have gotten worse even since the 90s.

The only issue the fridge has had is that one of the defroster heater coils died (it has two- I guess because it's a side-by-side style, so the freezer part is tall). It wasn't very hard to replace. In fact, the hardest part was actually finding the part, itself.

> Did things always feel like this?

I wonder about this, too. What were things like in, say, the 1960s? When you went to buy a new appliance, did you feel like the appliance was designed to intentionally screw you as much as possible via planned obsolescence, anti-consumer-repair measures, purchased "warranties" that had tons of fine print so you could never actually benefit, etc?

Even as a kid growing up in the 80s and 90s, I learned that everything was a scam. How many times did child-me watch a TV commercial (on the childrens' channels) that showed a remote-controlled toy car doing extremely cool stunts and riding on rocks and dirt, only to get it for a birthday present and have it not able to move at all unless it was on a totally flat, level, surface? Or, have you ever seen a commercial for a toy like the "Rock 'em Sock 'em Robots"? I'm sure they're on YouTube. Then once you see the toy in person it's pathetic.

I've truly been taught my whole life that everything is a scam.

I have the same mentality as you. But, rather than form an opinion on whatever EU regulation is being interpreted as "requiring" these steps from Google et al, I think I'm going to assert that it's a red herring.

The real issue, IMO, is that it's still too hard to distribute and install applications on my general-purpose computing devices! You can't be on Google's app store if you aren't a "real business" with a physical address and everything? Fine. Let's just distribute our apps on F-Droid, or by just releasing APKs in our GitHub pages, etc.

At least that's still possible with Android. But who knows how much longer they'll even allow that?

I can't decide if username checks out or not...

> The issue I think you're outlining is whether someone builds because they believe in their product and its value or if they are profiteers charading as believers.

I do agree with your overall criticism of short-sightedness and the short term incentives of VC and the stock market, etc.

But the people involved are not quite as binary as you lay out in the quote above. You can't discount the group of people who really do start out as true believers and who become seduced/deceived by VCs. Some of these VC types are real vultures. They'll convince the founder that the best way to share their vision or product with the most people and do the most good for the world is to let the VC guys use their capital to scale up and expand the reach of the product, etc. The money surely helps to lower one's skepticism/cynicism, but I can imagine that it must be very hard to say no to getting your dream project out to millions of people.

No doubt! I just like to point out the bullshit when I can. :)

Okay, so "fruitless" wasn't the right word. If you try to build an actual house out of LEGO bricks, you can eventually succeed and therefore the endeavor was technically "fruitful." I think I should've described it as "wasteful" effort, or as an inefficient use of brilliant minds' time.

For my specific example of JVMs on lambdas, I wasn't really thinking about GraalVM. I was more thinking of all the hacky, fiddly, things that people were doing to "warm up" their JVM-based lambdas. Like some of the stuff described in this article I just randomly grabbed from a web search: https://medium.com/@marcos.duarte242/keeping-your-aws-lambda...

The reality is that JVM languages were just the wrong tool for the job of writing short-lived applications.

Even though I wasn't really thinking about GraalVM, it might not be shocking that I don't really like it either- for the same kind of reason(s). Java was designed as a fairly dynamic language: you have runtime reflection, dynamic class loading (hot swapping), and various other (admittedly niche) features. So, Java code destined for GraalVM has to be written differently than Java code destined for a standard JVM runtime, which is an inverted way of saying that the nominal goal of GraalVM is technically impossible (you can't, generally, write a native compiler for the Java programming language). So, again, we're taking a language that was designed and optimized for specific runtime properties and we're forcing that square peg into the round hole of AOT compilation. You want native performance? Use a native language!

It feels like someone trying to design a hammer to also be a really shitty screwdriver. Why not just use a hammer sometimes and a screwdriver other times?

For sure. I agree with everything you say, and I've experienced the same thing 100 times, myself--including the specific scenario of speeding up someone's MATLAB code by multiple orders of magnitude by vectorizing the crap out of it. People seem to be almost drawn to quadratic-or-worse algorithms, even when I'd expect them to know better.

I'm just a little bitter because of how many times I've been shushed in places like programming language subreddits and here when I've pointed out how inefficient some cool new library/framework/paradigm is. It feels like I'm either being gaslit or everyone else is in denial that things like excessive heap allocations really do still matter in 2025, and that JITs almost never help much with realistic workloads for a large percentage of applications.

Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough?

All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...

I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms.

Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's all negligible.

But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language...

/s

No, I think I just misread the comment I replied to. :/

Look into where the term "open source" came from (the "Open Source Initiative").

Here's a quote from Wikipedia (https://en.wikipedia.org/wiki/Open_source):

> Open source as a term emerged in the late 1990s by a group of people in the free software movement who were critical of the political agenda and moral philosophy implied in the term "free software" and sought to reframe the discourse to reflect a more commercially minded position.

The GPL and Free Software were always political from the very moment Richard Stallman conceived of the GPL.

The U.S. still has competition from Europe and China, no? I'm not convinced that the puritanical fanatics would ever make the rational decision to ease up on their efforts for the sake of the economy. For non-Western examples, see Iran and Afghanistan since the mid 20th century.