mnarayan01

Speaking formally, we might consider a language to contain "redundancy" if there are source programs which produce the same compiled output; if they did it would be "redundant". Since all syntactically erroneous programs produce the same output (presumably none -- obviously I'm excluding e.g. diagnostic error messages here), a language which has more than one syntactically invalid program is redundant.

This might not seem all that useful in a practical sense, but I think that's basically the author's point: Such a language would be essentially impossible to write, and thus you're always going to have redundancy. As a result, you should evaluate redundancy in practical terms, rather than viewing it as always needing to be removed.

As others have noted, this is a little bizarre as the two functions are doing different things; one being less performant than the other is not really surprising. That said, there can be advantages to using array syntax rather than pointers for strings (even when also declaring the pointer to be constant), e.g. the compiler "knows" the array "pointer" is non-null:

  extern const char arr[];

  void do_arr() {
    if (arr) {
      dummy();
    }
  }

allows the compiler to optimize out the conditional: https://godbolt.org/g/FwBeWx.

I think the post is great, just that its not really clear what users need to do going forward (unsurprisingly; that should really be on nginx). In particular:

> Even pointing to a resolver on your internal local network may be a bad idea. Running a resolver on localhost is the only safe option.

In many cases, going to a localhost-only DNS is going to be way more complicated than getting off e.g. Google's open DNS, and thus conflating them likely means way more people giving up and sitting on untrusted DNS.

The POC seems to require some semi-esoteric stuff. In the absence of a more general exploit technique, it might be better to more explicitly say "these are configurations you should not use" than being as sweeping as this is (as for some configurations it does look super-frightening). From reading this, my impression is that there are two things people need to do:

1. Switch off untrusted DNS (e.g. Google's) regardless of any POC. Nginx views using these as insecure (fair enough), so they may decline to issue security advisories for any exploit that doing so allows (less fair).

2. In certain circumstances (1) is insufficient; the post details at least some of these. But you need to do (1) regardless.

The "simple" version leaves out an important bit from https://en.wikipedia.org/wiki/Zero-knowledge_proof:

> Peggy, being a very private person, does not want to reveal her knowledge (the secret word) to Victor or to reveal the fact of her knowledge to the world in general.

Without that, the example seems overly convoluted.

I totally missed it before your comment, but I think you're right, in particular:

> As with all IP, once created the value of a copy is pretty much zero. It's a simple case of supply and demand, the supply is infinite so logically the price is zero.

Read in a certain way (e.g. use of value vis–à–vis price), this is super Marxian.

  x + y * z

has way fewer than

  (+ x (* y z))

though. I'm not arguing for one or the other, but e.g. infix operators do have upsides.

The key is, I think, the "opinionated" part. Something like "how long should the DB statement timeout be" isn't really something people would have a general opinion on.

Also this stuff is all heavily Postgres specific; I think @nateberkopec's estimate of 300 gems is probably too low, even if you limit it to only say the top five most popular datastores.

I'm more talking about the exception behavior looking at e.g. https://wandbox.org/permlink/S5paK3Z9NpeCv3I0 (which exhibits the same bug). I mean you're right, and the fact that the User object is temporary should presumably not keep the first Resource destructor from firing, just it seems weird. I guess in my defense, apparently it seems weird to GCC as well.

If you assign the initialized value to a variable then you get the expected behavior: https://wandbox.org/permlink/r6csgR44BZBWudLV. What exactly is the defined destruction behavior for an object that's never (necessarily) on the stack? Or is it actually required to be on the stack in this case?

> That's also ignoring the fact that if the signal to a drone is lost, it's more than likely to fall out of the sky like a ton of bricks.

Consumer drones typically have well-defined and behaved signal loss behavior, which (for DJI ones at least) is even fairly configurable. Though quite often that behavior involves gaining a substantial amount of altitude (at least by default), which at an airport is actually probably worse than dropping.

Would it be possible to create a Ruby implementation of YAML which is compliant with the YAML v1.2 spec while also avoiding the more dangerous foot-guns? Sure. But the spec is simply a means to an end, and that end -- as per http://www.yaml.org/spec/1.2/spec.html -- is:

> In contrast, YAML's foremost design goals are human readability and support for serializing arbitrary native data structures.

In order to accomplish that goal in any sort of meaningful fashion, you need e.g. the !ruby tags. Hence my noting that the YAML format is not (generally) suitable for deserializing attacker controlled input.

Now here's the thing: You're totally right that the "core" functionality described in the YAML spec can be quite useful for more limited purposes, including possibly even safely deserializing and using attacker controlled input with only an intermediate amount of extra legwork. For better or worse, however, that's not the purpose that the people who designed and implemented YAML were going for. Too many people who comment on how various YAML APIs should be safer (for pragmatic reasons) ignore the truly awful (pragmatic) consequences of those comments when read by people who know far less than them.

I'm not trying to argue whether or not the API is well designed (the designers can do that if they so wish). My point is a pragmatic one: Saying the API lets you shoot yourself in the foot makes people believe that if they just use the right incantation everything will be fine and easy. YAML is just not that kind of format.

If I was designing the API today, I would name YAML::load something like YAML::unsafe_load because loading YAML is dangerous. Guiding naive users to a high-restricted subset of YAML is good. Making them think that they just need to avoid "easy foot-guns" is not.

For those confused by this comment, the actual title of the piece is: "This Hacker Is My New Hero".

> YAML.load(x) or YAML.parse(x).to_ruby

If you're working with attacker controlled input, at best you can avoid evals while deserializing. As soon as you use the result, a sufficiently clever and informed attacker can almost certainly own you. YAML is just too powerful for anything else.

If you're only using YAML as JSON with different syntax, that's a different story...but then you should just pass the library the deserialized data.

> It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all.

Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at least if it's e.g. purely positional to elide context related issues). The result of applying the patch would not be distributable, but I'd think the patch itself would be fine.

Pick two entries at random, and then choose the least recently used one.

I think you're mainly correct. The main issue is that there's an implied "given that the model from http://www.nature.com/ngeo/journal/v10/n2/full/ngeo2863.html is 'perfect' (at least for this case)". Since it seems unlikely that the model is perfect, the numbers they give are almost certainly inflated.

Most of the complaints about UB-based optimization that I've seen are from when the compiler uses UB to assume some type restraint that the programmer wishes it did not. E.g.:

  int v = *p;
  if (p == NULL) { /* ... */ }

The compiler uses UB to annotate the type information on p to indicate it's non-null, and then performs type-directed optimization.

> That is, before providing an explicit or institutional explanation for why individuals make prejudiced decisions, one must show that it was not a simple outcome of unthinking reproduction of statistical regularities absorbed with language.

This is an extraordinarily bold claim. I'd be quite interested in how peoples' responses to the article changed if this was the lead.

More in reference to the comments here than the actual article, but TODOs in the comments can be used to transmit what I find to be useful information: $THING was on the writer's radar, but $THING is not handled (correctly or not) in some non-obvious manner.

If your project uses them to indicate e.g. things that can not be merged into master, then obviously that's one thing, but when they're simply comments, the hate here seems misplaced. Other than (maybe) redis, I don't think I've ever seen code that did not have "potential things to do" that would have been nice to see commented.

JSON is a serialization format, just one that at least nods in the direction of human-readability. Formats which don't worry about human readability (e.g. Protobuf) can gain various degrees of efficiency.

> Like it or not, about 40,000 people a year are kicked off planes against their will. Some of them were standby passengers who knew this might happen.

Well at least we have numbers and pretty graphs.

First guess: The author is running into something related to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ....

He skips all the numbers where the hex-encoding has an A-F as the least significant digit. This makes everything bizarre.

> Uber has the authority to say to its employees, "If you have anything at home you bring it in here, give it to Mr. González, and he will turn it over to the Court."

So Uber says that to Levandowski, and he says "Sure, I'm an obedient employee, I'll give you the file if I have it. I don't have the file." Lying under oath is punishable by law (hence taking the 5th), but lying to your employer is (AFAIK) not.

Now if the judge is satisfied with that, then fair enough, but I doubt he would be. If he wants Uber to require that Levandowski not take the 5th as a condition of further employment he should just say so.

Looks like a nice library, though using a default of `*` for Origin seems like an invitation for people to shoot themselves in the foot.

It seems like this is simply a disassembler error (albeit an understandable one). Am I missing something?

Edit: Based on the responses below, I guess the point is that the disassembler can't generate Java code that will "naively" (wrong word, but I can't think of a better one) generate the same output. Notable (I assume) in that name munging would be problematic outside the current compilation unit.

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

  /(?=((?!exp).)*a.*)/ =~ "expba"
  # => 1

for me at least (using #match is also truthy, but the matched string is not what I'd guess the absent operator would give).