dan_quixote

We're starting to get some political alignment on anti-trust against Amazon at least. Though one party seems motivated by worker/consumer right, the other by retaliation for Bezos' ownership of WaPo.

If the vehicle's air conditioner compressor only runs at one stage, does it even matter? Are there any automotive air compressors with multiple stages/speeds?

I've seen success using RAMDisk instead of running entirely on SD card

Are those of us happy/comfortable with current major cloud offerings simply not speaking up here? I can't fathom running a data center any longer for a company of nearly any size. Given my team's responsibilities, this would require 2-3x more headcount with significantly worse SLA/SLO if we still ran our own datacenter. Maybe it's not such a big deal for places with constant demand? Or is this just a case of observer bias?

How did you manage the technical degree and full-time athlete duties? Did they occur at the same time?

Care to share an example of someone better?

Yeah, that's a complication/cost of HA that a significant portion of industry has long accepted. Everywhere I've been in the last 5 years has had this assumption baked in across all distributed systems.

> The frustration with interruptions is that they introduce a sudden increase in required working memory

I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.

Have you found hiring to be significantly more difficult in the last 6/12/18 months? I don’t mean the process - that’s universally more difficult since COVID began. I’m referring to the quality and behavior of candidates. Our job postings get as many responses as ever, but the candidates rarely match their resumes lately. And the number of interview no-shows is much higher than normal. This has turned into an astronomical rejection rate. Is anyone else seeing the same? If not it is long past time to re-evaluate our process.

> the way distros inject themselves into this software development process produces these bad outcomes

As a former maintainer of packages in an enterprise Linux ecosystem, I agree. But...the patches are often meant to solve a dependency mismatch and the maintainers can't easily pull related dependencies forward without breaking other applications. It's great that other distros like Arch just simply upstream the patches - it's the right thing to do after all - but that takes time that the enterprise distributions don't always have.

Can anyone surmise if the flask type hinting is vulnerable to annotations issue that pydantic/fastapi recently faced?

https://github.com/samuelcolvin/pydantic/issues/2678

> The fact that Fedex/UPS haven't gone wholesale into electric is telling at this point

Both companies had a huge moat until Amazon came along blew their doors off. And Amazon has been investing heavily in electric delivery vehicles: https://www.cnbc.com/2021/03/18/amazon-begins-testing-rivian...

An offer "in writing" means effectively nothing in the US. I'm not sure where people get this idea. Your employment is, for all intents and purposes, "at-will" even if it's not technically codified in law due to the high burden of proof on the employee. If your employer wants to change the contract, you've got an uphill battle to keeping the original terms AND your job.

Quoting myself here [1], but Kafka is still very architecturally un-sound for containerized deployments.

-------------------------------------------------------

The problem I see with kafka is that it was built before cloud architectures were commonly adopted (with distributed systems everywhere). Confluent has put a lot of effort dragging kafka's architecture to the present, but some major features are missing:

  - Auto-scaling:  Confluent finally introduced "elastic scaling" a few months ago but it only allows you to scale up and must be triggered by the admin (no threshold-based auto-scaling).

  - Multi-tenancy:  Planning for a multi-tenant kafka cluster is not for the faint of heart.  Achieving isolation tends toward liberal usage of topics of which starts to become unmanageable in the low thousands.  This isn't crazy when you've got a few hundred microservices and several tenants to keep isolated.

  - Decoupled brokers and storage:  Any broker scaling or failure can lead to downtime while event storage is redistributed.

Confluent's Cloud service reduces operational overhead but isn't always feasible due to cost, resource limits (like service accounts or schemas for instance), data controls, etc.

-------------------------------------------------------

[1] https://news.ycombinator.com/item?id=25984560

In politics, they call this a "trial balloon".

https://en.wikipedia.org/wiki/Trial_balloon

Alaska is ready and willing to prove you wrong.

Do you know of any APIs hosting ship AIS data for free? I did a bunch of digging on this a few years ago and essentially came up empty-handed.

Continental Europe was by far their largest market just a couple years ago. North American expansion was always a matter of discussion (if not investment) but it has only really picked up steam in the last year or so.

I don't know the political climate in Oregon about hydro, but it's starting to turn a bit in Washington. Dams are pretty awful for salmon and so much of our ecology is salmon-based as well as the culture/livelihoods of Native Americans.

The biggest story in recent years was the Elwha dam removal. It's stunning to see how much the landscape has changed since: https://therevelator.org/elwha-dam-removal/

And a recent story about a Skagit river dam: https://www.king5.com/article/news/investigations/seattles-s...

Power loss is a function of current. So major transmission lines use very high voltage to lower the current (and thus the power loss). Of course, there are losses at the transformer(s) the step the voltage up and down. Unsurprisingly, it's a very use-case-dependent engineering problem.

You should also keep an eye on idle data usage. I had several chromecasts plugged in around the house and discovered (with my UniFi setup) that they were each using about 500MB per day each just sitting idle. That's about 15GB per chromecast per month. Not trivial when you have several of them and a 1TB cap.

More details: https://www.howtogeek.com/337719/how-to-tame-your-chromecast...

"moral indignation" is timeless. But it does feel uniquely current to have two political parties that seem to use it as their primary currency (in the US at least). I have trouble recalling any major legislation after the Affordable Care Act that wasn't fully grounded in moral indignation or virtue signalling.

I interpret Pfhreak's comment to mean un-checked capitalism will naturally result in wealth consolidation. The article describes how we loosened our management of this natural law and witnessed a more rapid wealth shift as a result.

Deathmatch programming doesn't sound very pleasant.

But I hope most people here don't feel a morale hit when their code gets tossed. Inherently, I understand the desire for one's creative work to live on, but that's essentially incompatible with this industry. And I also have found much joy in turning-down/deleting existing services I've written. My team celebrates these events and it's always fun to give that high-maintenance service a viking funeral.

The problem I see with kafka is that it was built before cloud architectures were commonly adopted (with distributed systems everywhere). Confluent has put a lot of effort dragging kafka's architecture to the present, but some major features are missing:

  - Auto-scaling:  Confluent finally introduced "elastic scaling" a few months ago but it only allows you to scale up and must be triggered by the admin (no threshold-based auto-scaling).

  - Multi-tenancy:  Planning for a multi-tenant kafka cluster is not for the faint of heart.  Achieving isolation tends toward liberal usage of topics of which starts to become unmanageable in the low thousands.  This isn't crazy when you've got a few hundred microservices and several tenants to keep isolated.

  - Decoupled brokers and storage:  Any broker scaling or failure can lead to downtime while event storage is redistributed.

Confluent's Cloud service reduces operational overhead but isn't always feasible due to cost, resource limits (like service accounts or schemas for instance), data controls, etc.

Is it really that burdensome for novice programmers? Maybe it's just been too long for me to remember the pains...but I'd expect most novices to heavily use primitive types which shouldn't be that hard to grok.

As a Seattle resident in a common float plane flight path, the piston engines can be quite loud. You can hear them inside with windows/doors closed and moderate household noises (like a shower or washing machine).

Yeah, I feel cursed by the same habit. I get to about a 75% understanding of a domain and feel like I'm about to run out of things to learn...so I expand the domain and continue until I'm at that 75% mark again...and repeat...

> human cognitive biases that make us bad at objectively assessing risk

I generally agree strongly (e.g. car vs air safety). Though this group is highly cognizant of KNOWN risks. It's the UNKNOWN risks (usually found at those interfaces I mentioned above) that get overlooked. Unknown risks definitely will be more problematic in a compressed-schedule environment.

I spent many years working very close to Boeing, though never for Boeing so I wasn't privy to meetings that may have included the alleged malfeasance you describe. What I did see was communication breakdown between major teams. Some interface features were mutually assumed to be owned by another team and fell through the cracks. MCAS in response to unstable thrust vector is commonly cited as an example of this.

But I think it's worth noting to the (mostly software oriented) HN crowd - aerospace projects have massive manufacturing cycle times. Some things literally take years to manufacture for the proof-of-concept stage, let alone production. You can't NOT be incredibly schedule-oriented in this environment. This can cause some perverse incentives for management (which must be mitigated), but there are always going to be somewhat risky last-minute changes that could seem ill-advised in hindsight if you want to deliver something.