HiJon89

I think they're saying you create your own malicious wifi network and people will unintentionally connect to it. This network specifies your malicious DNS server via DHCP, and everything looks secure to the client. I think the main issue with this in practice is that all the major browsers have been updated to not trust these certs.

> “Humans of course can drive with just eyes, so there’s that proof of existence,” he said. “If the goal were to just approximately match human performance or to build an assist product, that’s a very reasonable way to go.”

It feels like there's a lot of assumptions baked in here. For example, do humans get in accidents because eyes are insufficient driving sensors? Or because human drivers get tired, distracted, make mistakes, etc.

Also, you can put 10 cameras on a car looking in all directions at the same time, which feels materially different from a human that only has 2 eyes which can only look in a single direction at a time.

It's possible that massively superhuman driving performance can't be achieved with just cameras, but I'm not seeing a strong case for that being made here.

> Specifically, I think it would be perfectly cromulent to have JsonArray.of() be able to support any Iterable of native Strings, Integers, Doubles, or Booleans; that doesn't feel like feature creep to me at all.

What type would that method accept? Wouldn't it need to be Object? That seems worse than boilerplate

Using observed latency, power of two choices, and requests in flight reminds me a lot of Finagle https://twitter.github.io/finagle/guide/Clients.html#p2c-lea...

Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)

Really cool analysis and visualizations! Although there’s an interesting wrinkle with Mario Kart 8 + 200cc - most players don’t want speed over a certain level because you’re too fast to control. So rather than trying to maximize absolute speed stat you may want to minimize the delta from your optimal speed stat

My Plex lifetime pass is still going strong

> > Another common example is when you are implementing an interface method or overriding a superclass method

> This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.

I think this is already a risk when modifying interfaces or superclasses. For example, if you add a method to a superclass, a subclass might already have a method with the same name/arguments but different return type, which would break compilation.

A common example is try-with-resources where you don't actually need the resource and are just using it for the closing effect. For example, let's say you have a metrics library that allows you to time code blocks like so:

  try (Timer ignored = Metrics.newTimer("getOrders")) {
    return db.getOrders();
  }

Another common example is when you are implementing an interface method or overriding a superclass method, and your implementation doesn't need all the arguments. Would be great for the programmer to have a way to express this intent (to the compiler and to the reader)

This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.

One datapoint: searching our codebase for variables named "ignored" produces >1,000 hits. And probably an order of magnitude more unused variables that aren't named ignored.

What if your system is the one actually sending the emails (ie, you are the 3rd party in this scenario)

When do you record the message as processed? If you do it before the processing is complete, you have at-most-once delivery (because processing could fail after you've recorded it as processed, and it won't be retried). If you do it after the processing is complete, you have at-least-once delivery (because marking the message as processed could fail, and it will be retried).

What if the receiver process fails? How do you know which messages it processed successfully? You can shuffle the problem around indefinitely but it doesn’t go away.

If your processing doesn’t have any external side effects (make external API calls, send emails, charge credit cards, etc) then one option is to put your message queue in a relational DB alongside all your other data. Then you can pull a message, process it, write the results to the DB, and mark the message as processed all inside one big transaction. But not many use-cases can fit these constraints and it also has low throughout.

Thanks for making the previous poster’s point for them.

Thanks for the great writeup and the great work!

The fact that half the comments here are dismissive or condescending is such a sad indictment of HN culture :(

With 2 million users, I imagine it would be on the order of thousands of posts per day, and maybe hundreds of reports?

How would that work for something like S3 range requests? Rather than reading an entire object sequentially (which would work fine with transparent compression) you can also ask to read an arbitrary byte range (give me bytes 1,000,000,000-1,000,001,000 from the original file). I guess you could maybe store the compressed file in chunks with metadata about the original byte range inside each chunk.

There was a later tweet clarifying that an update (presumably over-the-air) was released in 2021 but for some reason not all devices received it.

Quote:

Now it seems an update was available and has been rolled out end of 2021. But many H5000 did not get that update and now, as the certificate has expired, this update cannot be installed in the usual way.

I expected the top comment on hackernews to be something this pedantic and irrelevant to the content, and I was not disappointed

  We don’t need to write a test that tests this function as a whole, we can test the parts we care about independently.

What could possibly go wrong :)

Limited driver assist? Are all the videos of people using Tesla full self-driving on YouTube fake?

Or maybe the sad state is that there are still people dying every day from a pandemic THAT WE HAVE A SAFE AND EFFECTIVE VACCINE FOR.

I had to read that sentence a couple of times but I think it’s just poorly worded. He’s not saying that the person is old, he’s saying that the reason for wanting to fire them “you are not doing a great job”, is a “plain old” reason

I think this misses the point, which is called out directly at the top of the site:

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency."

If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).

For some context, S3 used to provide read-after-write consistency on new objects, but only if you didn't do a GET or HEAD to the key before it was created. So this access pattern is all good:

  PUT new-key 200
  GET new-key 200

However, this access pattern would be unreliable:

  GET new-key 404
  PUT new-key 200
  GET new-key 200/404

This last GET could return a 200, or it could return a cached 404. Unfortunately, Maven uses this access pattern when publishing maven-metadata.xml files, because it needs to know whether it should update an existing maven-metadata.xml file or create one if it doesn't exist yet. So when publishing a new version, it does something like this:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200

And then downstream builds would try to resolve version 1.0-SNAPSHOT, and the first thing Maven does is fetch the maven-metadata.xml:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404

So when publishing a new version, you could get a cached 404 and fail loudly. However, when updating an existing maven-metadata.xml file you could silently read an old maven-metadata.xml, and end up using an out-of-date artifact (which is even more concerning). Here's what one of the maven-metadata.xml files looks like: https://oss.sonatype.org/content/repositories/snapshots/org/...

Because updating an existing object in S3 didn't have read-after-write consistency, we could have a publishing flow that looked like:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v2)

And then downstream builds would fetch the maven-metadata.xml:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)

So downstream builds could read a stale maven-metadata.xml file, which results in silently using an out-of-date artifact.

We ended up just switching to GCS because it was relatively straight-forward and gave us the consistency guarantees we want.

We used to use S3 for Maven artifact storage. This is mostly an append-only workload, however Maven updates maven-metadata.xml files in place. These files contain info about what versions exist, when they were updated, what the latest snapshot version is, etc. We would see issues where a Maven build publishes to S3, and then a downstream build would read an out-of-date maven-metadata.xml and blow up. Or worse, it could silently use an older build and cause a nasty surprise when you deploy. It only happened a small percentage of the time, but when you’re doing tens of thousands of builds per day it ends up happening every day.

We switched to GCS for our Maven artifacts and the problem went away.

Awesome, thanks for the response. Looking forward to trying out Sourcegraph again