Is this a decision took in light of the new prime minister’s party winning 2/3 lower house majority and her statements about protecting Taiwan against China?

How is that a solution? These attacks would just tell you to install terminal if you don't already have it.

That would help a little no?

Well it's becoming developer hostile enough already. Maybe drop python and all command line tools while they're at it.

Would do wonders for that mythical year of the linux desktop...

I don't think the social media landscape is inherently bad, but the ways in which it evolved. And I think the shift in social media towards consuming content instead of connecting with others is a direct reflection of the era we live in; one of abundant information.

Social media will stop becoming relevant when we stop treating each person as a mini corporation that needs to provide value, trying to optimize every aspect of your life in a life-long marketing campaign.

You may be onto something. It is a little bit like google when it first started showing ads. Initially, the ads were clearly marked and were promised to be relevant to the user, but that line has been moved slowly in a way to extract more and more value from the user.. while removing value that user already had.

I know social media had some real use cases. CL and FB marketplace are probably one good example of that. But the rest of it.. best I can say, my overall happiness jumped up after first month of going on a media diet.

You might want to add [2022] in the title

Crap, you're right. But I can't edit anymore. Also that would exceed the character limit.

I went to Kyoto last year during what can be considered peak season. My accommodation was quiet central. I have to say I didn't have a problem with overturism. Sure if you visit what everyone markets on Instagram there are flocks of tourists everywhere. If you just randomly explore the city, you can find equally beautiful places that lack tourists and in my opinion are far more charming.

I think the problem is that since Japan has been trending on social media, everyone goes to the same 3 temples, eats at the same 5 restaurants and so on. And social media sure doesn't help in spreading the tourist flux evenly.

On my Intel mac searching with cmd+space for a file takes under a second. Maybe there is a problem on your end?

I’ve actually had worse problems as recently as last week: Apps stopped showing up completely in spotlight.

Only a system reinstall + manually deleting all index files fixed it. Meanwhile it was eating 20-30GB of disk space. There are tons of reports of this in the apple forums.

Even then, it feels a lot slower in MacOS 26 than it did before, and you often get the rug-pull effect of your results changing a millisecond before you press the enter key. I would pay good money to go back to Snow Leopard.

I had the same problem last year, re-indexing all the files fixed it for me[1].

That being said, macOS was definitely more snappy back on Catalina, which was the first version I had so I can't vouch for Snow Leopard. Each update after Catalina felt gradually worse and from what i heard Tahoe feels like the last nail in the coffin.

I hope the UX team will deliver a more polished, expressive and minimal design next time.

[1] - https://support.apple.com/en-us/102321

Catalina and Mojave were the closest releases in terms of quality that we got to Snow Leopard. Catalina in particular since it was the release that removed more 32-bit cruft (like Snow Leopard before it).

Absolutely there's a problem on my end, but how do I fix it! How did it get to that state in the first place? How do I make it not come back?

From your article it seems like you benchmark compile times. I am not an expert on the subject, but I don't see the point in comparing ARM compilation times with Intel. There are probably different tricks involved in compilation and the instructions set are not the same.

I've often been suspicious of this too, having noticed that building one of my projects on Apple Silicon is way quicker than I'd expect relative to x64, given relative test suite run times and relative PassMark numbers.

I don't know how to set up a proper cross compile setup on Apple Silicon, so I tried compiling the same code on 2 macOS systems and 1 Linux system, running the corresponding test suite, and getting some numbers. It's not exactly conclusive, and if I was doing this properly properly then I'd try a bit harder to make everything match up, but it does indeed look like using clang to build x64 code is more expensive - for whatever reason - than using it to build ARM code.

Systems, including clang version and single-core PassMark:

    M4 Max Mac Studio, clang-1700.6.3.2 (PassMark: 5000)
    x64 i7-5557U Macbook Pro, clang-1500.1.0.2.5 (PassMark: 2290)
    x64 AMD 2990WX Linux desktop, clang-20 (PassMark: 2431)

Single thread build times (in seconds). Code is a bunch of C++, plus some FOSS dependencies that are C, everything built with optimisation enabled:

    Mac Studio: 365
    x64 Macbook Pro: 1705
    x64 Linux: 1422

(Linux time excludes build times for some of the FOSS dependencies, which on Linux come prebuilt via the package manager.)

Single thread test suite times (in seconds), an approximate indication of relative single thread performance:

    Mac Studio: 120
    x64 Macbook Pro: 350
    x64 Linux: 309

Build time/test time makes it look like ARM clang is an outlier:

    Mac Studio: 3.04
    x64 Macbook Pro: 4.87
    x64 Linux: 4.60

(The Linux value is flattered here, as it excludes dependency build times, as above. The C dependencies don't add much when building in parallel, but, looking at the above numbers, I wonder if they'd add up to enough when built in series to make the x64 figures the same.)

After tweaking the build process to build the same dependencies from source on Linux as on macOS:

    x64 Linux build: 1514
    x64 Linux test: 307
    x64 Linux build/test: 4.93

(Again, not a perfect test, as it still won't be exactly the same code, but the numbers are nevertheless pretty close!)

Most of my targets aren’t machine code. Typescript emits JavaScript and C# emits IL. I didn’t check the exact output, but these are hardware independent and should be more or less the same.

I once read here on HN that a good metric for filtering controversial comment sections is number of upvotes/comments. If it's bellow one, the thread is probably controversial.

Are you saying controversial is good or bad?

Neither, that's up to your individual preference. Although I think that controversial threads have more noise, but sometimes provide a more enjoyable read.

So what use is it to filter them? It seems you still have to judge their worth based on their actual contents.

The front page has an algorithm that is "less noise, more news" but if you go to the /active page, you get more conversation-driven submissions. I tend to load both up and refresh every few hours.

> The FAQ notes that submission rank is impacted by "software which downweights overheated discussions." A good rule of thumb for this effect is when the number of comments on a submission exceeds its score. Moderators can overrule the downranking for appropriate, not-actually-a-flame-war discussions.

https://github.com/minimaxir/hacker-news-undocumented

Consider there are 100 upvotes and 100 downvotes. Net votes: 0. The submission would end up with a lower ranking that you wanted it to have.

Submissions don’t have downvotes, only flagging.

Fair. But it still holds for the comments section.

In common parlance, this would be called "ratioing".

I feel like, for me, it’s that I am more familiar with writing in C and switching to C++ seems rather difficult. So, sure I am reimplementing features that already exist in anoter language, it just so happens in this case is C++. Why not use python if you want to avoid reimplementing the wheel as much as possible. And sure python is not suited for game development but I just wanted to make a point with it. I think in the end ising a language you are most familiar with results in the most amount of enjoyable coding.

For a solo dev, it's not difficult. C++ is nearly a superset of C. You don't have to adopt all of C++ to start using it and to get immediate benefits from it (for example, unique_ptr, shared_ptr, and vector would all be things that I think any C dev would really appreciate).

A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ultimately forcing the whole team to become an expert in C++ simply because they all will be familiar with a different set of C++ features.

But for a solo dev? No reason not to use it, IMO. It's got a much nicer standard library with a rich set of datastructures that just make it easier to write correct code even if you keep a C style for everything.

I learnt C++ on Turbo C++ 1.0 for MS-DOS as teenager, after doing C with Turbo C 2.0.

Being on Borland ecosystem that was followed by several years of Object Pascal (I was already using TP at the time), and C++.

Never got the point of why to keep using C, other than external constraints like school assignments, jobs requirements or lack of compilers.

I've been using macOS since 2020, but for the last year I have seriously considered switching to Linux. macOS Catalina felt really fast, easy to use, and lacked the useless features they kept adding and the ipadOS like interface they began implementing. In 2020, the feature set felt much more intentional.