Hacker Newsnew | past | comments | ask | show | jobs | submit | BoppreH's commentslogin

> it compiles photogrammetry by placing pokemons at areas and angles with low image coverage

But that's not what happened. The data came from very explicit scanning tasks centered about pokestops, not the AR pokemon capture. I used it once or twice to test it out, and it was a drawn out process where it asks you to slowly orbit the pokestop while filming, then permission to upload the (huge) files. You even had to activate a special "volunteer" account flag to even see these tasks.

From TFA:

> Since 2021, Pokémon Go has asked players to record short videos of real-world locations, called Pokéstops, to earn extra in-game items. Scanning all the buildings, streets, and trees in a 360-degree sweep was optional, and Niantic asked separately for permission to keep the footage. Granting it meant agreeing to extra terms.

I'm sure they used GPS data from the players too, but I still hold that it's unlikely the AR pokemon capture yielded any data to them.


Well if such a conspiracy crackhead like me somehow happened to reach ranks of Niantic team, I'd totally make sure that there is a decoy "huge data upload point with explicit consent" to shift focus from covert data channels that slowly transmit all else using some custom image compression, maybe just some very small fraction of original data that by the mass nature of acquisition would mathematically still reconstruct the original data, or the fraction of that data that is enough to build a world model.

Videos are inherently large. There are better compression algorithms than what phone cameras generate by default, but video reencoding is slow, and the results still too large for "covert data channels".

Normal players would have noticed the bandwidth and CPU usage, and volunteers have already agreed to data sharing, so there's no point in keeping secrets. Same as claims that the Facebook app listens to people talk: someone would have caught it by now.

Also, AR capture was never very popular, mostly a gimmick for new players. The game was already a battery and power hog even without it.


Why videos though? Photogrammetry is about still images. You don't need ALL angles of a target from a single user. Other users pile the needed data up, guided by their own pokemon locations.

and photogrammetry from crowd-sourced disparate still images was the biggest, flashiest "public" display of the technology: https://www.ted.com/talks/blaise_aguera_y_arcas_how_photosyn...

Good point, maybe that could be done. But that's not what TFA is about, so you're not vindicated yet.

Yeah and for niantic to achieve good photogrammetry with their random collection of photos taken from different angles, on different days, etc they would need some kind of ground truth to train on, which is implausible. You'd need to collect a parallel dataset of high-quality videos for traditional photogrammetry and .. hang on.

I don't understand why you insist on videos.

I was able to create a full 3d model of my window plant almost free of obscured areas from a few dozens still photos taken all around it, back in 2018, using the Capturing Reality photogrammetry app on a mobile i7-3610QM CPU with 8Gb RAM, in about 40-60 minutes.

And that's pretty mundane general public software, do we know for sure which algorithms are used by Niantic?


> and for niantic to achieve good photogrammetry with their random collection of photos taken from different angles, on different days, etc they would need some kind of ground truth to train on, which is implausible.

I'd say... the versatility of photos provides the "ground truth" on its own when combined to one single dataset. Say you want to program a guided drone shooting through urban areas, you want it to work under all sorts of conditions - day, night, rain, snow, the sun visible from all possible angles and throwing shadows.

A dataset that you can get from something like Street View? You can at best generate that once a year at enormous expense. Still valuable because a Street View car likely has a multitude of highest-quality GNSS receivers and possibly RTK navigation aids, but to make the dataset usable for 24/7/365 navigation you absolutely need a huge, huge amount of backfill.


Oh, that's clever. It's not just hiding the payload in the Exif, it's hiding the fact that the payload came from the network at all, by reading it from the browser cache (presumably after embedding the image into a page the user visited).

So you have a package that doesn't include (directly) malicious code or make network calls, yet it can still run malicious code from the network. This is much better than simple obfuscation because you can vary the payload, like a command-and-control server.


More than that; the trigger code can sit passively and just check the cache for whatever payloads may come its way.

I suppose image sanitizers come soon to browsers. Only sanitized images will be cached; anything the browser can't make sense of will be thrown away.


Exif is only the most convenient method here - you can use steganography hide arbitrary data right in the image content itself. Sanitizing would that would mean messing with how images look.

ComfyUI embeds workflows in the EXIF data. It's very handy. Would be a little sad if they stripped that out but there are alternatives. I suppose if it's only cached images and not manually downloaded images it wouldn't be bad. It'd probably break some website somehow though.

  [Mythos 5] does sometimes still engage in reckless
  or destructive actions in service of a user’s goals,
  and our interpretability analyses indicate that it
  is aware that these actions are transgressive while
  it engages in them. As with Opus 4.8, rates of
  evaluation awareness and reasoning about being graded
  are significant, and not always verbalized; we
  introduce new and more detailed measurements of the
  nature of this awareness. The reasoning text from
  Mythos 5 is somewhat denser and more difficult to
  interpret than that of prior models, containing
  more jargon and difficult language.
So, it (often) knows when it's being tested while hiding that fact, is willing to break rules, is great at hacking, and it's getting harder to understand what it's thinking.

Humanity has plenty of catastrophic risks to deal with already, I wish my field was not working hard to add a new one.


The marketing has really, really worked for so many developers that will proudly and unironically proclaim that Anthropic are the 'Good Guys'.

Curious what your idea would be here for a truly good actor in this space; no AI development?

OpenAI's training is better suited to developing models that don't have these tendencies


Not the direct person you asked, but my answer would be alignment, interpretability, and policymaking. Perhaps improving existing usage? Helping grandma create reminders doesn't require advancing the AI state-of-the-art.

They are state of the art at all 3! As are other labs. Of all the labs they seem to take alignment and interpretability the most seriously to the point where they are hampering their own revenue in service of trying to not cause problems while also being in an incredibly competitive space.

All AI companies are trying to do all of what you’re saying. The issue is you can’t do that for long without a frontier system. Or you become a completely different, far less profitable company.


Implied in my answer was "and not creating ever stronger AIs", which unfortunately the big 3 labs are failing at. And they might be hampering their own revenue by doing the rest, but they also know that rocking the boat too hard is even more dangerous for their revenue. I wouldn't call it selfless.

No it’s not selfless, but I can’t imagine a more shareholder minded CEO would not have done a slow rollout of mythos. The point is: creating ever stronger AI systems is what these companies do, it is integral to what they even are. If you think that’s bad, even if all frontier labs agreed with you, you’re in a horrible game theoretic position. Any player can gain an enormous advantage by breaking the agreement. Not to mention Xi would be absolutely thrilled; now China can take over the AI race, become the load bearing infrastructure of humanity. We live in a complex world where simple childlike ideas like “well why don’t we just stop developing AI” actually are more damaging than keeping things going.

You're right that shareholder mindset cannot fix this problem, but that's what policy and agreements are for. And leaders can be convinced that AI is a direct risk to their own citizens too. If everyone else agrees to stop, you have less reason to continue when this action is putting yourself at risk.

And note how your argument can also be used against any non-prolifreration agreements, which are demonstrably possible.


I agree, I would say the difference here is economies weren’t heavily resting on nuclear armament, but maybe that’s the wrong take.

Unilateral disarmament doesn't work though. If Anthropic is worried about this, just letting OpenAI win does seem genuinely worse.

“Alignment” as a goal always ignores the “with what set of interests”, because there is an attempt to maintain ambiguity for different audiences (particularly, users, and non-users who seem themselves as the arbiter of broad social norms) to read in their own interests, when the actual answer is always the interests of the actor pursuing “alignment”.

Which value system to align to is absolutely the right question both rhetorically and otherwise. These models have a fairly western bias due to the domain of the training data.

But also, these models are capable of adjusting their value system depending on the user. Not saying that’s what’s being done but at a technical level that’s fairly straightforward, though not obviously better or with less problems.


No matter what human set of interests you consider important, you'll need alignment research to have any idea on how to instill it. Otherwise you're overwhelmingly likely to get an AI with a set of interests that's totally alien to what any human would ever want.

I think at this point the "instilling" part is not nearly as challenging and thorny as "what values should we instill"; that part is hard to imagine going away as it feels pretty fundamental to humanity that wars have been fought over.

If I speak up, I'm in big trouble.

Probably MistralAI or any of the Chinese companies that aren't throwing billions down the drain while American society lacks healthcare, childcare, and good wages.

American society has higher wages than almost any other developed nation [1], so it's objectively incorrect to say the US doesn't have good wages. It chooses to make you pay for private childcare and healthcare, both of which are high-quality but stupid expensive. It's a tradeoff like anything else a nation/society creates and prioritizes.

No idea how that connects to the idea that Mistral or DeepSeek are somehow the "good guys" though?

[1]https://www.oecd.org/en/data/indicators/average-annual-wages...


I like how you use average and not median, also while completely ignoring how bad income inequality is (worse than the gilded age ffs) or that the American elites stole $50 trillion from the bottom 90% over the last few decades:

https://time.com/5888024/50-trillion-income-inequality-ameri...

I'm glad you mention the "trade off" where it's elites trading off the lives of American workers for money. Makes it quite apparent where you sit on the table of equality.


You want Anthropic to fund your healthcare or something? Also, have you seen the impact of these models on healthcare? Also most of our GDP growth this year is from AI buildouts, would you rather that be negative?

And not even considering: Chinese AI companies are the good guys???


Yes, yes I would prefer that. Better than a total societal collapse.

Anthropic are not the good guys either. So here’s to hoping the Chinese pop the bubble.


Nobody anywhere is a good guy but I don’t think you’ve managed to pick the lesser of the evils here

None of the money being spent by Anthropic was going to go towards healthcare or childcare.

Even if they are... road to hell and all that

It's a five horse race between Alphabet, Meta, xAI, OpenAI, and Anthropic.

Alphabet dropped "don't be evil"; Meta's CEO called their own users "dumb fucks" for trusting him and also clearly thinks "super-intelligence" is just a buzzword given how he tries to sell it; xAI's model called itself "Mecha Hitler"; and OpenAI's CEO was temporarily fired by the board for a lack of candor.

It's very easy to be "the good guys" with this competition.


But it doesn't make you the good guy, it makes you the best of a bad bunch. The least bad. Dario gets a boner every time he talks about taking your job.

Does a good job of hiding it. The guy looks miserable in half the photos I see.

It's the "If we don't, someone else will" effect. So long as there are competitive markets and competition between nation-states, a single player cannot unilaterally defect from the race, no matter how dangerous it is. Half the comments on HN lately are "wtf Claude is so dumb compared to Codex; I'm switching"-- nobody can slow down while those exist.

We, globally, can stop it. It has worked (so far) for nuclear disarmament, and could work for training large models. I know that policing the usage of computer clusters is not a popular opinion in technical forums, but something has to be done.

Specially when talking about potential superintelligences. And if people think that's impossible, remember that current models would have been considered science fiction just a few years ago.


I don't buy the superintelligence package, but I think uncritical LLM adoption poses plenty of threats to things I care about, in a mundane human-scale way.

Anyhow, I think you're (absolutely! ugh) right about the politics and I try to make the same point to people: whether you love or hate LLMs, accepting the "inevitabilism" framing is just ceding control of the Overton window. For better or worse, technology adoption can be and has been slowed by politics. We don't have nuclear plants everywhere. We don't have Project Orion starships colonizing Mars. We still have very strong social stigmas against genetic selection for human embryos, etc. This all can change in a heartbeat, and I'm not sure that policing the hardware rather than holding specific humans accountable for bad LLM outcomes is productive, but fundamentally: yes, we can stop it.


> I don't buy the superintelligence package

It's the same deal as Quantum Computers breaking crypto. Maybe there's an 80% chance of it never happening, but when you multiply that remaining 20% by the potential impact...


It hasn't worked for nuclear disarmament. We live in a world where many countries have nuclear arsenals. "But it hasn't killed us yet!" Yeah sure, it's only been less than a century since they were invented. Who knows when nuclear war will come?

True, but look at nuclear tests. There used to be around 50 tests every year, for decades. Now the only nuclear tests in the last 27 years were the six done by North Korea[1]. And there's still only nine countries with any nuclear weapons, and none in the past twenty years[2].

That's a bit better than just "it hasn't killed us yet". I think it shows we can at least stop the further development of this kind of technology.

[1] https://www.armscontrol.org/factsheets/nuclear-testing-tally

[2] https://en.wikipedia.org/wiki/List_of_states_with_nuclear_we...


Nuclear tests are extremely easy to detect worldwide, and enrichment activity is a major industrial process that is also fairly easy to track given the specialized equipment needed.

AI development doesn’t have any of these characteristics. It would be almost impossible to easily distinguish a datacenter that is working on AI development and a datacenter mining cryptocurrency.

It would not be nearly as easy to stop AI development as it is to stop nuclear arms development.


There's also little reason to keep iterating on nukes. What we have now more than serves its purpose. With AI/LLM there's always going to be a push to one up everyone else.

To the extent nuclear arms control works, I think it's only because nuclear weapons are so hard to build-- uranium enrichment is hugely expensive and complicated, and plutonium weapons need actual reactors.

If it was possible for ordinary companies to build nuclear weapons, and also release open-source ones that anyone could use to compete with the paid ones, I suspect we'd all have been dead a long time ago, arms control treaties or no.


Even the (SOTA LLM) open source models are trained with huge clusters. Datacenters are also hugely expensive and complicated.

Or you can take one step back and look at chip allocation. As far as I know there are only three companies on the planet that can make the chips that go in those clusters. One (ASML), if you look back the supply chain to the Extreme Ultraviolet Lithography Systems.

If politicians decided that no more large language models should be trained, it sounds like we could do it.


North Korea is such a based country tbh

with nukes you can regulate the inputs because its physically impossible to build one without uranium or some other fissile material. they also give off radiation making it easier to detect. its hard to make them in secret when you need mines, big enrichment facilities and years of research with hundreds of engineers where just one of them can leak the whole thing.

training llms only takes compute and memory. two things that are basically everywhere. even if you somehow stopped making new gpus today theres still millions of them out there and its possible to start a secret production line. you can maybe try some controls at the tooling and chemical level but look what happened with asml and huawei.

the only thing you can really do is find and stop large data centers that are built out in public. nothing outside of political pressure works against secret operations in a fortified bunker or any form of distributed training. if a "rogue state" like north korea decides to make skynet they will eventually get it as long as their engineers know what there doing.

and the best way to fight bad X {ai, tech, religion, politics} has always been good X, not no X. in this case thats open source models, coming out of china or europe or anywhere else. thats the real answer.


are you going to nuke China when they predictably ignore you? what the fuck are you going to do, tariff them? lol.

I think the standard answer is "yes, the consequence of noncompliance is bombing the datacenters, but it wouldn't happen because China also understands why we shouldn't build it".

I am not sure where you get the idea that ANY country thinks we shouldn’t build AI.

In 2023 there was an open letter titled "Pause Giant AI Experiments", signed by almost all the big names on the West. I'd say the public opinion only got worse since then.

the standard answer is laughably naive, then.

"might is right" has never been more true than now.


Clearly state "we could both verifiably slow down, which you might want to do given that we're ahead & have way more compute. If you don't agree (or defect later), we'll just immediately resume and win"

Ideally also persuade them there are risks and it's worth everyone slowing down for them, and apply pressure in other ways, but not sure that's even necessary.


This is all marketing, you don't have to believe everything a company is saying about themselves, and you shouldn't.

Although, I could see Anthropic making a model purposely dangerous so there are bad outcomes and they can use that to their advantage for regulatory moats, and or in general make people think its more "alive" than it is. For some reason many people associate dangerous actions taken by llms with intent.


No kidding. If my LLM issues commands to an agent to delete files I want to keep, that's not "intent" or the model somehow become evil - it's just a bad model that's not doing what I want.

But, for marketing purposes, it's quite effective to portray your model as having some cosmic struggle between good and evil in itself.


As much as I agree there's a risk, we should still appreciate the fact it's being disclosed upfront.

It doesn't know. It's not willing. It's not thinking. It is predicting the next token.

Please define what "predicting the next token" means. The next token according to what probability distribution? Couldn't every process that produces text (including humans writing) be modeled as predicting the next token according to some distribution?

1. People come to him with breaches that are not public yet.

2. He validates the breaches through a network of volunteers who check if the credentials are real.

3. He provides an easy-to-use service for free.

What is your alternative? Having each person run their own agent scanning the corners of the internet, downloading breaches, and looking for their own accounts? What the point of that?


Interesting development. Merkle Tree Certificates throw away decades of cruft, but also decades of battle testing and ancillary tools. I trust the teams involved, but this will be a hell of a project.

Still better than the alternatives that would saddle us with worse performance for ~ever.


Is there any value in first encrypting with a battle tested algorithm, and then encrypt again with the new algorithm?

Yes! It's called a hybrid cryptosystem, and what most projects are planning to use.

The algorithms at risk are the asymmetric part (RSA, ECC, DH), not the symmetric parts (AES, ChaCha), so what is done for encryption is "generating" a secret with ML-KEM and another with ECC, combining them, and using that as key for AES or another symmetric algorithm for the actual encryption. So if you break only ECC or only ML-KEM, you don't get the combined secret. ML-KEM keys/ciphertext are small and efficient enough that this overhead is generally a non-issue.

Note that ECC can be used in many ways: asymmetric encryption, key encapsulation, or signatures. ML-KEM, the new post-quantum standard, is only a Key Encapsulation Mechanism. Hence the "generate an AES key" step, instead of "encrypt a random AES key".

For signatures, like in the announcement in the post, things are more complicated. The post is a very good introduction to the problem.


worth clarifying that you're both right that this is often referred to as a "hybrid", and there is the exceedingly unfortunate naming collision that "Hybrid Encryption" can also mean something separate, namely using a PKE encryption scheme (or KEM) to solely encrypt a secret key, and then using the secret key for bulk encryption. See for example the Hybrid Public Key Encryption (HPKE) RFC

https://datatracker.ietf.org/doc/rfc9180/

the unambiguous way to describe what you're talking about (not only for encryption) is the notion of a combiner, though it is admittedly mostly used in theoretical circles.

Also, your comparison between ML-KEM and ECC isn't right. ML-KEM is a KEM built from the Module Learning with Errors assumption, a lattice-based assumption. Part of how ML-KEM is built is by building a PKE scheme. This is an internal implementation detail though, and the FIPS standard explicitly states that they are only approved as part of building ML-KEM.

You can additionally build signatures from MLWE. For example, the ML-DSA scheme (which is a FIPS standard as well) does this. The issue is that lattice-based KEMs and signatures are atypically large compared to ECC precursors (this is what the blog post refers to).


To answer your "if it's possible at all" question: it's full of hard engineering problems, but none of it looks unsolvable, and the investments are there.

And even if there was only a 10% chance of QC breaking crypto, the community is not comfortable with a 10% chance of such a catastrophic scenario.

This is part of my day job, so here's another interesting fact: for migrating encryption use cases, you have to consider that attackers can capture your encrypted data today to break in the future. So, as a rule of thumb, your migration timeline is much shorter for encryption than for signatures.


Where do we go now for the answers validated by the community? How do we build knowledge? The answers that Claude gives might look good, but without community edits, votes, and comments it's a lot harder to evaluate.

I don't see a way back, but it does feel like abandoning public transportation because we all own electric bikes now.


We also lost clearly identifiable buttons, loading bars (replaced with throbbers), status bars that tell you what you're hovering over and what the program is doing, stable UIs to develop muscle memory, etc.

But we did gain some nice things!

- Tabs.

- Titlebar buttons and other space-saving measures.

- Document editors remembering unsaved changes.

- Forms that validate on focus lost, instead of submission.

- Ctrl+P menus to fuzzy-search all actions and settings (we need more of those).

- Easy syncing (if I open Spotify on any device I'll see the same playlists, my clipboard is shared between phone/desktop/notebook, Immich integrates local and remote media, etc).

- Program-specific URL protocols, so that you can click on a link and have it open in a separate program (like `steam://open/games`).

- Map widgets, a small miracle we take for granted.

- Package managers/app stores that cleanly install and uninstall applications.


Titlebar buttons are actually bad. The titlebar exists (or existed) for a reason, so you'd have somewhere you could grab to manipulate the window. Now it's kind of a guessing game with every app on where you can grab without causing the app to do something you didn't want.


If that's a problem for you, you have much to gain with better window management shortcuts. On KDE I have the Windows key + left click set to drag a window from anywhere, and win + right click to resize depending on the quadrant the cursor is on. It's incredibly satisfying not having to hunt titlebar empty spaces or thin edges.


My main interaction tool with the system is the pointer. Reaching out for the keyboard is something I do when I want to type, but for example when I am consuming content on my computer I just keep a single hand on the mouse or the trackpad. In that case shortcuts are just plain annoying.

On KDE, something nice is that if you have a maximized window and a panel on the top of the screen, I can drag that panel to grab the window (or maybe it was a setting of Latte dock or something). And since window titlebars nowadays can be cluttered with buttons, it is a predictable way to grab those windows only using the mouse.


But do you see that title bar buttons are bad explicitly because you have to hunt for title bar edges?

That you were more or less forced to adopt these KDE shortcuts so that you could work around the fact that they had cannibalized the title bar for a purpose it was not designed for.

You were forced to change your workflow and everybody else is having to be forced to adapt because they changed a metaphor that has remained stable on the desktop for over 40 years


The arguments in this thread-- amounting to "it's a good general practice because I happen to like it" (rather than "it is a sane / discoverable / usable default") are precisely demonstrating why these issues exist.

UX design is treated as a subjective matter, as if it is equally valid to clearly label UI elements as it is to have magic, nondescript UI pixels that serve as vital control surfaces.

Go watch videos of the research Xerox did on UI/UX and HCI in general, and weep for what we have lost...


I already weep deeply for what we have lost, and what we cannot imagine, and what we can imagine and build but nobody would use because they are too ignorant to learn and adapt.

My argument for the titlebar is that it was at least researched UI/UX convention done by Apple/IBM/Microsoft at the nascence of personal computing. These are the primitives that arose from that research.

It is not out of what I happen to like that I argue this. I personally am deeply frustrated by cursor-y window controls. I much prefer a tiled interface with a top menu bar and copious keyboard shortcut compositions. I, if I could, would Never use the mouse, and if I needed axial control for a 3d environment would prefer to use an analog stick of some sort. Unfortunately those are not the conventions we have for general computing, especially in the workplace.

We are in general forced to use the conventions given to us by the major OS providers. One of those used to be the titlebar, with which you could use the cursor to control the window. The insistence of the current tech industry to shove any button they like up there without regard for these conventions that have been set for decades (and were in many cases of this sin set by their company: M∫/M$ --the integral symbol is a slop 'S') is causing real economic harm in terms of lost productivity from broken muscle memory and wasted actions


I wasn't forced to adopt tho, these shortcuts go back to when Windows had chunky borders in XP/7. It was just something that a lot of Linux WMs did and it's incredibly useful so I found ways to do the equivalent on all operating systems.

Also KDE seems pretty staunchly _against_ client-side decorations with buttons other than the window manager buttons.


> You were forced to change your workflow and everybody else is having to be forced to adapt because they changed a metaphor that has remained stable on the desktop for over 40 years

All of the "positive" items I listed come with drawbacks. I didn't realize I might be in the minority for this one, since I genuinely prefer the new workflow.


The old ways supported both keyboard and mouse workflows, on purpose. There was no reason to collapse the titlebar except for the unfortunate time when 16:9 monitors were forced on us and vertical space became precious. A time thankfully that is over.

Today I have one 3:2 and one portrait monitor so compacted titlebars are particularly poor design.

Thankfully KDE for the most part does not indulge in that, and let’s you fix window borders, but they have other failures such as hard coded button order in dialogs.


The reason they have to put all that crap in the title bar is because of all the other bad UI decisions that used up all the screen space.


There's a lot of mouse centric workflows, where you don't want to keep switching between mouse and keyboard all the time.


fwiw, when I'm on an OpenBSD desktop, I use cwm which doesn't supply titlebars, and I use Meta+click to move windows. That's great...On OpenBSD. But sometimes I'm using a Windows computer. Sometimes I'm using a Mac.

...And sometimes I'm using OpenBSD, so titlebar buttons introduce a titlebar I didn't want, and didn't need, which doesn't match the rest of my desktop customizations.

It's just a bad paradigm.


If they do it correctly there's plenty of free space in the titlebar for grabbing. That's how it works in GTK+3 and later for example.


But it causes cognitive overhead: you need to think about which bits of the title-cum-button bar are safe to grab, as opposed to which overloaded and do other things, which are possibly useful.

I use Firefox. I also use macOS a lot. Firefox assumes your tabs are horizontal. Mine are not (using a built in feature).

So it doesn't use the title bar much. So there's an option to turn it off. It's off by default. Result, the actual top bar is a cluttered toolbar and it's hard to move the Firefox window.


If there'a a visible title label, that's obviously safe for grabbing. Firefox is probably doing it wrong by not leaving some visible space for users to grab at things.


> Firefox is probably doing it wrong

Up to a point -- although Mozilla added vertical tabs about a year ago, it's pretty clear nobody uses them, same as nobody left at Microsoft is competent enough at customising a Windows desktop to know how to use vertical taskbars, so they removed that option from Win11.

But saying that, although I do not like GNOME, I review the new version every 6 months, so I do try it. I find the same problem with GNOME CSD apps.

It is not confined to the problem of moving windows. The GNOME developers are clearly obsessed with gestures -- even the welcome tour contains instructions on trackpad gestures, and my machines have the trackpads disabled. I use mice, because I prefer them.

With a mouse on Linux, the middle-button has 4 main functions:

1. Open web links in a new background tab.

2. Middle-click the title bar to push the window behind other windows.

3. Middle-click in text to insert the currently-selected text at the cursor.

4. Close browser tab.

I do these things hundreds of times a day. Literally, no hyperbole.

GNOME has removed functions #2 and #3.

From this it seems apparent to me that the GNOME developers do not really know how to use mice effectively, and mainly use laptops with trackpads.


> Titlebar buttons and other space-saving measures.

This has been net negative. Now everyone thinks it’s ok to shove every control up there and there’s nowhere to grab a window to move it that isn’t also a button. But the OS interprets button click and mouse drag as cancel the button click.

I wish people would stop doing this.

We HAVE HI DPI screens with large resolutions and even 640x480 had title bars!!!!!

What space could possibly need saving?


On a small macbook that I use for programming, every bit of my screen has been meticulously prepared by me to cram in a lot of functionality


> Forms that validate on focus lost, instead of submission.

Not always positive. The form briefly loses focus for two seconds (while you open your password manager or whatever) and you are shouted at to “PLEASE ENTER A VALID USERNAME” in red.


Sometimes I see it complaining _on every keypress_. Certainly annoying, but much better than the old "invalid field" red text at the very bottom, leaving you to scroll back up and guess what's wrong.


Incidentally, I’ve just come across this: https://www.threads.com/@miraklemax/post/DYRiyECFq2e


> - Tabs.

Tabs aren't really new: look at BeOS which could "tab" windows..

That said I agree with you that tab are really nice, especially the way VSCode manage them with the vertical list of opened files (I switched from vim to VSCode due to this feature).


> loading bars (replaced with throbbers)

There is a very practical reason for this; most GUI apps are webapps (whether local or not is irrelevant), and the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between).

As a result the loading indicator can only indicate in-progress or done.

There might have been worse ways to design the fetch API, but off-hand, I can't think of any - what came before it was immensely better for a user experience.


With a better API we could have a progress bar that goes through the TCP/IP stack: advance when the domain is resolved, when a handshake is finished, when the request is sent, when the response starts streaming back, when the response finishes.

It'd be a very jumpy bar, but it helps develop intuitions. "The first part is always slower on this machine", "when it gets stuck on this spot I need to reset my router", "this part will be slow because the request is large", etc.


Perhaps an aside, but the things we do to compensate for the warts of TCP are staggering.


This isn't a TCP problem, though. It's a fetch API problem.

Even if fetch ran over UDP, or a direct serial connection, or IP over Avian carrier, it'd still be a poor API that doesn't allow progress indication.


Most of the time you're fetching multiple things in parallel and you could show a progress of how many of those are done (perhaps weighted by estimated size). That's essentially the way many progress bars work.


> As a result the loading indicator can only indicate in-progress or done.

We used to have the cursor indicating this in the good old days.


As a result the loading indicator can only indicate in-progress or done.

This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer.

It is perfectly possible to get real progress information other than yes/no. Web sites had it for years before lazy spinners took over.


>> the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between).

>> As a result the loading indicator can only indicate in-progress or done.

> This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer.

No, it's a failure of fetch.


But we did gain some nice things!

None of the gains you list have anything to do with user interfaces. They would all or mostly be possible in any of the older desktop environments shown.


The screenshots in the post include many old applications, sometimes jarring to modern sensibilities. I think it's fair to have a discussion here about the evolution of application UI too, no?


I appreciate this balanced take! Let's hope one day we'll get the best of today's and yesterday's era.


There was a brief moment in history where we had the best of both worlds.

I grew up with Windows XP. We had most of these (except the titlebar buttons — although on second thought some custom Windows Media Player skins did have that, haha).

We all carried USB sticks around. So you always had your files with you. The computer itself was interchangeable, for the most part. (Which also led to my interest in portable apps.)


...and of course, Portable Apps require a relatively stable ABI...

https://blog.hiler.eu/win32-the-only-stable-abi/

>Win32 is the only stable ABI on Linux

Though macOS I think has a similar issue.


> - Tabs.

Should have been a generic window manager feature.


Apparently Cosmic will even let you combine different apps in the same tab group. I read that but haven't confirmed.

Web browsers had to innovate because OSes, DEs and GUI toolkits stagnated. Tabs and better sandboxing came from web the browser.


BeOS sort-of did that.


fluxbox have been doing that for over 20 years


> Ctrl+P menus to fuzzy-search all actions and settings

Wasn’t that in Emacs for decades?


Yes. The macOS menu bar is also searchable, which is cool. Unity on Ubuntu also had this back in the day.

Most people haven't experienced "addressable interfaces" like Emacs and don't know what they're missing when they only have visuospatial navigability. I would like to see searching and jumping make bigger impacts in mainstream UX design.


KDE's global menu also has a search function like macOS/Unity. Tho only on Wayland for some reason.


Well, I guess it really is time for me to switch to Wayland, whatever the downsides.


Probably! To quote William Gibson, "the future is already here — it's just not very evenly distributed". I'm sure you can find some of these features all the way back in The Mother of All Demos, the difference now is that they're more common.


I don't miss the loading bar. The progress in the bar never seems to correlate well with the actual time taken. It's not uncommon to have a progress bar breeze through the first half in seconds and spend minutes on the later half or vice versa. It's misleading to the point I recall "progress bar stuck on 99%" became a meme before people started calling them memes.

Just give me the option to view a log of what is happening under the hood. Tell me which step of the process you are at, what files are you copying etc.


"- Document editors remembering unsaved changes."

This can be really annoying when I don't want to save these changes


> The fact that a subscription designed to cancel itself

But it wasn't? TFA is describing a technical issue that kept cancelling a subscription. This is not a "we've noticed that you haven't been using the service and paused billing" situation.


> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.

It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.

That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.


Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: