Chipsfrish Peperoni definitely have more heat, they’re saying they’re using 10000 Scoville powder (though not how much of it). Generally speaking if you order something hot in Germany you’re getting Turkish hot, which is about “able to eat pure Sriracha without breathing fire” kind of tolerance level.

But, granted, Pringles is American, I should have guessed.

If I read this article right, and I think their picture shows their Pringles stacked same-side up as mine, mine have the flavouring on the other side.

Which side is up in the can was never a question for me, they simply fit my mouth, and presumably mouths in general, better if the long concave side cups the tongue. It could be that they’re simply seasoned on the wrong side over here it’s not like they import them from the US, they’re produced in Poland.

In any case the store brand has seasoning placement down, but as this is Germany you’re limited to paprika and sour cream and onion. Which I will be sticking with in the future.

xmonad doesn’t, though using xmobar is common.

Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.

And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.

So… who’s outbidding them? Someone from tankiejerk? Or are their being taken over by lemmygrad, to be introduced to Socialism with Dessaline characteristics?

Oh no it’s definitely a theoretical paper. Even if the theory is fully formalised and thus executable it still wouldn’t give much insight on how it’d perform in the real world because theorem provers aren’t the most performant programming languages.

And, FWIW, CS theorists don’t really care about running programs same as theoretical physicists don’t care much about banging rocks together, in both cases making things work in the real world is up to engineers.

Security aside if there’s no central management you can have multiple apps listening for the same keybinding, I wouldn’t call that “simpler to work with”. It may be easy in the short term, but the dark side of the force always is.

Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored

There were ten years that the desktop environment people wasted, where all those interfaces could have been created but they only started in earnest once the x.org devs put their foot down and said “nope we’re serious x.org is unmaintainable we’re not doing this any more”.

And no, X didn’t solve any of those problems – what it did was provide completely unrestricted access to everything to anyone and it took multiple decades before different clients would stop fighting each other over control over the desktop. That clusterfuck was one of the things that x.org devs wanted to avoid, but they, not being DE devs, also didn’t know what DE people actually needed. So they asked. And, as said, didn’t get an answer.

Dual GPUs are no issue for x.org it’s just that automatic configuration assumes a somewhat standard machine or it gets confused. Should I tell you about the days before automatic configuration, of hand-editing XF86Config to tell the X server that no, I didn’t have a serial or ps/2 mouse but an USB one, and it had three buttons and a mouse wheel? Of seeing a list of monitor timings with the comment “CHOOSING THE WRONG THING MIGHT DESTROY YOUR HARDWARE”?

xrandr is actually quite recent (or I may be ancient), being able to do all that stuff at runtime was a godsend.

In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.

You’re aware you just called the x.org developers Elon, do you?

x.org is just as much a freedesktop project as wayland is or dbus. Or, before they spun off, flatpak. Wayland grew out of the x.org devs deciding that the thing has become literally unmaintainable. The recent pain is caused by downstream devs (including kde, gnome etc) noticing quite late that the x.org people were actually being serious, if they had provided input earlier then the gazillion of protocol extensions that people are whining about now (such as global hotkeys) could’ve been finalised literally ten years ago.

x.org still gets a couple of patches – for xwayland. At some point they’re going to rip out the whole graphics driver stack and replace it with a wayland compositor, that compositor plus xwayland will be the X server. You’re free to build a PC with a good ole S3 Trio but don’t expect future x.org releases to support it.

18/f/cali

Have a look here. Not sure how they do it the proper way would be to run the desktop environment as a subcompositor of autokey.

Meanwhile, though, do try CLI automation. It’s the Unix way.

There’s no X WMs that fake input devices, or organise global hotkeys, or a thousand other things people always quote when bashing wayland. You can get bog-standard X applications which do that because X has literally no security model, but the feature set between e.g. KDE on X and KDE on wayland is virtually identical.

Depends things like shaped window borders for theming, title bars

All possible. X had some age-old protocol enabling oval and whatnot windows and noone ever used it, whether you use CSD or SSD you can paint with alpha and say “nope, that mouse click wasn’t for me”. So even if logically all windows are rectangular because that makes sense because textures are rectangular and you really don’t want to complicate things at that level, UX-wise you can have fractal borders if you really want.

in hyprland,

…anything “in hyperland” is a hyperland problem, not a wayland problem.

effects, pagers, some automation options, etc…

All Things compositors can do.

What I generally miss in Wayland is better mouse automation support,

Faking input devices is compositor responsibility, for obvious security reasons.

Java support,

As if Java and X work well together.

the ability to have multiple mouse cursors and assign them to different input devices.

Weston does this, protocols support it, I don’t think it’s much of a priority for other compositors. The most common multiple pointing device configuration is to have both devices control one pointer. My tablet works and the tip is properly analogue that’s plenty of functionality for me (dunno if tilt works by now, blender doesn’t use it anyways).

Java’s UI libraries are notorious for shoddy window handling, it also was a nightmare on X.

org.freedesktop.portal.GlobalShortcuts allows apps to request a global shortcut binding from the compositor. They can’t just log all your keystrokes globally because that’d be a keylogger. Also there’d be no way to resolve conflicts between shortcuts.

If your app doesn’t support that then blame the app, the interface has been out for a while, and compositors have supported it for a while.

And yet all that pales in comparison to using react (or whatever framework) over vanilla js. Enter McMaster-Carr.

Using bencode over json would probably speed up the web more. Not to mention good ole ASN.1 (well, at least some binary schemes for ASN.1). The web is completely cooked when it comes to efficiency.

I blame Bavaria. If Germany had multiple price zones like other European countries instead of one giant one prices would plummet here in the north, while they’d explode in Bavaria. The state that does not want wind power, does want nuclear power, but already knows ahead of time that its geology (with lots of mountains and granite) is unsuitable for nuclear waste storage. Meanwhile, north German wind power and Scandinavian hydro dams complement each other perfectly. The Bavarians could do the same with the Austrians, they just don’t. They want to eat cake and have it, too.

After reading through the abstract the article is pop sci bunk: They developed a method to save additional space with constant-time overhead.

Which is certainly novel and nice and all kinds of things but it’s just a tool in the toolbox, making things more optimal in theory says little about things being faster in practice because the theoretical cost models never match what real-world machines are actually doing. In algorithm classes we learn to analyse sorting algorithms by number of comparisons, and indeed the minimum necessary is O(n log n), in the real world, it’s numbers of cache invalidation that matters: CPUs can compare numbers basically instantly, getting the stuff you want to compare from memory to the CPU is where time is spent. It can very well be faster to make more comparisons if it means you get fewer, or more regular (so that the CPU can predict and pre-fetch), data transfers.

Consulting my crystal ball, I see this trickling down into at least the minds of people who develop the usual KV stores, database engineers, etc, maybe it’ll help maybe it won’t those things are already incredibly optimized. Never trust a data structure optimisation you didn’t benchmark. Never trust any optimisation you didn’t benchmark, actually. Do your benchmarks, you’re not smarter than reality. In case it does help, it’s going to trickle down into standard implementations of data structures languages ship with.

EDIT: I was looking an this paper, not this. It’s actually disproving a conjecture of Yao, who has a Turing prize, certainly a nice feather to have in your cap. It’s also way more into the theoretical weeds than I’m comfortable with. This may have applications, or this may go along the lines of the Karatsuba algorithm: Faster only if your data is astronomically large, for (most) real-world applications the constant overhead out-weighs the asymptotic speedup.