HN user

GreymanTheGrey

51 karma
Posts0
Comments22
View on HN
No posts found.

It's not unusual for Americans to live insular lives where the rest of the world doesn't exist in their worldview. The globe snark is unnecessary and frankly not worthy of a HN comment.

And assuming that no one outside of the US could possibly be interested in US-oriented articles in the NYT - not to mention their world news - is just another example of the insular attitude I'm referring to.

Countries outside of the US exist, some of them with extremely low incomes that nevertheless hold segments of the population that are technically competent enough to not only understand what Docker is, but to use it on a regular basis.

Cloud Egress Costs 2 years ago

Most of your points apply equally well to ingress as they do to egress. Yet the cost of one is orders of magnitude less than the other.

The only sane explanation for the vast imbalance is vendor lock-in. Everything else is hand-wavy distraction.

I live in Australia and have noted the same phenomenon on Netflix. There is an absolute dearth of new, quality content coming through. I've seen no indication that formerly exclusive content from other platforms is making its way to Netflix in my country.

I don't believe the person you're replying to is overstating at all, and certainly not 'considerably'.

Lots of things that don't make a great deal of business sense still nevertheless occur in large corporations. Frequently. I'm not sure that's a useful metric by which to judge a situation.

I personally didn't reply to that other poster, simply because their tone suggested (to me) that they were more looking for an argument than a civil debate. Yours is very different, and thank you for that. This is something I'd genuinely like to bottom out, because from my perspective there's been a noticeable, ongoing decline in the quality of search results from Google.

So, challenge accepted. Here's an example for you, and it's not even that subjective: Run a Google search that includes a minus term and tell me how effective the search results are in regards to obeying that instruction. That was a feature I used on a daily basis until Google made it completely non-functional.

If you want an example that doesn't rely on specific features, trying searching for "<thing you might want to buy> review". Enjoy the avalanche of low-quality SEO and link spam you're about to receive.

Also consider the fact that many searches you perform on Google are already offered with a "reddit" suffix, because so many people can only find the information they're looking for by appending that term to their search. Google by itself just cannot find what you want any more.

If that's not enough for you and you want specific examples, that's certainly possible. I was searching for a solution to a programming related problem on Google just a few days ago, and came up empty-handed after 20+ frustrating minutes of it including "related" search terms that weren't relevant. Reconstructing that search wouldn't be terribly difficult, if there were an indication the effort was worthwhile. In the end I went to ChatGPT and got my answer, including a fully-functional example, in less than 30 seconds. An experience that is becoming more and more the norm as time goes on.

Even spouses of Googlers suffer from this malady occasionally. I have a close friend who has a wife working for Google as a tech writer, and every time the subject of Google's decline in search quality comes up he passionately defends them as light years ahead of the competition, untouchable, always on the edge of innovation, etc.

I really don't get where it comes from, it's just a company - not a religion!

As another programmer, and one with decades of experience building software running critical infrastructure, I have a very different view.

You seem to be expecting perfection, or a reasonable facsimile of it, but that's not the bar that's being set by the existing solution (people).

Using your example of even a pedestrian task such as buying airline tickets, humans generally have a worse error rate than a computer doing it.

Source: I live in the Philippines where manual handling is still de rigeur for everything from buying ferry tickets, to immigration paperwork, to car registration and driving licenses. The error rate is far, far higher than the automated systems that do these things in other countries.

Similarly, humans (in aggregate) are really not very good at driving cars safely. Software on the other hand, is only getting better at it as time goes on. It's perhaps debatable whether computers are currently better (again, in aggregate) than humans, but with the current state of the art my view is that they are.

I'd welcome these things with open arms in the Philippines compared to the average driver on the road. Or equally so in my home country of Australia, or the US, or anywhere where humans kill each other every day in fast-moving steel cages.

I wouldn't say I 'love' it, but at the same time I don't really get all the hate. I've recently moved from a large'ish (50+) dev shop to a much smaller team of 3. JIRA was and is used at both places. It continues to serve both orgs equally well.

Perhaps what people hate are all the ceremonies and bureaucracy that arise around JIRA in dysfunctional organisations, and not the product itself? The red tape and bullshit was just starting to take over at the old place (part of the reason I jumped ship), which made 'standups' that should have taken 5-10 minutes a 90-minute soul-destroying odyssey. But that's not JIRA's fault either.

imo it's the use of the word "secured" at all that's the problem, not the context to which it's applied. "Secured" can mean many things to many people, whereas "Encrypted" is much more descriptive as to what's actually happening and much less subject to interpretation.

Slight correction, from a former Turbo Pascal (and subsequent Delphi) programmer...

"Real" types were platform-dependent floating-point types, not suitable for monetary calculations whatsoever. and would map to either Single or Double depending on the underlying CPU architecture. Sort of like a C-style "int" that would map to an 8-bit, 16-bit, 24-bit, 32-bit, 36-bit, 60-bit, 64-bit etc integer, depending on the compiler and the compile target.

Turbo Pascal did have an 8-byte, fixed point, "Currency" type suitable for monetary calculations, however using it was very, very slow compared to pure floating point ops - just as the comment you replied to suggested. If that weren't enough, library support (both built-in and 3rd-party) for math and other utility functions was either limited or non-existent.

In regards to your first question, the word you're looking for in google-able energy industry jargon is "dispatchable". And yes, dispatchability of intermittent generation is achieved in a couple of ways in contemporary electricity networks:

  1. Deliberately backing off wind or solar generation from full capacity to provide reserves for demand spikes, transmission/generator outages, etc.  This means other generation that may otherwise not have generated at all over that period, is brought online to cover the shortfall.

  2. Co-locating grid-scale batteries at intermittent generation sites ("hybrid generation facilities" in energy industry jargon) to cover short-term contingency events.

The links you've provided more deal with how to keep NuGet package versions consistent across multiple projects within a solution. While this does solve an issue, it is not the problem being discussed.

Package version consistency is certainly an issue of merit and deserves attention, however for our company's use case is a minor bugbear in comparison to the issue of package references (for build) vs source or project references (for development) in large codebases that lean heavily on shared dependencies.

Something like this would be a game changer for my workplace.

This particular issue is a huge bugbear for our team of 50'ish developers in a .NET development environment, working on a large product with a lot of shared code/models/etc that often has to be updated at the same time as application logic.

It is astonishing to me that MS haven't addressed this issue with NuGet workflow and its hostility towards developers working on internal code.