I run regular Arch with Niri and Noctalia Shell, which is based on Quick Shell. It is a pretty solid experience. But even with Quick Shell, which has taken a lot of the pain out of closing the gap between traditional DEs and these tiling WMs, it’s still a decent chunk of configuration.

Without it, I’d be doing a ton more configuration with a bar and scripts to display some information. And then those would be hardly functional, since really they’re just showing some stdout from the terminal. If I wanted to actually, say, connect to a new Bluetooth device, I’d still be heading to the terminal to connect.

That gap is what makes Omarchy interesting to me, and presumably to the people who seem to really like it.

Omarchy lets someone install it just like another “real” distribution and get a working OS without having to do hours of configuration and ensuring they have all the additional utilities they’d expect to have.

I think it does kind of have to be a “distro” because the appeal is that you don’t maintain the scripts yourself. You can just install it and get sensible defaults from a fresh install.

There’s nothing stopping Ubuntu, Fedora, or another major distribution from creating something like this. They already have Plasma and GNOME variants that include bundled software and sensible defaults customized from the delivered version of those DEs.

My question for people is whether their objection has to do with Omarchy itself or with the person or people behind it. I get that even without a controversial figure behind it, people might still object to some of the technical decisions behind it. But I find it hard to argue against the idea. It is filling a niche by making alternative WMs like Hyprland more accessible.

both because as I said there's no distinction with a project like this, and I'll give you a technical example for this. The manual which I briefly read through says this on the monitor configuration:

"Omarchy assumes you're running on a 2x-capable retina-class display by default[...] It's what you'd want to run on a 27" 5K Apple Studio Display [...] But if you're not running a display with a PPI of 218 or above, you'll want to change the monitor settings ..."

then it proceeds to tell you what config files to edit by hand. Monitors with that PPI have a market share of <2%. This isn't a system for people who want things out of the box, it's his personal dotfiles that people use because they know his name. It's like buying Jordan sneakers and thinking they'll make you great at basketball, it's an influencer product. How many people, given that the appeal is to not read anything, have consulted that part of the manual? If this was a nobody's repo it'd have 10 stars and people would ask why the fonts look like crap.

If you want stuff working out of the box for non-technical people give them an Ubuntu LTS release, not window managers on release version 0.x. maintained by people in a discord

"Technical people" covers a vast variety of people. I can and have configured many different non-mainstream WMs and implemented different bars, and found workarounds to different issues that arise from them, both in wayland and X11. A person can be just as technical as I am and still have no interest nor desire to set that all up, but still want to explore or use the paradigm shift that something like a tiling or scrolling WM offer.

The problem is that these paradigms people find appealing aren't decoupled. You can't just drop it in to your current desktop because the window management is so tightly coupled to the compositor. You can try things like PaperWM, of course, but you don't really get to experience Niri unless you install it, and then figure out how to handle everything else you need in a way that you'd want.

If Omarchy used GNOME or Plasma, there's zero chance it'd have taken off in the same way it has. Yes, it is definitely a case of its virality being tied to an influencer, but it isn't ultimately why someone would stick with it. It gets rid of a lot of the gatekeeping that exists. Anyone that can install a linux distro can install Omarchy and get a fully functional system. That is something we need more of, not less.

If you're only talking about desktop displays, then I 100% agree that almost no one has them because until very recently, hardly any have existed because the only people who cared about it are people using MacOS. But given the increased number of 5k monitors with high refresh and gaming features shown off at CES and expected to hit the market this year, on top of a smattering of productivity-oriented displays with high PPI coming out in the past year, this could likely change.

I'd say it's something that benefits Windows and Linux because fractional scaling still isn't perfect on either OS. But Windows, frankly, does scaling for desktop in a much more pragmatic and (for most people) better way than MacOS, so having to set your 4k 27 inch monitor to 150% scaling isn't a big deal. Things still look relatively sharp. On MacOS, not so much.

Almost no-one is running Linux in a MacBook or iMac though.

Even Omarchy itself only supports Intel Macs: https://learn.omacom.io/2/the-omarchy-manual/97/mac-support. So the point is moot.

It's neither a novelty nor a Mac-only feature these days. A huge portion of the pc laptop market has high PPI displays and it's becoming increasingly rare to see anything that'd comfortably display at 1x scaling.

I have one of those, this kinda of screen is uncomfortable at 2x scale (everything gets too big), so I generally set up to 1.25x or 1.5x. This is not what is being set by default by Omarchy though.

> A huge portion of the pc laptop market has high PPI displays and it's becoming increasingly rare to see anything that'd comfortably display at 1x scaling.

That is true, but you're moving the goal posts. This thread was talking about the 2x scale set by Omarchy by default, that is really only good if you have 200+ DPI.

This is still the minority of users even nowadays, and definitely not "98% of the user base" of the distro.

It's better that everything be a bit too big that requires tinkering than everything being way too small (where you can't read the text on the screen). The 2x scale is pretty usable for even 150PPI.

As I mentioned in another post, hyprland does support using the preferred scaling based on the EDID information which is probably the right choice, but I can't really verify that myself.

I think it depends. 2x in my 14' 1080p laptop makes text and UI elements so huge that I can barely interact with the screen, so it is unusable either way.

It's arbitrary. They're all linux distributions delivering distinct OS experiences. The only reason we call one a 'flavor' or 'spin' is because Red Hat and Ubuntu wanted to maintain a core identity with its product line.

It's not a distro because you could overwrite everything by downloading someone else's dotfiles in a few minutes. It's purely just a set of configs.

The difference is there is an implicit contract. Omarchy is maintained as a complete system. You can install it from an ISO, update it like a distribution, and expect someone to care about whether the pieces work together. hyprland is a minimal compositor and you have to figure out how to put together the other pieces of a shell to get a complete experience. If you're doing that piecemeal, you have to maintain and update those on your own. Changes to each piece that break something has to be addressed individually. With Omarchy, that is maintained by someone else and the downstream user just runs an update to omarchy. It compiles a group of disparate packages and makes something cohesive enough to not require jumping into configuration files to use.

That is different from downloading someone’s dotfiles. A dotfiles repo is usually written for one person’s machine and workflow. Omarchy may have started from DHH's dots, but it is structured as something other people are meant to install, update, override, and live in. It separates Omarchy’s defaults from user overrides [1].

I'm not sure what exactly is required for something to be considered a 'distro' but omarchy definitely feels more like one than not, albeit a relatively thin distro based on Arch.

[1] https://learn.omacom.io/2/the-omarchy-manual/65/dotfiles

If it's really just primarily dotfiles, those 'install scripts' are just going to be a few cp and maybe tar commands.

> Omarchy is maintained as a complete system. You can install it from an ISO, update it like a distribution, and expect someone to care about whether the pieces work together.

Not entirely though, because they defer so much control and judgement to the actual distro they are layering over.

I guess it's semantics. I guess if you consider Kubuntu a different distro from Ubuntu then so too would Omarchy be a distinct Distro.

Why do you think that? I do regular ol' coding at my day job and have been vibe coding some side projects. They both require using my brain and both require my input for something to be created. They are different, though.

> Instead all you're doing is creating more cheap mediocre throwaway crap just because you can.

It probably is these things but since I'm just building stuff for myself, it hardly matters.

I've written a lot of code and a lot of that has been doing roughly the same thing. It's not a mental challenge; it's a chore. Sometimes it is really gratifying to code and try to figure stuff out. Often times it is not. So when it comes to building something in my free time, I'd prefer to avoid that sort of mental friction and banal tasks just to start working on the actual problem. More so than that, I'm building tools for myself to make my life easier so I can spend it more on something else.

I ride an electric bike with pedal assist. Does that mean I'm not really bicycling? Some might say yes and that it defeats the point. To me it ensures that I pick the bicycle more because it reduces friction to do so. I know that if I encounter a hill that the pedal assist will help me up it and thus I use it more and the net benefit outweighs the downsides. I think it's the same thing here.

I don't take pride in the work that an LLM does for me but I will happily benefit from it. It's a tool.

And just like with bikes, people who take pride in doing things the hard way can continue to do so. And they shouldn't belittle people who choose to use assistance.

It leaves more room for skill expression when you're making architectural decisions, defining scope, and designing the application.

This one in particular seems quite bad for it. Removing the tire and the folding mechanism designed to make it stable and stationary doesn't bode well for that use case. It really does seem to be designed only to be folded once you're done riding for the day and not intended for transporting it folded except for loading it into a trunk.

They are definitely prioritizing the ride quality over the foldability, compactness, or transportability. Bromptons try to balance it, which for me is a much better package, but for others, probably making too many compromises to ensure that it can meet those requirements.

I do find my brompton a lot more convenient for the train, though.

For me, the spatial mapping of windows comes naturally, though. For MacOS, I have 9 spaces. This can be as many or as little as you want, but for me, I have keybindings to switch between them, starting with ctrl + shift and then I map it to:

  u i o
  j k l
  m , . 

With that being said, things I'm frequently using (browser, terminal, mail, music, discord, etc) have their own global keys set to launch or switch to them and that is actually what I use most. I think if you can think about how you'd like to organize your system, just practicing that will help you reason about it that way.

I've been trying Niri on my thinkpad and I really like it, though I think I agree that it can be trickier to spatially map where things are in it. Its spaces are vertical and then you are scrolling the horizontal plane. They aren't always the same dimensions because it depends on how many windows are open. Getting back to say, the top right space, requires more work, at least out of the box. But on a smallish laptop screen I think it is well thought out way to make it easier to swap between different views.

In a vacuum I think the interpretation Verhoeven had is mostly fine. It only becomes apparently ignorant if you’ve read more of Heinlein’s work, where libertarian themes are pervasive.

The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.

Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.

If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.

Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.

With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.

Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.

If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.

I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).

This feels like a reasonable counter-measure.

SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.

We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.

And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.

One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all.

The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.

For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables.

There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.

I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.

And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.

Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And thus a thousand hacks were invented because it’s cheaper than doing things properly.

Then along comes Electron, React Native and so on and so forth. And our hacks continue to proliferate, memory usage be damned.

No, otherwise they would not need all those hacks. Web stack makes it cheap (fast and easy) to build an MVP, but since the very primitives required to fully implement requirements are not even there, they end up implementing tons of ugly hacks held by duck tape. All because they thought they could iterate fast and cheap.

It's the same story with teams picking any highly dynamic language for an MVP and then implementing half-baked typing on top of it when the project gets out of MVP stage. Otherwise the bug reproduction rate outpaces fixing rate.

I prefer the capabilities of native frameworks but I prefer the web box model.

Sizing stuff is native frameworks is nice until it isn’t.

But I will admit I’ve focused more on desktop than mobile app development. And the thing about sizing stuff is it’s a much easier problem for desktop than mobile apps, which are full screen and you have a multitude of screen sizes and orientations.

Any other way? Just build a web app with emscripten. You can do anything.

For a while GTK had an HTML5 backend so you could build whole GUI apps for web, but I think it got dropped because nobody used it.

This is the whole concept of the SPA - make a page behave like multiple pages. The premise itself requires breaking absolutely everything assuming that content is static.

> There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal.

Um... I'm old enough to remember the initial release of node, where the value proposition was that since you cannot trust client data anyway and have to implement thorough checking both client and server side, why not implement that once.

> I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way.

Let me introduce you to our lord and savior native app

If you don't let web developers manage history/state like this, we'd be going back to the inefficient world of, "every forward/back movement loads a whole page." (With lots of unnecessary round trip messages between the client and server while the user waits for everything to load).

Basically, the ability to manage history is a user-centric feature. It makes the experience better for them.

Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.

Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.

Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.

The Back and Forward buttons on a web browser is the navigation for the web. If you click a link on a static html page it will create a new entry. If you click back, it'll take you back. If you press forward, You will navigate forward.

We should not be creating a secondary set of controls that does the same thing. This is bad UX, bad design, and bad for an accessible web.

> Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.

It does close the app it's showing because we have tabs. If you close a tab, it'll close the app that it's showing. If you close the browser, which is made up of many tabs, it closes all of the tabs. Before tabs, if you closed a window, the web page you were on would close as well. It does what is reasonably expected.

If on your web application you have a 'link' to another 'page' where it shows a change in the view, then you'd expect you would be able to press back to go back to what you were just looking at. SPAs that DON'T do that are the ones that are doing a disservice to the user and reasonable navigation expectations.

> Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.

They should not have to be 'educated' here. The mental model of using the back and forward buttons to navigate within a webpage is totally fine.

Can you unpack this please? AFAIK history stack is not preserved in the URL, therefore it cannot be preserved in a bookmark or a shared link.

https://developer.mozilla.org/en-US/docs/Web/API/History/pus...

> The new history entry's URL. Note that the browser won't attempt to load this URL after a call to pushState(), but it may attempt to load the URL later, for instance, after the user restarts the browser.

This can be as simple as having a single checkbox with a checked/unchecked state.

when you load the webpage, the javascript can pull in the url parameters with URLSearchParams (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchPa...). If the url parameter you set is set to 'on' then the checkbox, which is by default unchecked, can be set to on.

You have your checkbox:

    <input type="checkbox" id="check">

    const check = document.getElementById('check');
  
    // get state of checkbox from URL parameter
    check.checked = new URLSearchParams(location.search).get('state') === 'on';
    
    // add event listener to call history api to alter the URL state.
    check.onchange = () => { history.replaceState(null, '', check.checked ? '?state=on' : '?state=off'); };

If I used history.pushState(), each time I clicked on the checkbox, a new item would be added to the stack. for a checkbox this is almost certainly a bad idea because your browser history is going to be polluted pretty quickly if you happen to click it multiple times.

pushState can be useful when it matches the user expectations, though, like if it is an SPA and the user clicks on an internal link to another section of the site, they'd expect to be able to go back to the previous page, even though we're still on the same actual html page.

So you would not be preserving the entire history stack. You can sort of do this by encoding state changes into another url parameter, but the behavior isn't entirely consistent between browsers. It also does require, as far as I know, an explicit action from the user for it to actually affect their navigation. So a website couldn't just add 1000 entries to the user's history on load without some explicit interaction on the web page.

Once the user interacts, though, it does seem like it opens up a lot of opportunity to abuse it, intentionally or not. You can asynchronously push thousands of entries into the browser history without blocking interactivity of the site. you can even continue to push state to the URL from other inputs while doing so.

When you enter a code block, that assumption changes. You are now in a “long text” mode where the assumptions are shifted where you are more likely want to insert a new line than to send the message.

I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context. Pressing tab in a table or spreadsheet will navigate cells instead of inserting a tab character. Pressing arrow keys may navigate cells instead of characters in the cell. Pressing enter will navigate to the cell below, not the first column of the next row. It’s optimized for its primary use case.

I think if the mode change was more explicit it’d maybe be a better experience. Right now it is largely guessing what behavior someone wants based off the context of their message but if that mismatches the users expectations it’s always going to feel clumsy. A toggle or indicator with a keyboard shortcut. Can stick the advanced options inside the settings somewhere if a power user wants to tinker.

I don't have a spreadsheet software nearby, but I remember the cell is highlighted different if you're in insert mode or navigation mode. Just like the status line in Vim let's you know which mode you're in.