thinkmoore

The political appointees pushing this new policy have not presented any evidence of these deaths beyond a vague assertion in a leaked internal email. They have not provided that evidence to career staffers either.

Recalls happen because they are required by regulators...

Also discussed here (but flagged, of course...): https://news.ycombinator.com/item?id=43691142

Yes, that's a good way to think of it---we need to come up with a valid / reasonable context in which to explore the function at all, which will subsequently let us look for other bugs (like the divide by zero in the blog post).

Part 1: https://galois.com/blog/2022/08/cclyzer/

Developer here: "not actively developed" might be a little strong---we currently don't have resources dedicated to quickly responding to issues, but we're not planning on abandoning it.

Various components of the SGX system (launch approval, remote attestation quote signing, etc) are implemented as Intel provided enclaves. AESM manages those enclaves and provides an untrusted API to communicate with them.

Who is "you"? From the terms of service:

"Absent a reasonable legal justification not to redeem Tether Tokens, and provided that you are a fully verified customer of Tether, your Tether Tokens are freely redeemable... Furthermore, residents of certain U.S. states are not permitted to be customers of Tether; are not permitted to cause Tethers to be issued or redeemed; and, are not permitted to hold Tether Tokens. Beginning on January 1, 2018, Tether Tokens will no longer be issued to U.S. Persons."

So if you hold Tether Tokens but are not a "customer", you have no claim to be paid. I suppose Tether customers (whoever they may be) might be willing to pay you dollars for your coins, but there's no reason for them to give you 1:1, for sure.

My understanding is that their terms of service say that they have no legal obligation to do so, regardless of where you have a bank account...

There is some very cool language design work from Chinawat Isradisaikul and Andrew C. Myers at Cornell on adding very powerful matching constructs to a Java-like language.

Paper: http://www.cs.cornell.edu/~chinawat/papers/pldi13-p343-israd... Slides: http://www.cs.cornell.edu/~chinawat/papers/chin-pldi13-slide...

Database choice aside, I'm shocked that this wasn't noticed when designing the app... It's clearly not a design decision because they refer to it as an error later in the paragraph.

Coming soon to an insurance broker near you: https://www.newsroom.co.nz/@health--science/2017/04/04/17972...

Of course, this article is about New Zealand, but I will not be surprised to see similar things in the States. Thankfully ACA provides protection for health insurance, but we're already seeing things like https://www.congress.gov/bill/115th-congress/house-bill/1313.

Oh neat, do you have a list of those? /sarcasm...

I think the alternative being suggested is that rm shouldn't accept a string that magically can reference anything in the filesystem...

In our capability-based shell scripting language Shill (shill-lang.org) for example, you could prevent this sort of bug by giving the script a capability for just the diaspora_home directory, and deriving the child directories from that capability. (Of course, you still need to make sure you pass in the right directory in the first place.)

I (with some colleagues) developed a capability-based shell scripting language (http://shill-lang.org) that makes it easier to apply the Principle of Least Privilege to system administration tasks and also functions as a modular, programmable sandbox.

We're currently working on a port to Linux and a commercial version. If you're intrigued, I'd love to chat.

There is some great existing work in the academic community on better models for web interactions: https://cs.brown.edu/~sk/Publications/Papers/Published/mk-in...

In a Typed Racket program that does not import any untyped racket code, there is no runtime enforcement. Runtime contracts are only introduced at the boundary between typed and untyped code. This allows programs to be soundly transitioned from untyped to partially typed to fully typed.

Well, for one, that he chose to say "will be taken away" when responding to this criticism, instead of "should be taken away," implying that he thinks they ought to be taken away (because it would allow for his libertarian utopia) but that it won't happen for other reasons.

Uh, we are paying it back? Why would any sensible household or business pass on ~1% APR loans to fund investment?

Our interest payments are less than 1.5% of GDP (down from 3% of GDP a decade or so ago).

People always whine about not running government like a business...

This is among the many use cases we're hoping to solve with our secure shell scripting language Shill (http://shill.seas.harvard.edu/).

We're currently working on a commercial version of Shill targeting Linux. If Shill sounds like a product your company wishes it could find, we'd love to hear from you. Shoot me an email at sdmoore@fas.harvard.edu.

"High risk, no-income." Really? Section 8 supports the working poor. You need to check your prejudices against reality.

How many prolog programmers does it take to change a lightbulb?

No.

You might be interested in checking out Habitat from Chef, which uses many similar ideas: habitat.sh

I think the idea of releasing a vehicle safety system that you apparently have little enough faith in to call a "beta," and marketing said system under the name "Autopilot" and then acting surprised when people treat it as a reliable autonomous control system are pretty cavalier. I was also referring to the attitude (evident in this thread) that since there was a warning it is completely the drivers fault. I certainly think this technology will improve safety. But we should certainly consider what role the technology itself played in accidents---whether because driver's aren't using it as intended or it has a design defect (no sensing at windscreen height).

I get the sense that a lot of people feel like since the intent is good and driver's are opting in that basically anything goes---which seems pretty cavalier to me.

While I agree some of the early arguments are a bit weak, I liked the author's discussion of the parallels to medical research---I think it gets across why some (including myself) think its worth approaching this exciting new technology with a slightly less cavalier attitude:

In developing cancer drugs that could save millions of lives—just like robot cars are promised to do—we understand we can’t ignore problems in clinical and human trials. We can’t cut corners just because we want to rush a life-saving product to market.

“The perfect is the enemy of the good,” as famously declared by Voltaire, is also a common reaction to ethical critiques of autonomous cars. But this is a straw-man argument: no one is demanding perfection, just due diligence, especially if death is on the line. Just as with cancer drugs or anything else on the market, a product doesn’t have to be perfect, though that’s not an excuse to not be more careful.

Look at seatbelts as an iconic safety device: even they aren’t absolved of all sins, just because they save a lot of lives overall. Unlatch buttons that are too large (and can be accidentally bumped open) or too easily opened have sparked lawsuits and massive recalls. These aren’t really malfunctions but only bad designs, and bad designs can kill.

The extra care needed to avoid these problems doesn’t have to take a Herculean effort or stall research and development. It just means investing some time to think it through and properly set expectations. This could save lives, and every one counts. (Just ask their families.)

Does anyone else find the first chart in this post ominous? 2014-2015 is looking a lot like 1999-2000, and nothing seems to suggest things are that different this time around...

As part of my PhD research, I developed a shell scripting language (shill-lang.org, previously on hn: https://news.ycombinator.com/item?id=9328277) with features that provide safety belts against this sort of error. From speaking to administrators and developers, we believe these types of errors cause take much more worry and time than they are worth.

Now that I'm graduating, we've started the process of refining Shill into a product that we can offer to administrators and developers to make their lives simpler. If this sounds like a tool you wish you had (or if you wish a similar tool existed for your platform of choice), we'd love to hear from you.

Okay, my last try.

For Bayes' theorem, we need a theory of how the data is produced given the parameter of interest. Bill and Lorena's plans certainly influence what data I observe: in scenario two, I can never observe the data BBBBGGG, but in scenario one, I can. My point is that your first category is not "exact statements about the likelihood of 7 births in a row being mmmmmmmf", it is "exact statements about the likelihood of observing mmmmmmf", which is, in fact, quite different, if you admit the possibility of Bill and Lorena having particular childbearing plans.

1 and 3 are really the same thing. If the complaint is that the frequentist test can't tell you anything if the assumed distribution wasn't the right one (which is what's happening if you would have done something different), consider the bayesian case. There one might argue you at least still have the probability of each hypothesis given the data. But that forgets that it is only the probability of each hypothesis given the data, given that those were the only possible hypotheses. And if you admit the possibility of their being other possible hypotheses, then these probabilities don't really tell you anything either.

Anyway, not sure if we're on the same page, but thanks for the discussion.

Right, but this is exactly my point: the correct answer depends on the set of prior theories, which is exactly what the frequentist scenarios you consider are varying.