The thing I don't like with these kinds of articles is rather than list potential pros/cons they make a wholly one sided story everyone is supposed to agree with the whole way and say "oh wow, yeah" at the end. Reality is it breaks right at the start - you don't really know when a good time to call someone is by the sun. You know because of when they wake up, when they go to bed, what hours they work, what you're calling them about, when they like to eat meals, etc. All of that varies by many hours within a timezone based on culture or individual, so it derails that build up pitch. It's a given the author isn't particularly swayed by that, but that they don't even talk about the detail and just move on spoils the rest of the (well put together) list IMO.
One way or the other I don't think we'll make a big shift in timekeeping until/if we ever have a sizable population off Earth. Of course, that introduces its own time problems we don't have to deal with as much all being so close together :).
I don’t personally see a lot of difference in consulting a chart of “what time is it in x country” vs a chart of say “the time business starts in country x”.
They’d be the same exact list. “offset +9 hours”- the only semantic difference would be that clocks don’t change.
I should mention that I spent a little bit of time in Saudi Arabia and expecting them to be out and about at 7pm like in Western Europe and the USA is crazy, they seem to get up later and keep going until 3am. I’ve never seen rush hour at 3am until I spent time in Riyadh. It’s a false construct we’ve decided on: that everyone follows the same time pattern anyway.
Why do we believe the world needs to wake up at 7am? If nothing else its so incredibly arbitrary to begin with.
I never found those arguments for keeping time zones particularly compelling. Everyone has their own schedule, trying to standardise time to sync people up is silly, you sync by talking to them and asking them what times they are available. The number on the clock doesn’t actually matter.
But DST affects us exactly because people tried to standardise on time AND then shift that meaning twice a year. If we ditched timezones, then businesses could say ok we will work from 1700 until until 0100 or whatever, based on time relative to sunrise, it it would be consistent all year round.
The thing is, regardless of timezones, you have to ask people what times they work or are available or whatever. Also consider that timezones are arbitrary and made up anyway: china physically spans the space of 3 timezones yet the entire country uses one timezone.
at least one of the pilots did. according to the preliminary report, the switches were only in the cutoff position for 10 seconds before being switched back to the run position and the engines started to spin up again
so just to confirm, this HN submission [ 1] should have linked to this pdf of the paper [2] and put the article [3] that is the current link for the post as a comment?
The question we always ask is whether a source contains “significant new information”.
In the case you cited, the Quanta Magazine article is a report about the study’s findings that is readable and understandable to lay people, and includes backstory and quotes from interviews with the researchers and also images.
I.e., there’s plenty of information in the article that isn’t in the paper. So we’ll always go with that kind of article, over the paper itself, particularly in the case of Quanta Magazine which is a high-quality publication.
In other cases an article is “blog spam” - I.e., it just rewords a study without adding any new information, and in those cases we’ll link directly to the study, or to a better article if someone suggests it.
Anyone is always welcome to suggest a source that is the most informative about a topic and we’ll happily update the link to that.
We built something similar for the managed DB we use, but i think it's a mistake to autogenerate the migration scripts instead of autogenerating the schema from the migration. Things like changing an enum, adding a nonnull column that shouldn't have a default to an existing table that already has data in it, and migrating data from one representation to another (eg, 'oh hey, we definitely shouldn't have made our users table have an fname and an lname field. let's change to full_name and preferred_name') are easily done in a migration script but hard, if not impossible, to infer from just schema changes.
What are side-effects but undocumented arguments and returns?
Firstly, you want to ensure your functions are pure with respect to input. That is to say, they might reference a configuration or context object that is passed to them as an argument, but they'll never reference some global object/variable.
So then the docker image inside some docker registry? Both the image and the registry are values in the config/context argument at the least. Maybe they're their own separate arguments depending on whether you prefer a single big object argument or a bunch of smaller more primitive arguments.
So then the pure function that expects the docker image to exist in some registry is no longer
Int -> Int
It's now
String -> String -> Int -> Int
because it needs a registry and an image. Maybe it's
String -> String -> String -> String -> Int -> Int
because there's a username and password required to access the registry. Icky, but if we make a few types like
data Registry {
user :: String,
password :: String,
url :: String
}
that becomes
Registry -> String -> Int
But we could make it better by doing something like
data Foo {
reg:: Registry,
image :: String
}
and now the function can be
Foo -> Int -> Int
This doesn't fix the image not actually existing in the registry, but at least now we know that the two functions aren't composable, and when it fails because the image doesn't exist we can hopefully trace through to see who the caller is that's giving it incorrect data.
PS: sorry if i got the haskell typing wrong. I don't know haskell so that's the result of what i could cobble together from googling about haskell type syntax
It's not meaningless, the author just doesn't like it. Open-source and source available were always meant to be watered-down versions of the FSF's free software specifically to be more palatable to businesses. That's not a bug and it's not even a feature. It's the freaking mission statement.
The aviation industry doesn't usually reduce incidents down to a single proximate or ultimate cause like that, but instead notes every decision/event that contributed to the incident occurring. And then they usually spend time on how they can reduce the likelihood of such an event reoccurring at every single point in that chain. It appears that the coast guard plane lined up on the runway to prepare for takeoff instead of holding short of the runway as instructed and the JAL pilots did not see that their runway was not actually clear until it was too late to avoid a collision (if they saw the other plane at all).
From the JAL plane's perspective, automation is only as good as the sensors and logic which would be checking for if a runway is actually clear. Regardless of whether extant solutions are better than humans right now or will be better in the future, those solutions will still have a same failure mode as humans, which is suddenly realizing a runway that appeared to be clear actually isn't clear when it is too late to abort.
From the coast guard plane's perspective and from the controller perspective, automation and warnings might have been able to alert or prevent, however, automation can't just be thrown around as a solution without deep knowledge of the system and environment in which it will work. The main reason for this is ensuring that the transition between automated-control and human-control is clearly evident to the humans involved, that it occurs with enough time for the human to actually be able to avert a problem, and that the human is actually ready to take control. If the automated system silently disengages, a plane with permission to take off from a runway will instead just sit on the runway because the pilot assumes the automation will begin takeoff as expected, which brings us right back to a plane on the runway when it shouldn't be there and a landing plane not seeing it until it is too late. It is actually possible to land a plane purely with automation (military drones do it all the time), however that isn't done on commercial aircraft, because the constraints are so tight that if the automation were to fail for any reason there is a large chance the human pilot would be unable to prevent a crash even when perfectly monitoring the system (and perfect monitoring can't be assumed).
There's actually a legal reason for tacking on anyone who is plausibly liable. The basic idea is to sue everyone in a single case and let the court sort out actual liability for each party as part of that single case.
Say the lawsuit is originally against just Holman Fleet Leasing and FedEx is the one legally liable (Maybe FedEx is the one that is doing something naughty. Maybe there's some contractual language around Fedex assuming all legal liabilities for the vehicles sold.). You're going to spend a bunch of time in court arguing with Holman about if they're even the right party to sue, and your case is either going to get thrown out or you're going to lose. Meanwhile, the statute of limitations is still ticking, so if it takes a long enough time to adjudicate the case against Holman, you won't even be able to refile the same case with the correct respondent. Oops. but if the statute of limitations miraculously hasn't run out yet, that's not even considering the possibility that the kind of person who would roll back an odometer would also have a punishingly short document retention policy, so all the documents that still existed at the time you filed against Holman have long since been shredded and destroyed, so your discovery in the new case against Fedex is going to be a single email saying "yeah, we don't have anything going back that far. Oops again.
Now consider the lawsuit filed initially against both Holman and Fedex. Assuming your list of respondents is complete, the case isn't going to get thrown out because you sued the wrong person. Liability will still be adjudicated (and the case amended to drop respondents as the proper liability holder gets determined), but now you don't need to worry about the statute of limitations running out as you wait for the determination of liability against the first respondent. And the document retention clock starts with that lawsuit and covers the time where you're just determining who hold liability, so now they can't delete those documents even if they other wise would be. Both of them are now going to be legally required to retain all the stuff you list in discovery for the duration of at least their involvement in the case. Sure, they could destroy those records anyway, but that sort of thing is regularly used to infer guilt of the respondent with the worst possible inferences when it's destroyed in violation of discovery.
These things never see the inside of a court room. It'll end up as a settlement check, with none of the involved parties admitting to anything. The lawyers will then move onto the next low hanging fruit.
I've learned over time, it doesn't matter how righteous your defense is - all that matters is the money it'll cost to make the issue go away. Turns out, it's almost always cheaper to write a check than defend yourself.
