Hacker Newsnew | past | comments | ask | show | jobs | submit | Dylan16807's commentslogin

It's not really the same. Pilots need extensive training for how to handle emergency situations and maintenance crew don't. It's not super harsh to say that pilots in different regions are at different levels for those weird situations. It is super harsh to say that maintenance crews in some regions can't do their baseline job.

That's entirely false, the maintenance crew are highly trained people they don't figure out things on the go and when they have to figure out solution to an issue, it's based on what they know about the aircrafts from their training.

Totally agree. Maintenance staff often get ignored. It is worth pointing out how skilled these people are and, in general, how dedicated they are to their task. It is also worth pointing out that often maintenance do get involved in emergencies, especially those that work on the line. I had a guy catch a bleed air leak and signal fire in seconds, saving the engine and potentially a lot more. We like to think of the pilots, but maintainers deserve a lot of credit.

Maintenance crew are highly trained people that in strange situations can pause their work to figure out a fix and ask experts what to do.

Very different from how a pilot has to handle strange situations. Being ready for anything in an airborne plane without a pause button is so much harder, impossibly hard, and not every air authority tries as hard to reach the impossible.


Stand outside an engine test cell for a while and tell me that maintenance crews don't deal with emergencies. I'll bet they do so more often than pilots, we just don't hear about it because there are no passengers at risk.

This is not just filling out reports and looking at stuff, they're in no way comparable to your local garage mechanic (and not to dump on them either: they too have to deal with out of the ordinary situations).

The responsibility issues are the same as with the pilots as well, they fuck up people die.


> you all are debating whether something can happen after it already happened

My goalposts have always been on levels 3 and 4.

Elon Musk has been promising level 4, sometimes level 5, this entire time.

It has not already happened. The cars are level 2.


If it's not native then we need to give powerful Bluetooth capabilities to web pages which isn't very good.

People said the same thing about allowing the browser to trigger the microphone and the camera.

Use sane browser and or OS inherited permissions, and sane permission-promoting and gating,

and it’s a non-issue.

(Have you seen the prompts for Location, Microphone, WebUSB, and other “scary” features in the browser?

There’s really not much room for misinterpretation!)


> ZeroFS supports running multiple instances on the same storage backend: one read-write instance and multiple read-only instances.

Well that's a big limiting factor that needs to be at the front in any distributed filesystem comparison.

Though I'm confused, the page says things like "ZeroFS makes S3 behave like a regular block device", but in that case how do read-only instances mount it without constantly getting their state corrupted out from under them? Is that implicitly talking about the NBD access, and the other access modes have logic to handle that?

Edit: What I want to see is a ZeroFS versus s3backer comparison.

Edit 2: changed the question at the end


> But if it can do 90% of the work for you, it is a serious force magnifier.

Well, we could characterize a Tesla as doing 90% of the work but it's not at all a force multiplier. Your "10%" supervisory contribution takes just as long as doing 100%.


I think any measurement of development velocity is shaky, especially when measured between two different workflows, and especially when measured by the person doing the development.

Such an estimate is far less reliable than your eyes are.

So if people want to do more and better studies, that sounds great. But I have a good supply of salt for self-estimates. I'm listening to your input, but it's much easier for your self-assessment to have issues than you're implying.


Is "by design" supposed to imply a negative scheming aspect, or am I reading too much into your comment? This page won't really be relevant to anything after a couple months, so if the link breaks I don't think there's a big problem.

> every single month we use it, versus paying a little extra for the few times we go over

I'm interpreting "every single month we use it" as every month you use starlink. In that case, you're incorrect. You can change plans when you hit the limit and then change back for the next month.

So instead of paying $1/GB extra every time you go above 50GB, you pay $115 extra every time you go above 100GB.

For most usage patterns, the second option is cheaper. And it sounds like your usage pattern is one of those.

(If I interpreted you wrong, and "every single month we use it" is supposed to mean the months you go over 100GB, then "every single month we use it" and "the few times we go over" mean exactly the same thing. Why word it with such different implications each time?)


It's not like 100GB is some huge amount of data. It's easy to hit, so if we're judging the overage amount we should be comparing it to the full 100GB, not some made up guy that only uses 10GB. There are users on unlimited consuming many terabytes, and they're not paying all that much more. It's not unfair to anyone if the cheaper plan is able to slowly reach 200GB or 300GB in a minimal-impact way.

Also dropping all the way to 10kbps with enough use would just suck. It's effectively unusable and it would be extreme penny-pinching to make sure the maximum 24/7 user can't squeak out more than 3GB extra on their 100GB plan. You get more variance than that from different month lengths.


There's all this blank space to the left of the comment. Some of that could be used for bigger arrows.

Or some of the buttons on a comment could be hidden until you tap the comment. (And you can do it in CSS if div toggle is an offensive amount of javascript.)

There are some low-hanging fruit that would make the experience better. It's fine but it's not great.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: