God, i am so glad to see these guys succeeding. The sun may have burned out, but the sky is still bright thanks to them. May they be so successful that i can eventually buy workstation versions of their minicomputers, sort of like how they made CoaL for triton.
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).
reply