dataflow

> One other suggestion I have is just buying a longer cable than you think you need because eventually you'll have the need for it anyway.

This only works with cables that bend easily. For something stiff/sensitive like high speed USB4 I found it more problematic than helpful.

What marker do you use to mark them? Is the ink durable and easy to read?

That sounds hard. Is a USB-A-to-C cable in the A group or C group or neither? What about the inverse? What about cables that only do data but can't transmit enough power? What about cables that are slow but high power? What about thick cables like USB4 that barely bend or fit in the bag? What about male-to-female vs. male-to-male? What about brand-specific cables that have their own abilities (say, high-powered but not PD)? The list goes on and on...

I think I hardly have any pairs of cables that are similar enough to be interchangeable, and at this point most of them are USB-C, so they'd all mostly end up in the same bag if that's the criterion.

I suspect the fundamental problem here is it's hard (if not impossible) to determine if someone who tried the winning approach deserves the credit for the discovery, because there's always the chance that they could've done something differently, or stopped before finishing, and thus never actually made the discovery. They might've even tried the approach just based on a whim, without really thinking it would work, and might've given up without a final insight. And fundings run out, people end up in hospitals, etc. What do you credit them with when the work isn't finished? For trying an approach that sounded promising? You can do that I guess, but is that what they want?

Has anyone else seen this happen? I checked and my setting is still off.

> Rather than this being too good at solving this class of problem, it seems to me that zero-initialization is the wrong approach

That's exactly why I wrote this here:

>> I'm obviously not saying we should write unsafe code or that we shouldn't try to eliminate entire classes of bugs, but that HOW we do it matters.

After you get past the hurdle of noticing this problem (which, as you saw, is very much not obvious), the harder question becomes: what is the right approach?

In this particular case it's not too hard to think of a better approach once you concede the obvious solution isn't so great, but in other cases it is, and often the better alternatives put some kind of selection pressure too... just less frequently. And even in this case, it's not at all obvious that this approach is bad - plenty of people think it's better to force a default value you can rely on, and they want to remove undefined behavior from C++ by forcing initialization on everything. For longstanding examples elsewhere, just look at how Java and C# initialize fields, for example.

Outside of programming it's even harder to notice and find a better alternative, but selection pressure has these kinds of effects in other areas too.

Here's a trivial example to illustrate:

  class User {
    explicit User(const char* name) {
      if (!look_up_uid(&uid, name)) {
       abort();
     }
    }

    bool is_root() const {
      return uid == 0;
    }

    int uid;
  };

Let's say look_up_uid() forgot to fill in uid for certain special kinds of users. Like maybe you have a dummy 'nobody' user that was introduced specially after the fact and which is not in the database like the rest.

As C++ is right now, uid would contain garbage. Which means that, at run time, you would often get invalid UIDs if you attempted to log in with such a user, triggering some logging or reporting you to Santa or whatever. And which means that sanitizers would immediately tell you that you forgot to initalialize the field if you ever try to use it (say, in is_root()). Both of these would flag the bug the moment that that kind of user attempts to log in, and make you dig into look_up_uid()'s body to figure out why it's not returning the UID when it's supposed to.

However, if C++ were to zero-initialize everything by default, then neither of those would be true - you would silently get a root user, which is capable of doing everything that nobody can do. And someone who reads the code wouldn't immediately know that you have such a bug; it would sit there idly until someone exploits it.

> But in practice so far, this doesn't end vulnerabilities, it just leads to a bunch of new and more exciting ones.

I kind of wish you wrote "potentially worse" rather than "exciting", because that happens too, and it's deceptively subtle and underappreciated.

To make this very concrete with a programming example, C and C++ are (somewhat counterintuitively) examples here, because if you guaranteed the absence of an entire classes of vulnerabilities - say, guaranteeing that uninitialized memory is zero, to prevent secret leaks - then you simultaneously make it much harder to detect logic bugs that this would've surfaced, since you no longer have that degree of freedom to detect logic bugs (say, via sanitizers). Say, an initialized UID that would've appeared as 0xDEADBEEF might now be well-defined as UID 0, giving you root access instead of tripping an alarm...

In other words, it's like natural selection and antibiotics: being too good at solving one class of problems selects for other classes that are more resilient and harder to find, whereas in some of those cases, whack-a-mole would've actually uncovered the root cause. Like with antibiotics, that's sometimes worth it, but definitely not always! Some infections just aren't worth preventing at all costs.

I'm obviously not saying we should write unsafe code or that we shouldn't try to eliminate entire classes of bugs, but that HOW we do it matters. We don't want to end up in a situation where problems still lurk but we push their detection beyond our ability because of the way we "solved" other problems.

(C++ was just for illustration here; this extends far beyond programming.)

Is blockchain going to finally be the solution to something?

I'm only half joking. Should researchers perhaps put hashes of their attempts on a public blockchain tied to their own public keys, verify their claims asynchronously, and then whoever reveals the first believable attempt gets the credit?

I know some people started doing this years ago but now it might need to become standard practice.

Wouldn't using a neighbor's Wi-Fi without anyone's permission or instruction violate CFAA or some other law?

Also, wouldn't this be trivial to test by just setting up your own network and seeing if the TV connects?

Why don't they use the Mollweide projection instead?

Perhaps they're hoping to get significant market share before they lose the opportunity for good?

You don't seem to believe that something like generational wealth makes much of a difference?

It sounds insultingly low, yeah. I'm trying to imagine why they would pay so little. The only two reasons I can think of are either (a) they were already aware of it and fixing it, and therefore the report didn't really change much, or (b) it requires an unusual configuration or otherwise rare opportunity to that makes it impractical to exploit most users. Really curious to see what the issue was whenever it gets made public.

Neither I nor you should appreciate spreading unsubstantiated rumors that directly attack the public servants neither of us personally know. If it bothers you that I'm defending them, then perhaps don't launch your attacks on them until you can share solid evidence that directly supports your claims. They're not going to be the ones defending themselves here and neither are you, and surely you don't expect us to accept whatever we read as true with zero evidence. Otherwise you're just spreading rumors. You owe it to the people you're talking to to justify any distrust that you're sowing.

And no, I'm not here to "own" anyone, whether left or right or up or down. I'm here to figure out what is true and what is false, and what is a rumor. Hence my question. If you had actually provided solid evidence for your claims in the beginning, I would have spread your words in support of your cause. I don't want innocent people being harmed any more than you do, whether they're wearing ankle monitors or robes.

What alternative solutions would people who use a lot of aliases at their own domain name suggest?

I'm similarly confused/upset, but it really does sound like they're discontinuing sending via SMTP:

> The “Send as” feature will no longer be available. This feature allows you to send email from a third-party address, such as @hotmail.com, @yahoo.com, and others, using your primary Gmail account.

https://support.google.com/mail/answer/17101213?sjid=2314716...

I don't understand, sorry. How does declaring an optional dependency in a toml file solve the problem of accessing the symbol in your code?

Also, you need something that works for simple one-file scripts, not just a whole package or project.

Thanks for the feedback, but I think you're missing something. This is not about us, it's about everything and everyone else implicated in the discussion. About the fact that we're essentially being demanded to assume - without clear evidence - that the vast majority of those with power over us are categorically incredibly incompetent or malicious. That is not only incredibly insulting toward the good subset of humans who have dedicated and even risked their lives for the public good, but it goes further and sows deep distrust and resentment, continuing to tear apart the very fabric of society. If you/we want to do that, be my guest. It is HN after all. But we damn better be able to justify it with rock-solid evidence, not just go "trust me bro, they're all stupid, they're not techies like us."

Throughout this entire chain of comments, there has not been one shred of evidence that this has actually even happened once, never mind that it is a repeating phenomenon as they claimed. All we have been given is repeated attempts to make us believe those claims were true, supported by claims of existence of (not actual) evidence that - even if existent - would not remotely imply the claim is true. If we want to believe things without evidence and damn other who disagree to hell based purely on beliefs, we certainly can - that's what freedom of religion is for. However, I hope the irony isn't lost on anyone that it's quite literally the diametric opposite of what we're expecting from the justice system.

Whether the claim is ultimately accurate or not, that is what what should be spoiling your day before anything I wrote. It certainly did mine. It should absolutely spoil your day to watch the integrity of huge swathes of people running your society get smeared without clear evidence, with more nails being hammered into the coffin that is the trust holding your society together. Either you're watching something unjustified, in which case that should make you upset on its own, or it's justified, in which case it's even sadder. Either way, I would think that seeing evidence should be at the bedrock of it all, not the last straw whose demand finally spoils your day.

It's not clear such a thing even exists in general though. It's certainly not guaranteed by packages.

What would that be for numba?

Okay thanks, so here's what I don't understand. When there is video evidence that someone was in their house the whole time, and given that everyone who has used a GPS knows it can easily be inaccurate by 30ft, why in the world would the judge trust the ankle monitor accuracy over video footage they see with their own eyes that directly contradicts it?

Something about this just doesn't seem very plausible, especially if this kind of thing is happening more than once in a blue moon. Either the video evidence is not as convincing as we're being led to assume (thus leaving more doubt in the judge's mind than ours, even if the person is innocent), or there should be some other explanation.

> To answer your question

Looking forward!

> motions by prosecutors

Motion ≠ incarceration. So, not an answer (yet?)...

Did defendants get incarcerated as a result of these motions, or no?

Thank you!

What is the right way to handle an optional dependency?

Do you have any examples of someone getting thrown behind bars due to a GPS error on the order of ~30ft like you're claiming? That's all I'm asking. Really don't understand why you keep avoiding it. You've essentially claimed police/judges are doing something rather stupid and terrible. I'm asking you to show example(s) of what you claimed (~30ft error → thrown behind bars), not something significantly different (~1+ mi error → only-police-visit-but-not-thrown-behind-bars).

You're claiming that erroneously reported movements by ~33 ft lead to incarceration, yet the article you're linking to reports that erroneously reported movements by ~1mi+ lead to police coming to double-check what's going on. Am I incorrect and do you therefore have examples of ~30ft errors actually leading to their incarceration, or are you struggling to see the disconnect between what you're claiming vs. what is actually happening?

> This pattern, for example, can’t be lazy: try: import numpy; except ModuleNotFoundError: ...

Wait, that seems bad. These kinds of modules (especially numba) are often exactly the ones that you want to delay importing. Why not provide a way to check the existence at import time? How are you supposed to handle nonexistence in that case?

> This

As in, GPS being off by 33 feet?

> leads to people getting reincarcerated

I'm reading your article and it seems to be about police coming to check and realizing that the reporting of being miles away was in error, not people getting reincarcerted because of GPS incorrectly reporting they moved ~30 feet too far? One of these is much more insane than the other.

> So its fine that they force you to agree to something when you paid for it but its not fine when they do the thing you agreed too?

Two things can be both "not fine" but one can still be worse than the other.

What was their rationale for doing nothing?