xmodem

I was hoping this would be an effort to re-use components that don't change as much between generations - such as power supplies or VRM components.

> With the Mac, Apple told everyone "we're moving to ARM and that's final."

In ~mid 2020, when macs were all-but-confirmed to be moving to Apple-designed chips, but before we had any software details, some commentators speculated that they thought Apple wouldn't build a compatibility layer at all this time around.

I thought the point of deploying to the cloud using higher level services was so that I could worry about my app and stop worrying about the minutia of managing load balancers or database servers.

Instead of interesting technical challenges I now get to worry about the minutia of Amazon's billing system. Neat! Where do I sign?

> Some other options include getting a spouse that will do it for you

Listen to yourself man. Get a spouse because you can't personally wash cookware by hand? If you make decisions in your own life how you're suggesting I should then I shudder to think what a horror show it must be.

Not even that - the data being written is coming straight from the network, and the pool has no issues keeping up.

I have a disability which makes hand-washing cookware impractical, regardless of how "easy" it is for a "normal" person.

Wood is not dishwasher safe, metal will damage the cookware's non-stick coating, which may be worse than the plastic I'm trying to avoid. I guess that leaves silicone.

We have a read-heavy zpool with some data that's used as part of our build process, on which we see a roughly 8x savings with dedup - and because of this ZFS dedup makes it economically viable for us to store the pool on NVMe rather than spinning rust.

One course I took actually provided students with the output of the plagiarism detector. It was great at correctly identifying where I had directly quoted (and attributed) a source.

It would also identify random 5-6 word phrases and attribute them to different random texts on completely different topics where those same 5 words happened to appear.

Generally a pre-condition for a market to exist is scarcity.

What type of scenarios come up in RT/audio code where an alternative path is available if you can't get a lock? In most of the concurrent code I've written the options available if I can't get a lock is some subset of try again, try again with backoff, or fail.

> likely perform far better at serving static content and other cacheable requests.

But at the cost of having a separate build step that deploys your static assets somewhere. Jetty is actually pretty fast - I've built some fairly high-volume internal apps this way.

> Also allows you to run two binaries at once for a rolling update.

You don't necessarily need an extra reverse proxy layer for this, though I will concede in some environments it's probably the easiest way to achieve it.

And that is a perfectly valid performance reason for adding an nginx layer in front. It does not IMO justify it in the general case however.

Jetty implements both TLS and compression, though in environments where I don't already have automated certificate issuance infrastructure in place I have occasionally deployed caddy as a reverse proxy just for the TLS termination.

> No reverse proxies required!

This is one that has always baffled me. If there's no specific reason that a reverse proxy is helpful, I will often hang an app with an embedded Jetty out on the internet without one. This has never lead to any problems.

Infra or security people will see this and ask why I don't have an nginx instance in front of it. When I ask why I need one, the answers are all hand-wavy security or performance, lacking any specifics. The most specific answer I received once was slow loris, which hasn't been an issue for years.

Is reverse proxying something we've collectively decided to cargo cult, or is there some reason why it's a good idea that applies in the general case that I'm missing?

Every non-trivial Java project I've worked on ends up depending on Google's Guava and some combination of Apache Commons libraries.

Even after a private repo is made public, it's common practice for new functionality to be worked on in private until it's ready.

The crates that I have looked at work by installing their own minimal signal handler which then puts a message into a channel, or otherwise delivers the message that the signal was fired to your code in a safe way.

Of course, you are still trusting that the implementation is sound.

There are several crates available which implement the dangerous parts of signal handling safely for you.

The way git works means that you can check that you have an un-doctored clone of a repo just by checking that the commit hash matches. Which in this instance is quite unfortunate, because it would be very funny.

(barring a SHA-1 collision, of course)

EDIT: i suppose another approach could be to invent poisoned repos out of whole cloth and only show them to Amazon, but I susepct that'd be even easier to detect.

Of course - I was being facetious. But I disagree with your assessment of how realistic it is. We already have it on a small scale today in the form of some projects using their own gitlab/gitea instances. If Github were to enshitify I expect we would see a push for this from a lot more communities.

I don't think it's that much of a stretch to design a system that keeps, for instance, issue, wiki, and PR metadata in git alongside code. This could then support simple import/export between instances. You could also support cross-instance forking and PR's.

The biggest problems I think you would still have are 1. third-party integrations and 2. abuse/spam prevention. Having been the system-owner for GitHub at a large engineering org before, I can say that for us, switching away would have been virtually impossible because of all the integrations we would have to replace. But, this is a consequence of the centre of gravity being Github currently and not an immutable law of nature.

As for 2, well I expect that'll remain one of the hard unsolved problems of computer science for the time being.

Yeah, I guess building a distributed version control system is basically an intractable problem.

Ethically Microsoft has about as much claim to be able to use the data for co-pilot as anyone else.

On the other hand, maybe a MSFT v Amazon lawsuit over this could be the wake up call the world needs that maybe we should stop centralising critical infrastructure in the hands of a single company. Which is why I think they wouldn't do it - at most I could see Microsoft tightening request limits on accounts associated with Amazon.

I don't disagree with the sentiment, but I think it's unlikely to matter for the adoption of Windows on ARM in the long run.

Qualcomm has shown off demos to the media of Baldur's Gate 3, video editing, music production, OBS, etc. Microsoft has claimed their translation layer is "as good as" Rosetta. Support for anti-cheat is not relevant unless you want to game online, which I don't. Driver support for third-party peripherals is a valid concern for a significant number of users, but not something I personally care about in a portable device.

It's perfectly reasonable to be sceptical of Qualcomm's claims, but you can get a feel for how confident a company is in their product by how they approach marketing - and we are seeing a level of confidence here from Qualcomm and Microsoft that we have not seen with previous Windows on ARM pushes.

I am personally inferring from this that the products are probably pretty good, but this is speculation. I won't be ordering one until I see some test results from independent reviewers.

When Apple announced the M1 Pro/Max, I predicted that they would now hold a monopoly on good laptops for the next 5 years, based on where the PC market was at the time. (Good defined as high-performance, long battery life, and without other serious compromises such as weight)

We haven't seen independent reviews of these Qualcomm chips yet, but not even 3 years later and it sure looks like the entire PC market is about to leapfrog Apple. Intel's Lunar Lake looks like it's getting pretty close too.

Being a fanboi for a particular company/tech helps no-one except shareholders. Capitalists don't need to invest in competing if there's no-one competing with them.

I suspect this is more of an ambit claim from ARM to extract better terms from Qualcomm

Question for those in this thread who hold this view: Please share your stories, along with which language ecosystem you're working within.

(Cards on the table: I've occasionally vendored stuff for a variety of reasons - because we needed to apply a patch that upstream didn't want or didn't accept quickly enough, or because we were stuck on an old version and needed to backport a fix - I've also on occasion copy-pasted 50-100 lines of code for a specific bit of functionality to avoid bringing in a 5MB library. These are exceptions - in the general case I prefer to depend on upstream wherever possible.)

I had one where the architecture team implemented the brain-dead solution, advised leadership of other teams that they should adopt the brain-dead solution, and that my team would be supporting the brain-dead solution, without consulting us, and made me into the bad guy when I pointed out that my team did not support the brain-dead solution.

We ended up supporting the brain-dead solution, but that team has now experienced 100% turn over since then.

If I were thinking about trying this, I wouldn't bother trying to appeal to top creators, especially not at first. No matter how much VC you throw at the problem, you'll burn through all of it before you even begin to make a dent. It's also been tried before and failed.

It's been discussed elsewhere in this thread that a lot of the appeal of YouTube is the small-to-mid-size creators. You may not even need to pay more than YouTube is paying in the general case to make it interesting - just offer better terms. Like a guaranteed rate per view and/or per view minute, along with a promise that all of your subscribers will actually be notified when you post new videos. You wouldn't require creators to stop cross-posting to YouTube as well, but you could pay a modest bonus for each platform-exclusive they post, or pay for timed exclusives with a call-out to your platform in the YouTube version.

You would still need to pour billions into it to get anywhere though, and even then, it's not even clear if YouTube is actually profitable as an independent business currently.

It's not really a matter of accepting it or not - my eyesight is poor enough that I couldn't get a license if I tried.

I was also lucky enough to grow up in a place that provided generous benefits to people who couldn't see well enough to get a license - free public transport and 50% subsidised taxis. Having access to this mitigated the loss of economic opportunity significantly. Where I'm living now I don't get those benefits, but I'm in a position where I no longer need them.