least · HackerTrans

17 日前議論

People don’t particularly care for platitudes from anonymous people on the internet. Even less so when they reduce a complex dilemma in your life to a binary choice between an “easy and amoral” option and a “difficult but righteous” one.

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.

least

先月議論

The United States experiences the same sort of issues, just with different sports.

least

2 か月前議論

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

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.

least

2 か月前議論

They don't need to. A lot of PC laptops feature high PPI displays. If you're using a moderately modern laptop, it's probably a high PPI display. A 14 inch laptop with a 1080p display is already at close to 160PPI. That's an option on a T480, a laptop from 2018. A P14S has an option for a 14 inch, 2880x1800 display, or 240+ PPI! The Dell Pro 14 has both an option for 1080p (~160PPI) and 2560x1600 (~215PPI). A 16 inch display with the same 2560x1600 resolution is close to 190PPI. Intel Macbooks Pro have had retina displays since 2012.

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.

least

2 か月前議論

If they have a mac laptop or iMac they have a >200 PPI monitor. If you have a higher end PC laptop, a lot of them go well past that.

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.

least

2 か月前議論

What makes one a distro and one a spin, flavor, or other made up branding by one of the larger linux vendors?

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.

least

2 か月前議論

It would still require install scripts to get from a fresh Arch install to Omarchy. And then those scripts would also be adding scripts that aren't really necessary for any single person's dotfiles but that’s not really the point.

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

least

2 か月前議論

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

least

2 か月前議論

No Linux distribution offers a good out-of-the-box experience with anything outside of XFCE, GNOME, or KDE Plasma. On the other end, these alternative WMs lack all of the shell features that people expect from a desktop experience.

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.

least

3 か月前議論

> What is coding for the sake of coding? I don't think anyone does that. Its about solving puzzles, using your brain, learning by doing, creating things- none of that happens when you use llm coding tools.

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.

least

3 か月前議論

I think there's a difference in using claude code at work to resolve issues or user stories which are patching existing software and already define what is trying to be solved and what the acceptance criteria is versus using claude code to build something from scratch, where you are acting as an architect.

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

least

3 か月前議論

When I was looking I found many full-sized folding bikes but they are solving a problem for an overlapping but different niche. They make it possible to fold and load it into a vehicle or make it more compact for storing at home, but they aren't very good at multi-modal commuting nor are they particularly compact. I remember someone with a folding Tern that struggled to carry it onto the train - it really isn't well suited for that.

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.

least

3 か月前議論

DC does not ban normal bikes. I see them all the time on the metro. I'd say it is becoming less common as they build out more bike parking infrastructure at stations, but it is definitely something people still do.

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

least

3 か月前議論

on MacOS I used to use Yabai but moved away from it to using a hammerspoon setup to manipulate window positions. This was mostly because bsp just doesn't scale well with larger displays, in my opinion.

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

So in this array, top left is 'u', bottom right is '.' Then you are arbitrarily assigning that area for a certain kind of task or work. so maybe for communications (Teams, Discord, iMessage, etc.) may be designated as being in the 'j' space, or west. My primary work space where I web browsing or coding might be the 'k' area. My email could be 'u' and calendar 'i'. If you've ever worked with two windows side by side, then you already reasoning about it spatially. On the left is my terminal. On the right is my web browser. This just extends that concept slightly. I use 9 spaces in a square shape because it just translates to an extra large desktop.

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.

least

3 か月前議論

The book does contain fascist themes and Heinlein was not advocating for traditional libertarianism in it. I read it more as exploring the boundaries of liberty and what would constitute a “free” society. The society was, for most, effectively free, just that a normal person didn’t have the right to full citizenship without serving. It was a utopia for the average person - only those that served really saw the absolute horrors of war and were the only ones able to vote and hold office. Would you rather live in a society where your quality of life was genuinely excellent but you weren’t entitled to vote or one where your quality of life is markedly worse but you are allowed to steer the direction of your own governance? It’s a theme explored in many utopian stories, usually with the conclusion that freedom trumps ignorant bliss.

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.

least

3 か月前議論

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

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.

least

3 か月前議論

Sure. I'm not speaking about preserving the full history stack in the URL, just storing state. Apologies in advance if my explanation for what I mean is something you already understand.

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

And then you have your javascript:

    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'); };

The history.replaceState() replaces the URL in your history with the one including the URL parameter, so if a user were to bookmark it, it would store that and reload it when they revisit the webpage.

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.

least

3 か月前議論

https://html.spec.whatwg.org/multipage/nav-history-apis.html...

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.

least

3 か月前議論

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page.

This feels like a reasonable counter-measure.

least

3 か月前議論

It’s kind of modal editing. Your 99% is enter to send because it’s a chat program. You’re sending mostly quick messages where adding a chorded input to send is just adding extra work to that mode.

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.

コメント