They may be alienating the core audience that made them who they are, but I don't think they're disconnected from their customer base, which has changed. RTSes are not popular and they are not platform-agnostic like an FPS is.

I think safari is largely fine but there are a lot of web APIs that it doesn’t support, rightly or not. A lot of devices are configurable through serial connections using the Web Serial APO thats only available in chromium browsers.

As a primary browser it really comes down to ergonomics. Things on top of the engine that make someone prefer one browser over the other.

https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes

Most people make compromises inside imperfect systems. The person casting judgment almost certainly has their own moral compromises too, except those they understand, contextualize, rationalize, and forgive themselves for.

It’s just tiresome. There may not be a ton of context, but even knowing that someone is bound to a particular place because of caregiving responsibilities should be enough to invite a little more empathy and grace, and a lot less judgment.

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.

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.

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.

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.

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

"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.

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.

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.

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 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.

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:

    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.