There are many different configurations of vps available with different numbers of cores, if you are picking the vps configuration specifically to have more cores than some transcoding software uses by default to avoid configuring a thread limit for that software then you are still configuring things to the nth degree just at the objectively wrong level of abstraction.

And why would they need open pit excavation for FTTH in NYC? Are there not existing trenches and under-street ducting for cables already in most of the city? Surely there are going to be some tricky areas but how to the other utilities like phones and electric work on their cabling?

I moved to a new house in the Netherlands at the end of last summer. KPN the FTTH provider was there by chance the day I got the keys to put the fibre in the cable box by my front door, however there was something wrong on the other end and the fibre was dark. The fibre lines themselves are owned by a different company and KPN couldn't issue a work order on my behalf to the fibre managment company since I didn't have an active KPN subscription. The way you get an active subscription is for the tech to connect his diagnostic machine (or a self installing modem/ont) to validate the connection works. Catch 22, can't fix the fibre without an active subscription, can't activate the subscription without a working fibre.

In one of the ten or so phone calls trying to come to a sensible resolution, one of the support people suggested the only way to resolve this was for someone with an active KPN subscription moves to my street so they can issue the work order on their account instead (yea let me get right on that KPN) or to simply get a different ISP that is willing to issue the work order and then switch back to KPN.

I told them to forget my number and went with a hyper local ISP that literally has a cat 6 cable running under the cobblestones from my neighbours house. Unfortunately it's not a very stable connection and the 1gb is more like 30-300mb depending on presumably the bandwidth usage of the neighbours.

And I think most linux users would pretty strongly disagree that it's easier to fix windows, a user hostile, closed source operating system with far fewer options for every single user facing aspect of the OS than linux. You have that completely backwards.

Is a quote from a sibiling comment to the one I replied to.

It seems that at the very least an extraordinarily loud minority of americans believe that arming the general population should somehow result in fewer gun deaths. On the big social media platforms, the larger news networks, and right here on HN, I am always surprised that such an obviously incorrect idea can be so pervasive.

> All available evidence indicates we should be spending much less time and energy focusing on guns and far more focusing on the failures and motivations of our government.

No, it doesn't. You can't just assert that because it's what you think. Societal issues do play a part, but just as you need oxygen and fuel for a fire, removing either one stops the flames. So if changing the individual minds and morals of seemingly half your country seems easier than enacting legislation restricting access to guns... well I don't think you should hold your breath.

It's absurd that anyone could pretend to believe that more people having guns is a "deterrent" mild or otherwise to lethal use of force? In every interview about why american cops shoot and kill orders of magnitude more people than most civilized countries, americans always argue it's because their citizenry is armed so the police need to be prepared to make life or death decisions in a split second at every moment on the job.

    json = '{"user":"nugget"}' // from somewhere

    let user = allocate_string(6 characters)
    for i in range(0, 6)
      user[i] = json["user"][i]
    // user is now the string "nugget"

    {"user":"nugget"}
             ^     ]end

So if you use user after calling free(json), You have written a classic _memory safety_ bug called a "use after free" or UAF. Search around a bit for the insane number of use after free bugs there have been in popular software and the havoc they have wreaked.

In rust, when you create a variable referencing the memory of another (user pointing into json) it keeps track of that (as a "borrow", so that's what the borrow checker does if you have read about that) and won't compile if json is freed while you still have access to user. That's the main memory safety issue involved with zero-copy deserialization techniques.

The point is that microsoft got _nothing_ regardless if you were using or not using clippy. So clippy being bad could only be because they sucked at making something good for their users. It was not because they chose maliciously to make the user experience bad for an ulterior motive like collecting and selling user data or pumping up telemetry numbers for a promotion. They genuinely thought clippy would be a net benefit to their users in some way even though they were clearly wrong.

The point Louis is trying to highlight is the difference in intent, not in execution so that is why clippy is being used as the moral backdrop to compare modern software against. Saying clippy itself is "user hostile UX" is besides the point, and either shows a lack of comprehension or intentional feigned ignorance so that you can complain about a badly thought out feature you didn't like that hasn't existed for over 20 years.

If someone randomly comes up to you and offers you an apple with a rotten spot and you say "No thanks, there's a big rotten spot" would you expect them to scold you for being entitled and looking a gift horse in the mouth? _They_ came up to _you_ offering an apple!