HN user
Due to some counterintuitive geothermal reasons, it's likely that three of the four Galilean moons (of Jupiter) as well as Titan (Saturn's largest moon) all sport significant underground oceans of liquid water.
For example, despite being much smaller than the Earth, Ganymede is projected to harbor more liquid water than all of Earth's oceans combined.
(Whether this adds up to 30% depends heavily on what you start counting as a "body")
The issue isn't one of fixed vs rotation, it's that radar can't fundamentally achieve the resolution necessary to distinguish important features in the environment. It's easily fooled by oddly-shaped objects, especially concave features like corners, and so while it's great for answer the question of "am I close to something" it's not reliable for telling you what that something is, especially at longer ranges.
Note that the only proponent of the man-made theory mentioned is Graham Hancock, a somewhat infamous Atlantis-chasing pseudoscientist and overall purveyor of extremely flimsy "ancient civilization" theories.
That doesn't mean that there aren't also legitimate archeologists who might be excited about these prospects, but the lack of their mention is...suspicious.
A better approach is to optimistically merge most changes as soon as not-rocket-science allows it, and then later review the code in situ, in the main branch. And instead of adding comments in web ui, just changint the code in-place, sending a new PR ccing the original author.
This may work for small projects or open source projects that generally receive high-quality PRs, but this sounds truly infeasible for large teams or organizations.
There are a couple reasons why the code review process occurs before merging. First, it helps keep the canonical version of the codebase in a "correct" state. This is, ironically, an extension of the "not rocket science" principle that the article mentions. Without this invariant, any checkout of the codebase might contain what is essentially "WIP" code that will waste other engineers' time if they have to interact with it. Second, the social pressure of blocking someone else's work is an important and necessary force for motivating code review. The idea that folks will go back and review code that's already been merged is akin to "will add tests in a followup PR". It's a pleasant lie we tell ourselves, but it rarely comes true.
Relatedly, the article also seems to suggest that the code REVIEWER should be providing the changes necessary after code review. This is problematic for so many reasons: first, it places an even higher burden on code reviewers' time which no one wants; second, it encourages poor code hygiene if someone else is just going to fix up your crappy work later on; third, it robs junior engineers of what is perhaps their most valuable learning experience: getting feedback from more experienced engineers and acting upon it.
(there are other issues here; the general thesis of the article leans heavily towards making code easier to _write_ rather than _read_, which again I think it just not appropriate for a codebase with a significant lifetime or number of contributors)
I have no insider knowledge here, but Google tried to go the high route of working with carriers for years before giving up on their intransigence.
I suspect that Google's RCS is proprietary as a blunt instrument to prevent carriers from trying to either (a) undermine e2ee in some weasely way or (b) have the ability to pick and choose the pieces of the implementation they want to support. You either get the whole thing, with e2ee that you don't control, or nothing.
Sadly the lesson from Google, Apple, and Whatsapp here appears to be "cooperating with telecom carriers is a fool's errand".
I can replicate this behavior fairly easily in a browser.
1. Open incognito window in Chrome
2. Visit https://t.co/4fs609qwWt -> 5s delay
3. Open a second tab in the same window -> no delay
4. Close window, start a new incognito session
5. Visit https://t.co/4fs609qwWt -> 5s delay returnsJust for comparison, the extended-range Ford Lightning pickup truck (the one that can power a home for three days) has a 131 kWh battery.
I'm a little sad that there aren't any comments describing what is technically novel around Fuchsia and why it is/why it isn't interesting from an OS design standpoint.
I get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit.
Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?
I don't see what there is to lament. If this is necessary spending (it seems it is) and there is other necessary spending, then it seems we must pay for both of those things.
I guess we could wish that the hornets never arrived here, but the life of a government is solving thousands of problems like these. If not the hornets, it would be something else. The uplifting moment is that this was a successful containment. Money well-spent :)
I have to say, after reading those posts, Matt is looking more trustworthy than the OP.
Especially considering the definitely-not-a-sock-puppet post by jimboykin [1], an account that was created immediately after this thread and has but a single post on HN.
Console hardware is vastly underpowered compared to PCs and yet frequently competes with mid-tier graphics cards in terms of performance and graphics quality.
The reason is that game devs are able to optimize their games specifically for the GPUs in the console hardware. Google is presumably betting that if they get enough market share, devs will start to optimize for _their_ hardware, and reap similar rewards.
Also, unavailable to most people.
Yes, I suppose it was kind of nice when the internet was only available to the tech-savvy, to those who didn't mind maintaining a second job as a Unix administrator. But for people who just wanted to _write_, it was not welcoming.
Yes, you can go to wordpress.com and sign up for your own blog, but then you're just on the wordpress platform, and subject to their whims. If your plan works, then wordpress.com becomes so big that they're the bad guys now.
Facebook, Medium, and others are here because we, the tech world, didn't give the rest of the world any other options. We didn't settle on a standard, containerized server platform that was simple enough for users to drag "Wordpress.server" onto "SomeHostingProvider.com" and get a working server. The tech ceiling was _always_ too high, and it was our own hubris that we weren't willing to build a more welcoming environment.
While beautiful, most of these pieces are primarily ceremonial or intended for generals who would rarely involve themselves on the battlefield†.
Almost all of these pieces date from after the unification of Japan under the Tokugawa shogunate (c. 1600). From 1600 to 1850 Japan experienced a stable period marked by very little real armed conflict. During this time, the samurai transitioned from soldiers to what were effectively mid-level bureaucrats. However, unlike most bureaucrats, they managed to retain all of the trappings of a martial lifestyle, including ornate armor, beautiful swords, and the occasional mortal duel. It was during this time of relative peace that these (sometimes ridiculous) fashion pieces developed, somewhat complicated by the tradition of incorporating pieces of much, much older helmets into the "core" of the helmets (one of the helmets in the OP has a core dating from the 14th century, but was significantly embellished later on).
†This is generally true of what arms and armor have survived from around the world. The stuff that was actually used rusted away long ago; the highest chance for survival was to have been so valuable that no one dared to actually take it onto a battlefield.
This is the use case they highlighted in the keynote. It doesn't appear to be a system designed for shipped games.
No, in fact one of the bug comments refutes this sarcasm:
The default driver on the distribution we support is broken.
They do test the default driver on the distributions they support. The tests show that the driver is unacceptably unstable. It may work better on other distros/versions, but they don't have time to test those. They're happy for others to help out in testing these unsupported combinations, however:
Again, if someone wants to spend the time to test thoroughly to narrow down the blacklist, we will accept patches.
There's a decent argument that current desktop OSes are a poor man's OS. The permissive-by-default approach of traditional OSes is deeply problematic and attempts at reigning that in (Mac App store sandbox, capabilities work on *nix) have largely failed to gain any traction.
It's certainly not elegant that we build a proper security model from within a browser rather than an OS, but it might be the only practical approach (short of some large-scale migration to iOS/Android/Fuschia etc, which seems...unlikely.)
Such a feedback loop -- of identifying which interviewers give the "most accurate" scores -- doesn't exist. Nor is it clear how you would build such a system (how do you quantify a "bad hire" or "good hire" in such a way that isn't lost in the noise?). Interviewers are trusted to do the best job they can.
Remember, interviewing is volunteer work, not something that will advance your career. The results of the interviews and committee deliberation are confidential, so there's no way to gain a reputation for being a "great interviewer".
Some perspective from the interviewer's side may help here:
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
This article is just a recapitulation of the old pure functional programming vs. imperative programming argument but wrapped up in new packaging. Most of these issues, such as needing to validate types at codebase boundaries, functions that have side effects, and unsound static type systems, could just as easily be leveled at most imperative languages (C++, Java).
So yeah, go use a proper functional language (many of which compile to JS!). Complaining that an imperative language isn't a soundly-typed functional language is tautologically true I guess, but who cares?
No, the author is showing off how smart they are, and in an unprofessional and nasty manner to boot.
It's kind of you to gift the article with some genuinely thoughtful conclusions, but you're doing all the work there, not the original.
As the grandparent says, it's easy to poke holes in something, especially when disregarding important requirements that influenced its design. The fact that the OP can't point to any implementation of the "right" way to do things is telling.
So citibank and NTP will need to change their domain structure. That's okay: those are confusing structures.
This is a tradeoff -- continuing to support already-confusing differences is not worth the loss of the ease-of-use gain referenced in the grandparent.
Maps are, infamously, a place where "truth" is not usually an attainable goal. All cartographers are faced with the decision between creating a map that is uncontroversial vs. one that is useful. When possible they optimize for both, but when the two (frequently) are in opposition to one another, it's time to choose.
Matthew Hyland, [...] said he considered those all made-up names, some of which he deleted from the map
Unfortunately all place names are made-up names. If everyone suddenly agrees to start calling a place by a new name, who is Google to argue? But what if people can't agree and some start calling it by a new name and others don't? And of course you can't just poll every resident for their opinion, so you're stuck with relying on other signals...like local advertising and publications.
Appeals to authority are also of dubious value. There may be an "official" map somewhere, but if it doesn't reflect the day-to-day usage of the space, is it very useful? Prescriptivist maps generally enjoy about as much success as prescriptivist linguistics -- pretty to look at, but not what you want in your back pocket.
It's true that, based on my interviewing experience, candidates with only a jQuery background are unlikely to have the skills to cut it developing large-scale software at a large-scale company, which is what I am hiring for. At the moment I interview mostly front-end candidates, and it takes a lot of sifting to find qualified hires.
However, the implicit companion assumption that a resume with lots of clojure experience will have those skills is not something I've seen any evidence for. Many Clojure-focused candidates are unproductively dogmatic and are at risk of wasting everyone's time by trying to rearchitect our codebase because it doesn't meet their particular taste. In general, if a candidate is an adherent to a niche programming language they need to be able to explain to me when its use would be appropriate and inappropriate. If their answer is "this language and/or dogma is always better" then you're adorable but you need some more experience before I'm going to hire you.
It's also important to point out that, while my core requirements are the same for both jQuery and Clojurey candidates (ability to function in a large, complex codebase & ability to manage your own code's complexity), the specific skillsets are very different. Most clojure enthusiasts are actively bad front-end engineers. Which is fine! But many positions require engineers to at least be able to dabble in UI work, and if I get the sense that you would find it beneath you to do so, its probably going to mean better luck somewhere else unless I have a very specific position to fill.
I suspect type declaration order is a deeply personal preference. I hate C-style type-first declarations with a passion; type-last declarations have always felt more readable and natural to me.
- UI code spends most of its time interacting with a UI API (Android view framework, whatever iOS uses, DOM/CSS in web). These APIs are enormous and are rarely designed with testing in mind. Mocking or faking the pieces of API that you need to interact with is frequently a daunting or impossible task.
- Followup to the above: because so much of the "work" involved with UI code involves interacting with another API, usage of that API tends to spread itself through the entire codebase like cancer. You can create a careful separation of concerns, but it takes a lot of upfront work, verbose boilerplate code, and constant vigilance -- if you're just handed an existing UI codebase you won't have that luxury.
- UI code is highly stateful and highly mutable. A core skill in UI programming is managing your app's enormous state profile. Single-path, whole-world rendering techniques like React/other shadow DOM techniques really help here.
- UI is highly temporal. It needs to change over time. Testing anything to do with time is an enormous headache. Animations can force you to temporarily separate your underlying state from its representation, which is a testing nightmare. But just in general, writing unit tests that involve time passing is infuriating and fragile (even if you can control time passing via a mocked clock object).
- A lot of core functionality in UI involves different pieces handing off to each other -- one window transitions to another window, etc. To test that properly you need integration tests, but now your integration tests also need to interact with the underlying OS/browser (because you can't separate any of that stuff out). So your integration tests are in general way flakier than you can get on UI-less systems that really only need to worry about faking out a DB of some kind.
Reader mode exists on Chrome for Android, so this is most likely a feature that mainline Chrome hasn't gotten around to rather than some nefarious plan :)
Note that journalism has a more overloaded space than most when it comes to lead vs. lead, so I'm not surprised someone started using "lede" to mean specifically the one that sounds like LEED. "Leading", a common typographic term describing the space between lines, is pronounced the other way, like the element (and is in fact named for it).
On the contrary, silencing voices is a necessary thing. All societies have to determine what speech is allowed and what isn't. There are lots of things you can say in general American society that will get you censured. Claiming that black people are biologically inferior to white people, for example. Claiming that women are biologically inferior to men, though? Some still seem fond of that one.
This all boils down to the fact one group is trying to add a number of new entries to the list of censurable topics. It's fine to disagree with that, but then you have to state a) what topics you think shouldn't be added to the list and b). why. When people walk around loudly complaining about how they can't say anything anymore without being specific as to what they want to say, it suggests that perhaps they know that those positions are not really defensible.
[EDIT: To explain things a little more. Societies must limit some forms of speech because some speech limits who can be a member of a society. "We should murder all Asian people" is not compatible with a society that contains Asian people. And no, it is not fair to expect Asian people to have to constantly defend their humanity to others who have nothing to lose in the argument. Much as it's nice to think about abstractly entertaining every possible idea, when some of those ideas actively push out or dehumanize members, the society is forced to choose between accepting debate on the idea or excluding those members. So yes, if you want to complain about how SV society shuns people for not wanting to experiment on human embryos or whatever, go ahead. But assuming that all ideas should be up for debate is ignoring the fact that some ideas are incompatible with your fellow society members. And you get to choose between debating those ideas or having those people in your society as equals. You do have a choice, but you can't have both.]
Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.
If both studies are so flawed, it seems indefensible to draw _any_ conclusions right now.