HN user

vhab

426 karma
Posts2
Comments18
View on HN

This goes for devs in all industries, it's not a problem unique to games.

If anything, the most competent developers in terms of getting the most performance out of hardware are game developers.

For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.

The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.

A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.

I hope Microsoft follows suit and introduces a unique namespace per customer as well.

Open hardware for 3D printers is actually thriving. There's a whole fleet of community designed hardware, with most innovations to consumer 3D printing still originating in the DIY community.

Multiple manufacturers have direct contact with community members to produce custom hardware at a small but affordable scale, and keeping up with rapid iterations and multiple hardware improvements throughout the year.

Some of the most cutting edge as well as niche 3D printing hardware available to consumers are being sold on small webshops operating out of someone's garage.

If anything, we're in a golden age right now. 3D printing in 2025 is a very exciting place to be.

This could have been an interesting take from anyone but Prusa. While they've earned themselves a great deal of goodwill from past contributions to the ecosystem, they're a failing company pivoting to dark patterns in an attempt to cling to relevance. It's heart breaking to see they still haven't been able to take a good hard look at themselves, and understand their own role in why they are scrambling.

Blog posts like these might be heralding the beginning of the end for Prusa.

The comments in this thread are very interestingly making the Author's point.

Yes, you can be "technically correct" saying branches are just refs, but it's not a useful statement for most users.

I believe the author makes a very valid point, and we could do with a bit less "technically correct" and more with language targeting the usage rather than technical implementation.

Git is confusing enough for many people, and we don't have to make it more confusing for them.

Interestingly though, there's a slow but steady push towards 24V on boats. More electronics are available in 24V version or simply support both 12V and 24V. And new boats tend to have a 12V and 24V bank. Electric sailboats usually have a 48V bank as well.

And in an entirely different area, 3D printing completed their transition from 12V to 24V some years ago, and currently there's an active push towards 48V.

I'm personally just looking forward to not spend a fortune on cables due to low voltages. It's frustratingly expensive to carry 12V a decent distance with some higher current draws.

Unfortunately this doesn't surprise me.

We worked on a Stadia title before launch. We were constantly reminded by Google how big the YouTube integration would be, which unique killer features we absolutely had to integrate with, and more.

And non of that ever materialized after launch. If Google can't even convince their own internal teams to cooperate, how do they expect studios and consumers to care the slightest for their product.

It also didn't help that supporting Stadia was equivalent to supporting an entirely different new console in scope, except less battle tested and much more buggy. Meanwhile all their competitors allow existing console or Windows builds to be shipped to their platforms.

And while we're sharing anecdotes, this was a fun one. For the longest time devkits were limited to 1080p, but at least the output was streamed from rack mounted servers that supported a couple of concurrent sessions. A few months before launch, they finally made 4k devkits available, except they supported only a single session, couldn't stream, and instead had to sit at a developer's desk with a monitor hooked up...

Let that sink in, a streaming service's devkits couldn't stream :)

I don't expect to keep warranty, it just diminishes any praise you could give for other statements they make like quoted in the OP

you have every right to open up your Steam Deck and do what you want with it.

We already have this right for things we own, on exactly the same terms, which is it voids warranty.

They managed to disturb millions of worker to an "attention driven" work culture in which everything needs to always be synchronous and immediate.

I see where you're coming from. But anecdote time.

The immediate communication fixed something for us which would previously be a more disruptive tap on the shoulder, or alternatively an only once a day processed e-mail. Slack gave our devs time to finish their thought, write out that line of code, before tabbing to Slack to see what's up.

Because you see, I love my team, but they're not perfect. Just like the vast majority of people they're imperfect beings working with imperfect information. And in order to get them to output quality code (as in, does what it needs to do, bug free, without incorrect assumptions about data) they need to communicate to each other and me. We can't wait until a PR to catch they didn't fully understand these data models setup by another guy. Nor can we wait until a PR to realize someone took the wrong approach trying to fix a problem.

Someone getting disrupted might mean someone else can progress with their task. What I'm trying to get at, I need my team to communicate and communicate often. We have plenty of issues, just like any team, but most of them come from the lack of communication. Slack, or any other similar platform allowed to strike somewhat of a happy medium where the barrier to communicate isn't too high nor too low. It's less formal and faster than an email. And keeps a better log than an in-person conversation would.

Added bonus, it also helps us to have a more liberal 'work from home' policy.

If hiring a freelancer to do a little thing tends to generate all sorts of nightmarish legal liabilities, your company is either a government contractor or it has even bigger structural problems than hiring.

It might not be an issue for your company, but your candidate might have a non-compete (or other clause) preventing them from accepting compensation or even performing work for another company at all.

Things get trickier as soon as money is involved.

If you're in tech, Sweden is a more attractive opportunity. It's pretty similar to the Netherlands culture wise, but with a much bigger and faster moving tech scene.

That said, any in that line up will be a bit of a culture shock coming from the US.

Source: I'm Dutch and moved to Sweden

From an IT and "just works" perspective, Linux was a no-go for us.

It wasn't particularly about the UX on Linux desktops, but rather they don't fit in our company culture when it comes to how assets and IT are managed.

Which is why I wrote it from my own perspective as an anecdote.

As usual, YMMV

There seems to be a lot of conspiracy theories going on, on what I personally believe to be a really straight forward and logical reaction.

From my perspective, "Bash on Windows" is a reaction to the wide adoption of OSX for development (In particularly web development seemed to have a mass migration).

For obligatory anecdote:

I'm a longtime and loyal Windows user. Windows has been my primary development platform even though parts or all of our stack ran on some flavor of -nix. I've always encouraged my team to do the same, primary motivated by the better UX on Windows.

But, like many in the past few years, I jumped the OSX bandwagon and moved the entire department over. This wasn't a fun transition, and came with many pains. But ultimately it was a necessary transition as the tools we needed just weren't supported on Windows.

Development became more complex, tooling became mandatory at every stage of development and only OSX offered us a reasonable balance between a -nix-like environment that ran the tools with decent UX.

Microsoft's move to bring Bash to Windows will likely motivate me to migrate back in due time.

While some may be spinning conspiracy theories, I'm personally just really glad Microsoft is moving in this direction.

While not Docker Cloud specifically, when we eyeballed UCP we found it very underwhelming when pitted against Kubernetes.

To us it appeared yet another in a sea of many orchestration tools that will give you a very quick and impressive "Hello World", but then fail to adapt to real world situations.

This is what Kubernetes really has going for it, every release adds more blocks and tools that are useful and composable targeting real world use (and allow many of us crazies to deal with the oddball and quirky behavior our fleet of applications may have), not just a single path of how applications would ideally work.

This generally has been a trend with Docker's tooling outside of Docker itself unfortunately. Similarly docker-compose is great for our development boxes, but nowhere near useful for production. And it doesn't help Docker's enterprise offerings still steer you towards using docker-compose and the likes.