Yeah, but I doubt that would change much; the amount of damage done would be difficult to roll back. What do you think Apple is going to do for the next macOS: "Look we told you to design all these extra icons last year. Guess what, this year we want you to remove them."
I just can't imagine that happening. This is the fundamental thing that is wrong with this. They had the OSes in beta for a few months, barely listened to feedback, and now we're stuck with the damage. For how many more OS iterations?
I really wish they had at least macOS in a different cycle than iOS (and with the idiotic year version names, they've brazenly signed themselves up for the yearly schedules.) I really couldn't care less about what damage they do to iOS after iOS 7, but I still haven't upgraded to Tahoe and I won't do so until they roll this design back entirely...which I don't see happening.
Maybe I'm just pessimistic about Apple at this point but I feel like no amount of criticism is going to change their design trajectory now, unless it affects their bottom-line.
they'll slowly walk the changes back until the aesthetic is usable
in 8 years or so we'll probably get the next major overhaul
we're not stuck with the damage, except for the icons and such. the rest can be changed no problem. they could remove liquid glass tomorrow and make everything look like visionOS and the icons would still fit just fine
but they can't roll back to the previous design. which is a shame, because they poured in probably millions of man-hours to make it great. and the soulless app icons we now have won't ever match the 3d ish big sur icons that were filled to the brim with personality.
hell, there even were entire webpages and social media accts dedicated just to macOS icons. i regularly saw icon showcases on twitter with thousands of likes. not anymore :(
I hope with change in leadership correction of these things will be possible again. Not just Alan Dye, but Tim Cook is rumored to leave in the next year too.
I like sourcehut. It's the only forge out there that isn't set out to copy the Github UI like everyone else. And its UI itself feels instantaneous, as if it was running locally.
sourcehut is a product that feels like it was just built for me and what I care about, I absolutely love the design. But it's tough to use for a team that isn't building open source software. Your teammates will probably be perplexed by the UI because it's so different. The tooling for sending and receiving patches is quite poor, there is no decent GUI email client with patch support. There's also no organization support or ability to apply principle of least access like with a codeowners file.
The UI is fast, but it can be difficult to navigate, at least if you aren't familiar with it. In particular, unless it is explicitly mentioned in the README, it isn't at all clear how to report a bug, or submit a patch, or view relevant mailing list archives.
> In particular, unless it is explicitly mentioned in the README, it isn't at all clear how to report a bug, or submit a patch, or view relevant mailing list archives.
Those are meant to be mentioned in the README. Each of sourcehut's parts including the repo frontend, project page, mailing list, task list, documentation pages, etc are independent. There is no predefined way in which these are associated with each other like on GitHub. For example, I use a single mailing list for all of my FOSS projects.
I use bog-standard zsh without any plugins or any of the fancy stuff, but one of the most useful tricks I use is to leverage interactive comments. If I have a long command I know I run will frequently, I 'tag' them at the end by a shell comment[1].
So for example, I have one that I use to run software updates:
I have a similar one without the `--restart` option that I tag with `:norestart` instead, but you get the idea—I put related commands under a common term.
Then I can just use the ctrl-r builtin keybinding, type `:system` and cycle through system related commands, or go exactly to the command I want. The beauty of this is that it also works in bash and systems I remote into (which I frequently need to do at work), without any extra plugins required.
[1]: interactive comments are disabled by default in zsh, but can be enabled with `setopt interactive_comments`
Interesting approach. Im so lazy I would just create a alias with the commands initials so "sur" but I guess that can get confusing if there are too many.
For sure. Personally, I avoid shortened aliases like that. I regularly need to use barebones systems so I wouldn't like something like "ll" (`ls -l`) or "gst" (`git status`) becoming muscle memory. Most of my aliases I do define are proper english words.
> A particular thing I don’t like about git forge websites is the way they make you create an account.
Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone.
I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they do, I just don't get the motivation to email them.
People like to complain about email a lot, but I enjoy different mailing lists for open source software. You could have discussions with other users of that software or keep track of development by following the "-devel" list. All you needed is something you already had—email. Sadly, they're becoming less popular. Even python moved to discourse which—dun dun dun—requires an account. grumble grumble
I like SourceHut for many reasons—it's the fastest forge I've used, it's FOSS, doesn't try to copy the GitHub UI like every other Git forge these days. But by far the reason I love it is _because_ it doesn't require me creating an account to contribute. I think of it as gitweb, but nicer.
Security/privacy yeah. I don't do business with Twitter/Facebook for the same reason. In the case of GitHub, if I want to contribute something, I am going to do it volitionally, knowing they will do whatever they want with it.
Creating an account just locks you in, when the alternative exists or existed before. SourceHut proves this is possible. Why not allow non-accounts to contribute?
OK, that's a really solid reason. Thank you! For me, it suggests that someone like you might not mind creating an account on a system I run (because I allow anonymous account creation without anything at all although providing an email is encouraged).
Bad comparison. People who are critical of others' complaints about creating and/or logging in to a GitHub account like this aren't going through the trouble of creating a GitHub account in 2025 (as opposed to, say, 2015) and are clearly logging in once and staying logged in.
I encourage you to try an experiment where you pick three or four (or more) times a day to log out of your HN account and only log back in the next time you need to perform some action that requires an account/authorization. Now do the same with GitHub and compare the experience. They've made merely logging in such a massive pain in the ass that somehow goes beyond the anticipated pain around "here's a forced 2FA workflow you didn't ask for but have to run through, anyway". All so you can be generous with your time to someone else's benefit and e.g. leave a signpost comment with answers to a shared problem in some neglected bugtracker, but it's real a kicker when this is interrupting a semi-flow state.
> Now do the same with GitHub and compare the experience. They've made merely logging in such a massive pain in the ass that somehow goes beyond the anticipated pain around "here's a forced 2FA workflow you didn't ask for but have to run through, anyway".
I don't agree, in my opinion it's easier than logging into HN because Github has passwordless auth with passkeys.
I don't even have to enter a username, I just click "Sign in with a passkey" and use my passkey and then I'm logged in, no "forced 2FA workflow"
Those passkeys that you and GitHub are talking about require a separate authenticator to use.
> no "forced 2FA workflow"
What does "2FA" stand for?
> it's easier than logging into HN
You have your thumb on the scale (which seems to happen every time someone criticizes GitHub). You have already indicated a willingness/desire to use an authenticator. At that point, there is literally nothing stopping the authenticator from providing the exact same user experience, where instead of releasing your "passkey", it provides your password to HN's login form. And oh wait that's exactly how scores of password managers work, including the ones that are built in to every mainstream browser. (If you're somehow using one that for whatever reason doesn't do that, then it's self-inflicted, which is exactly opposite to the case of the forced 2FA flow that GitHub imposes.)
This is without even mentioning that you have to set all this up.
> It's not, though. The passkey itself is strictly a single factor.
The passkey alone is not sufficient to log in. You must also provide a successful response to the WebAuthn challenge from an authenticator that has been registered/configured with that passkey.
> That's kinda the point, to reduce user toil.
It's almost as if letting people elect to enter their secure, never-written-down-anywhere-else passphrase would accomplish that.
Great. Now go ahead and try to argue the indefensible position that relying on an authenticator to supply a passkey is somehow not a form of two-factor auth.
> I'm not using anything other than my browser.
... as your authenticator. The fact that you're using your browser and its built-in support for this as your authenticator but are using the term "browser" when you're talking about it instead of the word "authenticator" (GitHub's term—here's their documentation about authenticators, which I'm sure you could have Googled: <https://docs.github.com/en/authentication/authenticating-wit...>) doesn't change its role.
> (which doesn't take longer than 15-20s)
Aside from the fact that the ~5 seconds that it takes to create an HN account is not even the same as the 15–20 second estimate that you're offering here, there's the minor problem that that estimate is bogus.
You are simply not being honest in your reckoning of the respective costs. Here's GitHub's own documentation for the process of adding a passkey to your account:
> as I stated it's my opinion, having a different opinion doesn't make me dishonest
Stating your opinion doesn't make you dishonest, but arguing about things that are matters of fact and not opinions—measurable, quantitative things—and doing it with bad quantities chosen in a dishonest way is, in fact, dishonest.
Here's the Wikipedia article about intellectual dishonesty:
It's a good point, I suppose, but it doesn't have to be so black-and-white. There are certain exceptions to this no-account rule of course, like for your bank.
Now, would HN be better without an account? I believe it would, why not? I like lurking (and sometimes commenting) on HN though so I feel like creating an account is valid. Also, HN works fine without JS and has no trackers, which does tend to get me to create an account.
Last week, I started to explore `pass`[1], to move away from my current Authy + iCloud Keychain ecosystems. It's pretty barebones but that's what I like about it. I like it so much that one week later, I've fully migrated away and couldn't be happier.
And the news about the Authy leak yesterday validated my move, if anything.
I don't really care for ente; it's more complicated than what I need from a password manager. And the fact that pass is so much more customizable (being as it's only 700 or so lines of shell script), I don't feel like I need anything more _personally_.
Just clone beneath /opt/pass and configure with the standard environmental variables, or use the default password-store location, and you're good to go. I use this to ensure all my systems have access to the same passwords (which are stored in a private git repository).
Absolutely devastated at the news. Bram was really patient with me based on the few times I tried to contribute. I always liked his way of doing things, despite complaints from others.
I know there are a number of developers who regularly contribute and I hope they can continue developing for it.
Personally, I will archive Bram's last patch for posterity.
Text objects are cool, but `ca)` would remove the parenthesis too. There's no shorter way to get to `my_func(foo);` when your cursor is at the comma, than using the motion OP indicated.
gandi.net seems to charge $364/year for any .is domain. Namecheap charges around the same price as isnic.
Any reason why I shouldn't register the domain on isnic directly? Are there benefits to registering the domain via namecheap (or other registrar), apart from getting access to their support?
A big thing to consider with registrars is support for 2FA - can't speak to ISNIC, but I recently moved all my domains to Namecheap because they have first-class support for U2F/Webauthn. (And also Hover lost a domain on me but that's another story)
Process was pretty straightforward and I was able to add my DNS records just fine. Do you know if they have any safeguards against domain transfers? I don't see any settings related to that, other than to transfer my domain.
Very early on in my vim journey, I used to use fugitive[1], which is sort of a lighter equivalent of magit for vim. However, I found that too overkill and unwieldy. I never really found any benefits to forcing myself to stay inside vim to run some git command.
These days, I just use git in a tmux split rather than trying to force vim to show some arbitrary git UI. For a nice interactive git UI, I use tig[1]. Tig is essentially like fugitive/magic insofar as it allows me to interactively view a nice graphical log, stage/commit, traverse a file's historical blame, etc. It's a nicer UI compared to something like `gitk`.
I have these mappings in my `~/.vim/vimrc` for git/tig functionalities:
I've been using `!tig` forever. For some reason it was convenient enough for me to never turn it into a mapping. I feel like `tig` damaged me in the sense that using tig and then pressing `S` is my usual workflow, so I just can't get used to either fugitive or magit.
Fugitive is really useful for a lot of stuff, though I don't use anywhere near all of its functionality. For example, I never rebase within vim. But blaming and especially staging/committing is a far better experience with fugitive than in plain terminal.
There is interactive blaming, staging and committing with tig too, so give that a try.
That said though, I actually prefer using the shell to stage and commit stuff. I think I'm way faster when I'm on the shell performing those actions than in either tig or fugitive.
Tig looks great but fugitive is in my fingers (been using it for something like 7 or 8 years at this point). I'll still check it out.
Not sure when the last time you used fugitive but there was a major overhaul a couple of years ago. You can expand diffs in the commit window and stage parts of the files.
But obviously, stick with what you're comfortable with!
I'm not sure what I did wrong but your mapping didn't work for me on Neovim - it either immediately closed the terminal or didn't know what <bar> means.
All the mapping worked fine for me as well in vim, and I found gB to be super useful, earlier I had to go first in tree view and then select the file and then use the blame view.
Yeah, but I doubt that would change much; the amount of damage done would be difficult to roll back. What do you think Apple is going to do for the next macOS: "Look we told you to design all these extra icons last year. Guess what, this year we want you to remove them."
I just can't imagine that happening. This is the fundamental thing that is wrong with this. They had the OSes in beta for a few months, barely listened to feedback, and now we're stuck with the damage. For how many more OS iterations?
I really wish they had at least macOS in a different cycle than iOS (and with the idiotic year version names, they've brazenly signed themselves up for the yearly schedules.) I really couldn't care less about what damage they do to iOS after iOS 7, but I still haven't upgraded to Tahoe and I won't do so until they roll this design back entirely...which I don't see happening.
Maybe I'm just pessimistic about Apple at this point but I feel like no amount of criticism is going to change their design trajectory now, unless it affects their bottom-line.
reply