ender7

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 returns

Just 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 :)

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.