dwc

The right comparison is with the distance at which this photo was taken: 18,000 miles, or about half an hour from closest approach.

Implicit in this statement: the camera was pointing close to the direction of travel and the target wasn't moving much within the field of view. Hugely easier than trying to image from the side at closest approach, which at best would have given a smeared image and at worst a complete miss.

It's still impressive and awesome. But always try to skew the odds of success in your favor when dealing with stuff like this. You have one pass and then the opportunity is gone.

Uniformity through imposing one paradigm on everything isn't attractive at all to me, especially for a paradigm I have no interest in using and avoid when I practically can.

the language isn’t CLOS all the way down

I'm curious what you mean by this, why it's needed or would be a good thing, etc. As a multi-paradigm language, I'm not seeing why CL should have a particular paradigm "all the way down".

And 10 years later, sharing stuff with people nearby still kinda sucks.

It does still suck, and once every few years I feel that. But that's a problem. Solving a minor, "kinda" pain point that people experience once in a while isn't that big of a win. I'm sure that other people want to do this more often than I do, but I'm also sure that this case is a small subset of the need to share stuff with others generally. I.e., you're always needing to share stuff, with people in Boston, LA, or Singapore, or your manager on another floor of the building, or wherever. You know how to do that. So while it seems silly that you can't share something more easily with someone sitting across the table from you, the methods you already use do work.

Phoenix AZ area.

I grow blue java bananas in my yard. Rajapuri bananas are fairly popular around here.

It's unfortunate how much Google-hate is on HN these days because I think it's largely unjustified. There are definitely some bad (IMHO) leadership decisions but the rank-and-file are still culture carriers for a lot of the things that made Google great.

The fairly small number of people I know who are Googlers or Xooglers are all pretty awesome as techies and as people. That does little to change my opinion of Google itself. Sometimes it makes me even more cynical, thinking that management might take special care in internal messaging lest the rank-and-file revolt.

But from my perspective, from the outside, what Google does as a company is what counts for me and for society. All the good people inside don't ameliorate the external behavior of the company.

A trusted network is fine, but are the telephone networks trusted?

In the old days there was an assumption that if you were in the network then you were trusted, which was always dicey but made more sense when Ma Bell controlled everything tightly. Since the monopoly breakup that model was no longer true, and many problems can trace back to the nature of back patching security onto an entirely different model that no longer fits reality.

Note on above: there are legitimate reasons for businesses to set Caller ID to something other than the call origin. But the "something other" should be selected from a set under the control of the business, not a free for all. I.e., a desk phone with DID may show as the main company number, etc.

This takes a little more work to account for, but it shouldn't be a roadblock.

Spoofed Caller ID is a lie, not anonymity.

Here's a proposal: 1) Caller may choose to hide/suppress their Caller ID, 2) mandatory option for phone carriers to allow Callee to completely block calls (no ring, no voicemail) that don't carry Caller ID, 3) When present Caller ID must be accurate.

The above allows anonymity but disallows deceit. It also provides opt-out for people not to receive anonymous calls. (Anonymity does not give you the right to have any given individual listen to you)

We could have had this for ages, as there are no great technical hurdles.

You start by saying that too much is blamed on leadership and then go on to describe the real reason which is a failure in leadership?

FWIW, I largely agree about the "cogs" idea. One particularly frustrating thing is seeing repeated failures and management fails to consult with workers about how it happened. Seeing the repeated problems the workers volunteer their insights to management about the underlying problems and possible solutions. But that info is either discarded (after "careful consideration") or warped to fit an existing but incorrect management narrative. The very idea that people doing the work could contribute anything meaningful beyond estimates doesn't seem to be palatable.

One question I have is how sequestered the undersea carbon really is

Depends on how you interpret "sequestered". In the sense that it's locked away somewhere for a long time, like organic matter frozen into tundra, it's not very sequestered. But as long as there's lots of seaweed there'll be a lot of carbon taken up. Even though individual plants may die and release their carbon on a relatively short timeline, new growth will take up carbon.

Yes, correctness absolutely comes first.

One way to achieve greater simplicity is to negotiate for fewer/simpler requirements for the first revision. There's often a core set of functionality that can be implemented correctly in a simpler way, and that gets the work done. Once that's in place it's interesting to see how often people lose interest in what were "hard" requirements before. It's also common that new asks have little to no resemblance to those unimplemented features, and are instead things that they found out they needed after using the new system.

I like and use early exits when they fit well, which is often. And in this case I'd probably do as you suggest. But it's worth mentioning that even if you stick with if/else it's often worth it to put the simple case first to reduce mental load:

    if cache.contains(key) {
      return cache.get(key)
    } else {    
      v = db.query("..")
      expiry = calcexpiry(v)
      cache.put(k, v, expiry)
      return v;
    }

They would make forks ;)

The fight really being had here is "warrant Vs. routine monitoring."

Exactly right.

That's what law enforcement want from this: If you know someone that knows someone that might have committed a crime, they want to invade your privacy "just in case."

It's worse. While they will say that's what they want (and they do want that), what they really want is to look at anyone at any time for any reason. Say, if you tweet something disparaging about police they'd love to be able to look at your info without asking anyone, to see if they can find something on you.

"The trailer for Cyberpunk 2077 strikes me as GTA skinned-over with a generic 80s retro-future, but hey, that's just me." --William Gibson[1]

It's mentioned (and little more) in the article at the end, but it still seems odd to invoke Gibson's name and not talk about this more.

1. https://twitter.com/GreatDismal/status/1005958197654351872

The rise of the iPhone explains a LOT about where Apple puts their attention. What it doesn't really explain is why the changes they do make to Mac products seem designed to annoy. Since they're not upgrading the processors couldn't they just leave things completely alone and keep selling the old models? I'm not sure they'd take any more heat for that than they do for dropping connectors and such.

It's worth noting that strlcpy and strlcat are quite small, very stable, and can be brought into any program that needs them. Yes, it's an extra step but not an onerous one. Of course it's nice to autoconf them if practical.

The money in (real) UBI comes from somewhere, obviously. It's not like everyone just has more money. If you can already afford the basics then it's going to come out of your money in taxes to a greater or lesser degree. So for people in a normal middle income range you pay and then get the money back. Higher income people would pay more and get back the same as you. Low income people would pay little or nothing and get the same back as you.

How that actually plays out in a market like ours hasn't (can't) been fully tested, but it seems a promising idea.

time with timezone without a date attached to it is inherently ambiguous

I'd view that as incomplete (rather than ambiguous) until applied to a specific date. "You people in the Hawaii office feel free to join the Boston 2PM call whenever you want" is a fine thing to say even though you don't know what the Hawaii time will be until you know the date.

the arrangement has become more and more one sided favoring the publishers

Rather than "has become" this is publishers using their leverage to achieve this situation.

There is a package for every possible problem you have just waiting to be used.

Only if you work on the same kinds of things everyone else works on. There are certainly tons of jobs that qualify in that regard.

For other kinds of work there aren't packages that cover needed functionality, because either there wouldn't be many consumers of a package or the functionality is actually new. This is where I've found myself over the last couple of decades and I like it better, personally.

I imagine that researchers designed the experiment they thought would be accepted rather than the experiment they wanted. Yes, they intended to learn some things and most likely did.

Hi! Developer working in C here. I'm neither a kernel dev nor an embedded dev.

My current job is network programming on the core product of my employer. It's "legacy" in the sense that it's been around a long time but it's actively developed and continually extended to meet rapidly evolving customer needs.

I also wrote C in my previous job doing non-flight software for a space mission, analyzing telemetry, processing image data, automated planning of camera targeting, etc. Much other work was done in scripting languages, and when those weren't performant enough for the task then I wrote C libraries to do the heavy lifting for them to interface with.

You don't live in a bubble. There are whole segments of the software industry where you'll never see C developers, and there are many companies where you C could (should?) be used but isn't because it's unhip and old. Software development these days is pretty fragmented and there's a tendency for people to think that their experience describes everything, but it's not the case.

I believe that the latter is a better option, when it's available.

Expanding on an aspect of that...

Usually portability, along with many other such things, should be considered as a higher level goal. Decide on the portability requirements and then pick the best options within constraints. This varies wildly between projects! The same dev team may come to different decisions on various projects.

Much of your response seems to orbit around the utility function, which is the devilishly tricky part from the start. Getting that part right is much more important than a specific level of intelligence.

I find your response interesting. Thank you.

I think that the nature of the context can vary a lot. Some art speaks to people on a primal level, and the context is shared human experience. Other art needs more shared cultural context. Then there's art that requires the context of the artist's life to really move you.

In short, I concede your point that context matters. I think it can and does vary quite a bit.

I still don't want to conflate works requiring the context of knowing and understanding the artist with thinking a work is deep because the artist is well regarded.

This is why I mention that there are specific cases for subhuman levels of intelligence.

Pretty much every conception of AGI is of greater than human intelligence, at least in some aspects.

The reason? Otherwise why build it? Yes, there are cases where AGI as subhuman-level intelligence would have utility, but the remaining cases are far more numerous and have far more utility.