TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.
The meta problem with all this desktop UX design discussion is that it's not actually very problem driven.
Many of us solve our UI problems and we land into our own happy minima.
Many of the UX "solutions" are either invented problems or not my problems or worse, grinding some anti-me agenda.
Like many, a lot of my UX improvements have been to simplify the UI. Tiling, with just a few windows per virtual desktop in herbstluftwm: kitty, emacs, browser and some rare transient application (usually PDF or image viewer).
The idea in the screen shot horrifies me. Why would I buy an expensive high pixel monitor just to use only 10% of it to display a single window? Why would I want to waste CPU to animate the migration of a full window to a single button icon (another example given)?
These UI "innovations" are great for movie props but do they actually help in reality? Not that I see. The "stagnation" of UI to me is more a plateau. Anything truly new must be driven by new "I", no input/output channels between user and computer.
The one interesting idea I saw in the article was Lifestreams. I think storage and recall is something that needs improvement and new ideas because for me that is a problem. I produce and consume too much info while recalling it is hard and while also I often do not produce or consume info that I wish I had.
I don’t find the ideas proposed in the talk (and this article based on it) terribly offensive, but that’s not because of anybody being more right or wrong.
Desktop UX I think is a much more deeply personal and subjective thing than many care to admit. A setup that’s one user’s nirvana can be another’s anathema (case in point: the tiling setups beloved by many in the tech sphere drive me crazy).
While some underlying principles track between different solutions, I don’t think it’s possible to build a desktop that works well for everybody. We all have different mental models, ways of thinking, ways of working, and formative experiences with technology and that all goes into what we find most ergonomic and comfortable. It’s very similar to how radically people’s physical workspaces can differ from each other.
So the best thing to do I think is to ensure that a wide variety of meaningfully different desktops are available so as many users can find one that’s a reasonably close match to their style. Trying to pose a single desktop as “most correct” and shoehorning all users into it is a recipe for failure. Maybe the futuristic concept desktop is the right choice for someone even if most would prefer something more traditional.
>Many of the UX "solutions" are either invented problems or not my problems or worse, grinding some anti-me agenda.
>These UI "innovations" are great for movie props but do they actually help in reality? Not that I see.
Scott Jenson specifically mentioned in this talk that he doesn't view open source devs as programmers who couldn't care less about needs of non-power users, but this is exactly that sort of a tone deaf response, and a really narrow perspective.
Most actually novel things in Linux desktops since the ~late 2000s target the extreme power users. They have near-zero discoverability, terrible defaults, building substantial skills and constant practice and maintenance are required to use it for rather routine operations, etc. I mean I also used to configure my WM by programming it in Lua (because it expected the users to know it and I do), I also use emacs for quarter a century, I use Nix to set up my entire desktop, but I'm not saying everything else is useless and carries "anti-me agenda".
Your animation example is really telling, most users are like "where did my window go??" without it, I'm talking from the first-hand experience of watching young people trying to use a computer. The CPU argument is simply inane and 100% irrelevant for the modern hardware, I'd understand if it was distracting for you (and me too), but wasting CPU is a silly hill to die on. Power user interfaces that make simple things hard is the primary reason most young people outside of a really narrow group are not tech-savvy and look at desktops as obsolete ancient tech.
There are arguments that it's impossible to target both power users and any others, but these are all simply wrong. Both target groups are totally compatible, you can look at Microsoft's ribbon or superbar as an example of such an interface. In the worst case you introduce a simple binary setting if you don't want the cues, don't tell me it offends you somehow please.
(That said, it's funny to hear SJ mentioning his work on Finder, because that's probably the worst non-power-user file manager in existence.)
I don't care about animations wasting CPU time. Any modern CPU has plenty of cycles to spare for animations. I care about wasting my own time. If I minimize a window, it should minimize immediately. I don't want to wait for some useless animation to play first.
That animation in particular (window minimization) is 200-300ms long in most DEs, and is located on the slow/discoverable UI path that is tolerable to such delays. If you want faster speeds, you likely use the keyboard and your muscle memory and aren't likely to find yourself in a scenario where you want to minimize or maximize a window at all, since you're using the hot/low latency path through the UI (e.g. Alt-TAB or a myriad other ways). If you use a pointer, it's a rather negligible delay compared to moving it, and of course you can make it faster in the settings. UI design is about thinking such details through and measuring them, not adding useless animations to annoy power users.
Anyway, it's not the point. You're always free to disable animations if you think they're making you slow. I think too many people in the discussions about UIs are confusing quirks of particular interfaces with first principles, and are extrapolating specific experiences to the whole field.
>it's a rather negligible delay compared to moving it
That's an irrelevant comparison. If you booked a long flight, would you accept somebody pointlessly delaying it for an hour just because that's short compared to the duration? The correct amount of avoidable latency is zero, regardless of how much unavoidable latency there is.
It's also false; I have a good mouse, good mouse skills, and my taskbar sits against the edge of the screen giving it effectively infinite height (see Fitt's law). I can hit taskbar targets in around 300ms.
You're assuming this is a sequential workflow, which it isn't. Animation is already done by the time you hit a target. I also am fast with the mouse, I used to play and design competitive FPSes for a living, that's precisely why without measurement and considering actual scenarios I have a really hard time believing that this specific thing actually slows anything down for real use cases and isn't just your personal preference/imagination. I disable it too but it's just my preference, as I find it distracting and breaking the focus.
I click the taskbar to minimize/restore the windows, so the animation starts only after I click them. And it's still sequential even if I use the title bar icons, because I have to wait for the animation to finish before I can use the space where the window once was.
> You're always free to disable animations if you think they're making you slow.
Sadly less and less true nowadays. I always try to turn off any animations. On Android the settings is not respected, not even by Google owns app. On KDE itseld, it respects it pretty well, but applications don't always do, and not consistently. Firefox has its own animation settind on Android, linux, and windows (never tried on mac), and firefox doesn't even respect it in some case when scrolling even though i turned off everything.
I hate animations. I want everything instant, my time is precious, my ability to suffer shit moving all over the place is limited.
I have animations minimized (whatever the setting is called) on my iphone, and there is still a maddening delay when doing many actions. Either the app has hard-coded some amount of time between presses or the program is so inept that it really takes fractions of a second to do basic activities.
> (That said, it funny to hear SJ mentioning his work on Finder, because that's probably the worst non-power-user file manager in existence.)
I’ve seen similar sentiments echoed many times but I’ve never really understood them. After enabling the status and path bars and setting window search default to the current directory, I don’t find the Finder any worse than the typical Linux file manager and in some ways prefer it to Windows Explorer.
Yeah the social media giants cribbed Lifestreams sort of with the timeline but without the search capabilities that were a cornerstone of the paper. You can see glimpses of this metaphor elsewhere with email, rss and news readers but it would be interesting to make that the centralized metaphor of an entire system for all the system's data.
The basic idea of Lifestreams is good for its metaphor but a lot of important implementation problems are ignored: ballooning storage from "clone" operations for every edit, ever increasing "view" query time, lack of a provenance back pointer. I think a lot of this can be solved with an SQL store, git style content hashes but there are still leaks to plug. One big one is how to resolve hashes given the content stores can move or disappear? Here I am assuming the system does not attempt to intern and reinvent git, github, dropbox, Maildir, etc? Then there is the huge footprint of how to collect inputs. Plugins for browser, email, git, perhaps even file system. It's all rather daunting to contemplate yet also feels like such a workable system is just within reach.
What is the interplay between such delegation and token cache timeout? If Fable is truly active for 4 days, enough to keep the cache hot, the cost would be astronomical. OTOH, if Fable idles while subagents are active, then each awakening is a cache miss.
True, that’s why I didn’t have a single Fable thread running for the whole time. Each phase had its own orchestrator that ran about 4-5h, in Fable or Opus depending on complexity, delegating to sub agents along the way - they had tasks broken down in a granular enough way that each returned in anything from 5 to 30 mins approx, then the lead agent did some validating and status updates before delegating the next step. So the main agent’s cache never went cold. Each phase raised its own PR and had an opportunity for human validation/code review before the next phase kicked off in a new context.
> the maximum achievable throughput is 26 bps at 1.5 m and goes down to 22 bps at 4.5 m.
And when there are more than one transmitters in real world conditions instead of anechoic chamber?
It's cool and all and if this work is for it's own sake, for the sake of research, no issues. But otherwise, I struggle to think of practical use cases. I grant that my imagination may be deficient.
I think someone from OpenAI said something like "air gapping AI can't (hypothetically) work because it will figure out a way to basically morse code across the airgap". (I think this was in response to people calling them out for not airgapping)
> "air gapping AI can't (hypothetically) work because it will figure out a way to basically morse code across the airgap"
All things well-known for good two decades and written about by x-risk/LessWrong crowd, but to date continued to be dismissed as lunacy.
On one hand it's great to see it demonstrated in practice in concrete terms, on the other hand it's sad we have to basically make the mistakes ourselves, with live and close-to-dangerous systems, because we can't believe the obvious warnings.
I didn't mean they first invented or described the methods, but that they've been consistently presenting a solid argument that these and other methods make airgapping and sandboxing AGI a dangerously flawed idea from the start. They are the serious people who considered this, and to date nobody listens.
Less wrong gives off a give of wanker doomsday cult in general. Like they just enjoy being scared or something, but are not actually serious about anything. Like the true crime YouTube series enjoyers. That's purely vibes based of course
There needs to be something on the other side to receive that morse code. Unless it's like Metamorphosis of Prime Intellect and it figures out how to rearrange matter just by modulating some electronic signal.
If you think this is a realistic possibility, you might be experiencing AI psychosis.
Do you have thoughts on the prospects for inter-operation between the "recoll" application and hister? Like, maybe an adapter that let's hister read recoll's xapian database/index? Or, a tool that converts/syncs beween hister's store and recoll's?
They also define and measure an "IPJ" as well as "IPW"
> the NVIDIA B200 achieves 1.6× to 2.3× higher intelligence per joule
than the APPLE M4 MAX across QWEN 3 and GPT-OSS model variants
The B200 = "cloud", M4 = "local".
So "cloud" does even better in energy than it does in power compared to "local". Or, to flip it, "local" is both slower and more expensive than "cloud".
> Unless I misread it, are they saying local GPUs use less energy?
You misread it. From the abstract:
> local accelerators achieve at least 1.4× lower IPW than cloud accelerators running identical models
That's "intelligence per watt". They also have IPJ, per Joule.
So, they find local is 40% "dumber" than cloud for the same power or 40% more power for the same "intelligence".
Tables 13 and 14 summarize their IPW and IPJ metrics.
But, to your actual point, I think the "local is 40% dumber per watt than cloud" message is still an understatement. And maybe this is something I failed to find in the paper but they seem to ignore the "idle baseline" costs and talks about explicitly focusing on the power consumption of just the accelerator under load.
There is a large baseline power consumption just to support the accelerator. CPUs, memory, PS losses, network, fans, general environment cooling. This "cost floor" is different for data centers and a "random local computer" and I think must be in favor of data centers which are designed and built with efficiency in mind.
Idleness should also be considered. My local GPUs at $WORK and home are idle more than they are used. Idle time energy in real world scenarios should be somehow attributed to those brief, punctuated times when LLM functions are actually active on the accelerator. Actual, local LLM usage of a GPU is brief (assuming one user per PC). Even with my heavy usage developing s/w I'd guess I heat up a GPU about one hour per day total, sometimes much less. If that is local then one must pay 23 hours of idleness for that 1 hour of "intelligence". Of course a local PC is used for other things and the idleness penalty must somehow account for that. OTOH, data centers try to maximize utilization so their idle time penalty would be much less, perhaps close to zero, by construction.
> Of course a local PC is used for other things and the idleness penalty must somehow account for that.
I'd argue the idleness penalty only applies if you wouldn't have otherwise had equivalent hardware. If you already have the exact same dGPU for gaming and it doubles up for inference then the only inefficiency is power consumption (both by the GPU and potentially by AC for your living space).
Conversely I think we should consider that privacy, distributed compute that you can access without an intermediary, and a more distributed power grid all provide net benefits to society at large.
reply