heavenlyhash

Right, so then we'll just have balanced power between everyone who can afford the AWS or other compute service bill do to the facial recognition matches against all those millions (and later, hundreds of millions, then billions) of records. That'll be...

Oh. Hm.

Maybe "privacy for everyone" is a better point to aim for.

The alternative seems to be no privacy as a baseline and then still results in an everybody-loses arms race to top it off.

That's a really excellent example -- crossing the regionality information of genomics with an otherwise-basic parallelization problem definitely makes it nontrivial. Thank you :D

Is it really so surprising that people continue to iterate and explore the space of possible DSLs -- literally, domain specific languages -- especially when people are solving problems from many different specific domains?

If you read NAMESPACES(7) and thought to yourself "that's a unified API", we have radically different definitions of "unified".

Oslo resident here.

Indeed.

Look also to:

- the near-universality of charger stations on streets, both in residential and commercial districts;

- the huge tax subsidies for buying and owning electric vehicles;

- the low cost of (clean, incidentally) electricity (I believe most of the charger posts in the city are free, though I should note I don't drive myself);

- the substantial tarrifs and fees for poluting vehicles in the city center areas (we're talking more than a cup of coffee's cost to enter ring 1, as well as lighter but still extant fees for the larger outer rings);

- as well as some air control days where vehicles with exhaust may be outright forbidden from operating in the city center entirely...

- and all of these pressures are being tuned up over time. It's widely-discussed and part of campaigns to make things greener. So people are not only responding to the current numbers, but considering the future.

This has everything to do with the society, its incentives, and how those incentives were rationally designed; and very, very little to do with a particular manufacturer and their marketing.

> Before signature verification I had extensions installed in Firefox that I didn't install

... How?

I agree with the sibling poster; it sounds like you already lost.

It's actually pretty good reporting. I'd give it a full read.

There's enough details dropped about experiment durations, species counts, and references to the techniques used to measure that if you've already got a background in the field, you can infer quite a lot; and if you don't, you can skip those details.

What good reporting should be, in other words: a summary valid for a wide audience.

So, can we as humans learn from history? Can we establish better, more thoughtful, and more balanced societies as time and our understanding progresses?

Or have we already built the pinnacle of society at some past point, and everything we ever do in the future is doomed to be as bad or worse than what we already have?

I'd like to choose optimism here, personally.

I found it interesting that the article mentions actors much at all for the same reason.

It's pretty trivial to construct actors out of some other message passing system. The interesting design choices in doing so are mostly down to the semantics in A) message passing, and B) scheduling/triggering/mapping-onto-green-threads/etc.

And for part A, all the other choices in the first three segments of the article are still effectively the choices that you've got to contend with: copying vs immutablity (bonus, COW mode, but still) vs ownership semantics.

Or to come at it from the other way: actors are far more featureful than is appropriate to directly compare to mere message passing semantics choices, because actors generally have some concept of error handling as a result of their relationship to scheduling, and that puts them on a whole different field.

I think the linked Rootkovska tweet (or more specifically, her own thread/replies to it) actually gracefully acknowledges that Xen is not magically free of attack surfaces.

She's also written some fairly long-form articles about Xen security and the (sometimes significant) room for improvement, including, for example, this Black Hat talk (from 2008!) about breaking Xen: https://invisiblethingslab.com/resources/bh08/part3.pdf

I don't disagree with the rest of your comment :) I just have the impression that any discussion about Qubes+Xen is less "dismissal" and more that supporting a variety of hypervisors is "a small matter of programming" (where "small" is used to mean "absolutely not small").

I didn't mean it as a call-out at all! :) I've had similar intuitions but been struggling to put a finger on it and wordsmith well on the topic. Thank you for writing!

And yes please do continue to write more, will eagerly read :)

Can you comment more about your comparative experiences with "logic bleed"?

I find this fascinating, because it seems that a lot of the bleed should be the same (isn't 'oneof' roughly equivalent to 'union'?)... but it sounds like something is different in practice, and I'd really like to understand what the root cause of the difference is.

You know, this might be a linguistic nit, and likely not a popular one to mention on HN, but...

I find it awfully odd to use the word "surpassing" to describe valuation, given that valuation is a number on paper. "Surpassing" is for something where there were expectations to exceed; or an arduous challenge overcome to the surprise of onlookers.

Valuation is an expectation; by definition it cannot be exceeded. While running a company is surely arduous, the most interesting challenge and the place to surpass expectations is not in the board room where the valuation is decided; and whether the math is massaged to offer a valuation a few decimal digits above or below a nice round $2B is more a foible of those in the room than any real indication of... anything.

Odd phrasing, to say "surpassing" here. It's numeric assignment.

> would implement the language in {foo}

If that choice becomes perceivable to anyone but the authors and maintainers of the language itself, I'd say that's a first class failing, isn't it?

The quality of a language should be a pure function of the language itself; the interpreter doesn't (or rather, shouldn't) enter into it.

Interesting.

Random observations in no particular order:

- The simple assignment syntax looks somewhat procedural and is easy to read in small hunks at a time, but is still functional. I like this. This meshes well with the very real limits of how the human brain can parse things.

- I wish there were type declarations. There's a type system, but it seems to be all inference. Type declarations just at the function inputs and outputs (and leaving it pure inference in the middle) would promote readability when you've got no compiler in hand and are just eyeballing the pure text, in my opinion.

- I'm surprised by the inclusion of a system of nonlocal returns (panic/recover). It still looks relatively functional, but A) boy that's not an area where the word "relatively" is comfortable to use and B) I shudder to think what the inferred types will tend to explode into when using this feature (an Either of an Either of an Either of a ...?) in a nontrivial program (and the examples don't really shed light on that either, due to the "all inference" model leaving us with no plain text declarations of types in sight).

- I haven't seen any examples yet of what happens and how you're supposed to resolve it when the type inference can't quite figure it out. There seem to be some examples of doing explicit casts which seems to be a workaround for this, but I don't see it discussed very clearly.

- The quick and easy syntax for returning new record/structure types seems nice. Though I'm again a tad worried that the range of types I could end up producing would get pretty large.

- The syntax holistically seems to keep things from "drifting to the right", which seems to be a common readability cramp that emerges in many functional languages. Nice.

- Using the term "Variety" for roughly "closure" is... very nonobvious to me. But I shouldn't nitpick on terminology. (And for what it's worth, I read the protobuf that Ko uses internally to define its types of types before anything else, and so maybe I'd be less surprised if I had encountered it from from the docs and lessons first.)

Caveat: these are all "hot takes" from the couple dozen minutes of digging I've done so far. I might be reading some things wrong or have missed some documentation, so take these comments with a grain of salt and do your own looking as well.

Overall, this seems neat, but simultaneously leaves me a little worried that I'd be able to too easily write things in which the type inference finds something that compiles, but isn't the type that I would've declared.

I'd be really interested to see what this shapes up like if combined with some system for explicit type declaration. Gluing Ko together with a serial data schema like Protobuf and using Ko for "migrations" seems like it could be a really useful combination, for example.

Grains are sold as a bulk commodity. The sale typically takes place at a "grain elevator" where the grain is dumped into a shared storage pool by the truckload.

I'm not sure how anything about brands could apply. Any "brand" ends at the grate where you dump the grain.

Similar with other ag products. Remember how we just had that E. Coli outbreak in lettuce and nobody had any idea for several days where exactly it came from, so they had to broadcast the warning across the entire nation?

If either of the first two propositions was true, then we should be able to look at other first world countries around the world that should be experiencing the same pressure, and we would see a similar slump in small business creation, right?

> require users to install applications manually without ensuring dependencies or pre/post installation configuration.

Yet my point is the converse of this: by not supporting those things, it means for something to be well packaged as a tarball, it may not have any external dependencies nor may it have pre/post installation hooks. And that's a Good Thing.

Because why would you need any of these things?

And how can you survive that level of complexity when the thing in question is itself the build tool which is traditionally the thing that we use to handle these complexities?

This may just be "my opinion", but I think my build tool should have packages available which have no further recursive dependencies -- the buck has to stop somewhere -- and it certainly shouldn't need post-install hooks for absolutely any purpose -- what would it use them for? Doing something stateful? That's antithetical to the core of what a good build tool should be doing.

I suspect a large amount of the issue is sheer availability.

There's an odd proclivity of developers of build tools to assume that their favorite runtime (be it python for scons, etc) is already available or trivial to nicely install. And that's just... not true.

The build tool itself is the one place in the ecosystem of building software that we have the least room for manual dependency handling and manual setup, because there's nowhere left to punt the hard part.

Make isn't better at this either, but it's been so widely packaged and is so nearly-default available (it's remarkably hard to get a working desktop system without some transitive dependency having gotten make installed for you) that it defacto gets a free pass on this.

My hypothesis is that these newer build tools would have a much better shot at reaching adoption if they were well-packaged enough that a single tarball (with zero external deps) or a single-line install script (think: "gradlew", though even that was cheating by assuming an existing jvm) could bootstrap them. Most don't seem to have invested that effort. And it shows.

... What?

Edit: Oh, your profile says " "obvious troll" ". Okay then. Checks out.

For the 1,000,000th time: you can't shout "fire" in a crowded theater and call it "satire" either.

I mean, "a fraction" is "half" in this case, which is actually pretty close to par in my mind. And that's what I pay for one address for a year; so if this is more addresses and more domains at better scaling prices, that's quite interesting.

This is really interesting...

... so I'm really a bit bewildered and sad by some of the engineering choices they made along the way, like requiring a modified kernel: https://github.com/oscarlab/betrfs/blob/master/README.md#com...

The reasons are detailed just above that link target, but are somewhat absurd IMHO: they modified the kernel's `struct task_struct` to pass error values, rather than fixing one of their libraries to handle its own error values. In return, nobody ever gets to use this without patching a kernel (which is, by the way, so ancient of a fork at this point that Forget It).

I know it's unfair of a random internetfolk to complain about the engineering choices of a project like this, I'm sure I don't know the influences and tradeoffs first hand, etc, etc, but... Ow. I would've tried this.

But not on a 3.11 kernel fork.

I hope someone can take all the awesome research here and get it to veer towards something slightly closer to product.

Those are just some assertions you made, most of which are considered "wrong" by experts who have spent time in this domain.

> cheaper

You realize we get to use volunteer labor here.

> more audit

That's broadly dissented unless you presume a given-by-god form of "done properly" and no-true-scotsman your way out of any constructive discussion.

> ability for voters to verify their vote

ALSO broadly dissented or at best extremely nontrivial. Blinded cryptographic operations are the territory you're talking about if you want to be in the ballpark of correct, and while the theory exists, the practice is again... not a given. I'm not even sure the theory is fully available for this domain.

Remember, one of the core concepts in a functional democracy is a secret ballot. This is essential to avoiding Some Very Nice People hovering just outside the polling place to make sure everyone in the area voted "correctly".

> From OP's calculation, a great school may cause at least $200K price increase per house

Say it with me: Correlation does not imply causation!

Correlation does not imply causation!

Correlation does not imply causation!

Correlation does not imply causation!

(And schools in the U.S. are funded largely by local property taxes. Therefore, the arrow of causation might very well go the opposite direction here: the places where homes are sold at higher prices are assessed at correspondingly higher taxes, and therefore those school districts get more money, and thus perhaps -- perhaps! Correlation does not imply causation! -- those more heavily funded schools are regarded as "better".)

> the options for phones with headphone jacks and no crapware preinstalled are exceedingly limited.

A thousand times this. The current market for phones is absolute crap. We need more competition. (And we also need at least some of that competition to quit playing "follow the leader" when the "leader" is an imagined title, and the "leader" is clearly blind and thrashing...)

Oh boy. If you and GP think there's a purely unregulated Laissez-faire market for dairy products in the U.S., you've got some fun reading to catchup on.

A sibling comment lower down the page provides some links: https://news.ycombinator.com/item?id=17996881

> turns out that if you are willing to pay more,

I don't think that actually refutes "peak oil" suggestions that there's a price curvature that's going to keep going up.

So since the majority of the voices here on HN seem to be pretty negative towards this, I think it's worth noting there are some creative voices who are in favor of some copyright law. For example, here's one fellow on the twitter machine who's a composer and seems pleased: https://twitter.com/Howard_Goodall/status/103983376226213478...

Simultaneously, I'm not campaigning in favor of the "link tax" component, here. I think it's widely agreed upon that that part of this proposal is pretty dire bunkum.

But let's not be eager to discard the baby and bathwater together. The idea of some EU copyright policy consensus is not inherently evil. If HN wants to rally about the "link tax" issue, do so. Don't jump directly to "boo, the EU is undemocratic because they didn't do what I want". That's just bizarre and we should be above that.

Sure.

Aaaand last airport I flew through had a wifi signup which required your phone number.

To send you an SMS.

With a code for the wifi.

So uh...

I'll continue to take my SMS notifications (and emails, which also have nice well-known offline sync properties...) over any more modern appy things, please and thank you.