If you read this and think it doesn't apply in corporate technology jobs, either you're already doing so well at it that you take it for granted, or you are so unaware of the relationship dynamics going on around you that you don't even know what opportunities you've missed.
Even dealing with point of sale and customer support issues becomes a lot easier when they know you're a few taps on your phone away from reversing a transaction. Make it clear that it's something you're very comfortable with, routine even, not a bother at all, and almost like you're doing them a favor by handling it on your end. They won't see it that way, of course, but it gives you all the leverage in the negotiation without it getting ugly.
Try it next time someone says their point of sale policy only lets them offer you store credit or an exchange. Say, oh that's fine, my credit card lets me reverse the transaction if I couldn't resolve the matter with the store, so I'll just do that. The very next response will be a miraculous change in the store's policy.
I see it the same way I see surround/spatial audio and HDR on an OLED. Most people won't get much out of it, but those that do notice will tend to prefer the option when available, even at substantial cost.
I think that's a little different. With spatial audio or OLED, it's a one time up front cost to get the better hardware, but turning on an OLED iPad or TV is no different than turning on an LCD. By contrast, Vision Pro requires extra work every single time it's used. I'm much more willing to pay a little extra or do a one time setup than I am to do extra work every time I want to do something.
Going for a walk in a nice park is a better experience than walking around the block, but if I only ever walked after going through the trouble of driving to a nice park, I'd almost never walk. That's more like VR to me. Even if the cost is removed from the equation, it creates enough friction that using it becomes an event, not an everyday default, even if it's preferred.
The study has... let's just say "other methodological problems". But they did do an RCT of parachute use! (The open peer review correspondence is quite fun, too).
Fun fact: part of why TOML 1.1 has taken so long to land is because of open questions around unicode key normalization. That in itself sounds dry and boring, but the discussion threads are anything but.
I inherited a project where a dozen different entity kinds were all given UUIDv4s. Users mostly see namespaced strings, but actually searching by those strings is janky and unreliable for other reasons (including the fact that they can change), so whenever I'm asked to debug something I insist on reducing to UUIDs first so at least we're definitely looking at the same entities.
I didn't like the UUIDs at first, but it ended up being an unexpected boon for generic code to use the same key type for different entity kinds. What was less of a boon was that the string identifiers also have to be unique, but can change at any time, and depend on three-level namespacing (yes really) so there's far more that has to be tracked and enforced. The names are very important for UI use cases, but can never be the way that records reference other records, because that would just make them much harder to change with confidence.
The essay seems to assume you'll have either unique natural keys or unique synthetic keys, but having now worked on a project that does both at the same time for many entities, I think it's a third option worthy of its own analysis. My experience was negative but I can't deny that the end result ticks a lot of functional boxes.
> In a context world, you would use io.Writer/Reader or net.Conn to write small bits of data and check whether the context is cancelled in between 1KB writes (or whatever size).
That can still block pretty much indefinitely. Imagine you're a client reading from a server, but the server isn't in any hurry to send anything, and keepalives are keeping the TCP connection open, and no network blips occur for months, so your goroutine is blocked on that read for months.
The much simpler and more robust thing is to propagate context cancellation to socket close. The close will abort any blocked reads or writes.
e.g.
go func() {
<-ctx.Done()
_ = conn.Close()
}()
You'll still observe and return an error in the read/write call, and close is idempotent, so this doesn't take anything away from your existing logic and really just acts as a way to propagate cancellation.
I don't know how well this works for other types of closeable reader/writer implementations. It may not even be thread-safe for some of them. But this worked great when I tried it for sockets.
> I typically just defer a function in the goroutine that either writes to an "IsDead" channel or sets a mutex-protected boolean
I try to just use `errgroup` whenever possible, even if no error can be returned. It's just the most fool-proof way I've found to make sure you return only when all nested goroutines are returned, and if you're consistent about it then this applies recursively too. It's a way to fake "structured concurrency" with quite readable code and very few downsides.
Valve chose KDE for SteamOS, including as the desktop mode on the Steam Deck, a device sold to be so user-friendly that it can compete with home consoles including the Nintendo Switch. (Not saying that desktop mode itself is as foolproof as a console interface, just that it can't be a total usability disaster for people who bought a Steam Deck for gaming and not as a Linux desktop)
Emphasis on chose KDE, not forked KDE. I agree with people who say that KDE has gone to great lengths to be customizable enough that you can mostly set it up the way you want without forks, extensions, or even registry editors.
I can't speak to how difficult Valve found it to work with KDE, but it says a lot that they still chose it overall. It's not often we get such a clear positive signal from a company that invests so heavily in user experience.
> If you don't like GNOME's design then just don't use it,
I don't, but for many years GNOME has been in a position where it can't use this excuse any more.
GNOME is most people's first experience of a Linux desktop. These days, more people than ever are giving Linux a try, for various reasons not relevant to this discussion. Most of those people will use GNOME first because it's the default for many distros, and often recommended for its simplicity even when people do have a choice.
Now GNOME could take the feedback from users that give it, and start to earn the position it takes in the ecosystem. Instead GNOME has been infamous for many years of actively dismissing user issues. If you have an issue with GNOME and you search for it online, not only are you likely to find it's a known and often long-standing issue, you're likely to find it being either closed or ignored so you know there's no point even trying to file it again.
An experienced Linux desktop user might just shrug and move on to something else. A first-time Linux desktop user can be forgiven for thinking that if this is the experience they have with the most famously user-friendly DE, then the Linux desktop as a whole just isn't for them.
GNOME's attitude towards user issue reports is hurting the Linux desktop as a whole, especially early in the adoption pipeline where the leverage of damage is greatest.
> The developers are already aware of what bugs are present and what features are missing.
Of course the developers are aware what bugs are present, users have been filing them for years, they just don't get resolved. In some cases features already existed and were actively removed with no adequate workaround; and no, extensions as they currently exist are NOT an adequate workaround. I'm not saying it's easy to fix, I'm saying when the state of extensions is so infamously poor and even GNOME developers can often admit that, GNOME developers cannot then turn around and use extensions as an excuse to actively remove working features or dismiss requests for features now standard to every modern DE.
Most people commenting are software developers too, we understand the pain of having to maintain a large project that has years of tech debt. Developers have every reason to be eager to purge old code and reluctant to add new code. But when user experience is on the line, especially in the one DE that most often forms a new user's first Linux experience, you have to actually listen to user feedback and make some tough calls that favor users. At the very least you can't blame the users for reporting the experience the users had, especially when GNOME has already made sure that filing issues constructively is a waste of time so venting on HN is all that's left.
In this HN thread you've told people to stop complaining or use something else or volunteer their own time to help GNOME fix its own mess. How many of those things would you say to a brand new Linux user who tried GNOME in earnest and filed a well-meaning bug trying to participate in the community constructively without being a developer? Never mind, from this thread and many GNOME issues and forum threads online, I already know exactly how the GNOME project and its advocates treat such reports and such users.
>GNOME is most people's first experience of a Linux desktop.
Perhaps that's proof that it isn't as bad as the vocal minority says it is? And if it was really that bad, wouldn't that be the distros' fault for continuing to ship something they know is bad? I don't think you can spin this in any way that makes it GNOME's fault, they didn't force any distros to make it the default.
>If you have an issue with GNOME and you search for it online, not only are you likely to find it's a known and often long-standing issue, you're likely to find it being either closed or ignored so you know there's no point even trying to file it again.
At that point the correct course of action is to fix it yourself or fork it. This is the same as any other open source project. I've had plenty of other open projects close or ignore my issues too, welcome to the club. I don't understand how you can be a developer yourself and still hold GNOME to this unrealistically high standard.
>GNOME developers cannot then turn around and use extensions as an excuse to actively remove working features or dismiss requests for features now standard to every modern DE.
Yes they can? It's their project, they can remove features or dismiss requests for any reason they feel like. You can also do the same in your projects.
>But when user experience is on the line, you have to actually listen to user feedback and make some tough calls that favor users.
No you don't? How many posts have we seen on HN about startups cancelling projects or shutting down because of management or money problems? Nobody likes to make those decisions, it makes the users very angry, but companies have to make them all the time because they have no choice. I know people like to fantasize about open source being different but it really isn't different. If the company employing the maintainers can't figure out how to profit from a feature then it most likely will get ignored or removed after a while. The Linux desktop is also notorious for being a pit of money that nobody can figure out how to profit from hence why a lot of user feedback is just noise. Look at Ubuntu Unity, that was beloved by its users and still it got abandoned because it wasn't profitable. I always found it weird that GNOME has this reputation for making radical changes when I find them to be quite conservative in some areas and reluctant to make changes that would result in the project totally dying off like that.
>At the very least you can't blame the users for reporting the experience the users had, especially when GNOME has already made sure that filing issues constructively is a waste of time so venting on HN is all that's left.
No, this is wrong. I'll say it again, you have the options to fix it yourself or fork the project. Venting is not the only option left and in fact venting is a completely useless option. I've seen so much venting about this on internet forums over the years, it's all the same comments about the same issues and none of it has changed anything in meaningful ways. The bugs that actually do get fixed were because somebody put in the work with the other maintainers and got it done, at no point were they ever helped by somebody ranting at them about how GNOME is bad.
>How many of those things would you say to a brand new Linux user who tried GNOME in earnest and filed a well-meaning bug trying to participate in the community constructively without being a developer?
I wouldn't, I only say these things on HN because the audience here is hackers. All the time I tell new Linux users to use Cinnamon or KDE because those are a bit more familiar to Windows users.
It's actually extremely disappointing to see developers on this forum repeating the same conspiratorial comments and unrealistic demands that you see elsewhere. Just so you know, at one time I made many of the same comments as you. I hated GNOME and refused to use it. Complainers have been saying the same things for decades now every time a new version of GNOME comes out. I was one of them. But still GNOME has lots of users that actually like it and swear by it. So what's going on here? Maybe it could be that the developers who hear feedback from a large sample of representative users on a daily basis might have a different perspective than everyone else? Maybe consider that your view is biased by only reading bugs that you noticed aren't fixed over long periods and are therefore difficult or unrewarding to fix? I know my view certainly was biased when I said those things.
