mort96

You can't turn the animation off, you can change it to be a fade animation instead of a slide animation. As you say, it takes the same time regardless.

I just want them to make the animation faster. It makes Spaces completely useless to me that it takes what feels like 2 seconds to shift focus to a window on the new space when I swipe on my trackpad. Worse, it takes longer the higher refresh rate your monitor is; it's not too bad on 60Hz screens.

I tried using Mission Control with two monitors for the first time yesterday. Nothing fancy: a YouTube video in fullscreen (aka with its own Space) on the secondary screen, whatever else I was doing on the primary (built-in laptop) screen.

It was such a broken mess. Opening Mission Control and closing it again, interacting with it only on the primary screen, would often (but not always) result in the secondary screen forgetting what it was doing and going to a normal desktop space instead of the video space.

And I'm certain that windows are more prone to overlap now than they were before?

My favorite thing they broke is that there is no longer an animation when launching and dismissing Spotlight in its Launchpad mode (i.e 4 finger pinch on trackpad). I mean there is an animation, but it's only visible if I'm pinching slowly. If I do it at normal speed, there's just a half-second delay and then it pops in or out.

I suspect they made the animation so heavy that it reaches its deadline before it even starts, so it gets skipped.

Not sure if it's better or worse than Tahoe, where the animation (mostly) worked but app icons either popped in all at once a bit later or were rendered one by one from top-left to bottom-right.

It's such a buggy mess. When using my Mac these days I miss the polish of my Linux desktop.

No, it's not. Here's a comment where I described a concrete hypothetical scenario: https://news.ycombinator.com/item?id=49871032

The "update code to refer to B" step is a massive undertaking. My whole original comment was about that one step.

AKA it solves nothing, just kicks the problem down the road.

Huh? I already searched, I know what I'm looking for so why would I need it to figure out what to search

And if any tooling ever gets executed without the proper replace directive...

Until your tooling automatically makes a request to a now-untrusted server and trusts its response...

And leave URLs to abandoned infrastructure all over the place? No thank you.

What do you mean? Go's tooling definitely tries to fetch from that URL.

com.sun is an identifier, nothing more. No tooling sees com.sun and assumes, "oh that means I can make an HTTP request to the IP address which sun.com resolves to".

In Go, the package identifiers are literally URLs. Go's own tooling assumes that it can make an HTTP request to the URL and that the response will be HTML with particular tags which Go's tooling will parse and use to resolve a git repository which can be 'git clone'd. Leaving them as-is when you abandon the infrastructure they reference literally means leaving dead links in your source code.

Oh that's horrible. I've somehow never encountered it but damn.

How do you propose it's solved in an easier way, given the constraints that 1) you don't want references to old infrastructure in your code and 2) you want to do the move without changing how the code works? Is there some secret trick we missed which would've made this much easier?

It opened for me on iOS but with those constant requests to make me download the app.

I just tried on my laptop though, both Waterfox and Firefox. It's just completely unusable there, with a ton of CORS and CSP errors so no CSS loads and no JavaScript loads. Happens even when I disable all forms of tracking protection and ad blocking; I think their site is just broken in a way which presumably happens to work in Google Chrome.

Yeah the AI part of their post is stupid, but they're right; screenshots can be easily faked (through e.g inspect element), so if your social media feed is mostly screenshots from other social media, you're at a relatively high risk of seeing fake posts. On the other hand you can't fake the content of a post or repost or the quoted content of a quote post, so if your feed contains only non-screenshot content you can be relatively certain that the content you're seeing is genuine.

I've never had that problem on Mastodon, but I can see how it could be annoying if you follow a lot of people who mainly post screenshots of people's posts from other social media sites. Though you could solve that problem by unfollowing those people...

Sounds like a local government problem for y'all to solve, not a problem for the rest of the world to work around

I was allowed to read the original post without logging in, but it repeatedly showed me a dismissable pop-up asking me to download the app. Then when I tried to scroll down to read replies it showed me a non-dismissable pop-up asking me to download the app.

Holy shit social media is bad. I've been using Mastodon for so long I didn't realize how bad the others are.

Wow that Threads website is absolutely unusable on mobile

I do something like this in all my projects now. Except that I don't use example.com, I just use the name of the project. So if I'm working on a program called Frobnicator, I'll just have `module Frobnicator;` in my go.mod and do things like `import "Frobnicator/lib/blah"` in my source files. It works really well to be honest for non-library software.

But it's something you have to do as an active choice; the tooling, and your colleagues, will nudge you towards using URLs to your primary git host's web front-end. And it naturally doesn't work for libraries.

Well vendoring is a technical solution of the same caliber as adding module aliases to the go.mod. By that I mean, sure, it keeps the code compiling right now, but all your source files still contain references to abandoned infrastructure. It changes when you have to do the work, but unless you want your code to reference abandoned infrastructure forever, you still need to do the work.

Moving the repositories over was no problem at all! But once all the data is on the new hosts, all the Go source files still reference the old git host, since imports in Go are URLs to a git host.

Have libfoo with a bunch of different versions. Authservice depends on libfoo 1.2.0. APIservice depends on libfoo 1.3.0.

Now you want to move from github.com to git.example.org. You change libfoo, authservice and apiservice to use git.example.org, that part is just simple tedious work. But the v1.2.0 and v1.3.0 tags of libfoo are old commits from before the move, so they still reference github.com! Now you need to branch off of the v1.2.0 and v1.3.0 tags of libfoo and do the same change there.

So we have only 3 repositories with only 2 dependencies and we already have to do the search/replace 5 times.

Imagine now that apiservice depends on authservice v2.3.7 just to include some type definitions. Authservice is currently on version 2.4.0 but the types haven't changed so apiservice hasn't upgraded its dependency. Now you need to branch off of authservice v2.3.7 too and do the job there. Oh and authservice v2.3.7 depends on libfoo v1.2.5, so now you need to make a branch off of libfoo v1.2.5 with the search/replace.

3 repositories with a straightforward dependency relationship, 7 search/replace jobs.

The numbers get terrifying as you scale this up.

See: https://news.ycombinator.com/item?id=49870363

You're now arguing that it's easy, which is a completely different argument. The comment I responded to argued that it's unnecessary ("just do the rewrite in go.mod, leave source files unchanged").

For my thoughts about why it's not easy, see this comment: https://news.ycombinator.com/item?id=49870363

If it's thinking I want, I can do that myself. Chat bots are occasionally useful search tools, but thinking doesn't really help with that. So why pay?

And you'll just leave references to abandoned infrastructure in your code forever?

And now all your source files contain URLs to abandoned infrastructure. Is that what you'd want long term?

I've gone through such a migration. Huge Go code base distributed across a lot of git repositories had to be moved to a different git host.

It was horrible. A team of people spent weeks. Different projects depended on different versions of the same internal libraries, we had to create a branch for each depended-on commit and make a version of that commit with the new URLs. The expressed goal was to end up with a system that's "exactly the same" as the old, just on a new host. Changing which version of libraries projects depends on would introduce unnecessary risk.

And the result is a code base where bisects are broken and where it's impossible to build an old version of any of the code without a ton of work.