skysight-inc/HackerNews huggingface dataset:
Almost anything by James P. Hogan -- one of the best hard sci-fi writers as he trained as an electrical and computer engineer (including about AI like "The Two Faces of Tomorrow" from 1979 and still a good read as it was informed by talking to Marvin Minsky at the MIT AI lab): http://www.jamesphogan.com/biblio/novels.php

Most of his sci-fi is from the late 1970s through the early 2000s.

I especially like his Voyage From Yesteryear from 1982:
http://www.jamesphogan.com/books/info.php?titleID=29&cmd=sum...
"The fun begins when a generation ship housing a population of thousands arrives to "reclaim" the colony on behalf of the repressive, authoritarian regime that emerged following the crisis period. The Mayflower II brings with it all the tried and tested apparatus for bringing a recalcitrant population to heel: authority, with its power structure and symbolism, to impress; commercial institutions with the promise of wealth and possessions, to tempt and ensnare; a religious presence, to awe and instill duty and obedience; and if all else fails, armed military force to compel. But what happens when these methods encounter a population that has never been conditioned to respond? ...
The book has an interesting corollary. Around about the mid eighties, I received a letter notifying me that the story had been serialized in an underground Polish s.f. magazine. They hadn't exactly "stolen" it, the publishers explained, but had credited zlotys to an account in my name there, so if I ever decided to take a holiday in Poland the expenses would be covered (there was no exchange mechanism with Western currencies at that time). Then the story started surfacing in other countries of Eastern Europe, by all accounts to an enthusiastic reception. What they liked there, apparently, was the updated "Ghandiesque" formula on how bring down an oppressive regime when it's got all the guns. And a couple of years later, they were all doing it!"
You seem to be just playing with semantics and claiming it offers a new way of thinking about I/O.
Hmm, FYI, I seem to have broken it a little bit: https://i.imgur.com/qrNeZFJ.png
Andy Weir's "The Martian" is my favourite book. I've read it about 5 times, and I've never read a book twice before. The movie was a decent adaptation, but it's not near the quality that the book was.
34C3: Call for Participation and Submission Guidelines
> even the drug-pusher-like "Community" (first hit is free, unless/until you're making money) edition.

I mean, yeah it's not free-for-all, but "first hit is free" is kind of unfair. A company is not allowed to use it if they have more than "(a) more than 250 PCs or users or (b) one million U.S. dollars... in annual revenues" [1], and if it doesn't meet that criteria, it's usage is limited to 5 concurrent instances. More accurate would be "first hits are free, and you won't start getting charged until you're big enough where you can afford it".

Just making the distinction because I still have friends who think they can't use Community at home if they want to have a side project that makes money.

[1]: https://www.visualstudio.com/license-terms/mlt553321/
It would be useful more as a tool to help migrate away from e-paper workflows, i.e. emailing PDF scans of legacy paper forms, and towards smarter architectures.

For example: suppose a customer with a workflow where the customer fills out a PDF form and emails the completed PDF to an externality (e.g. supplier, other department whose workflow they can't control, etc.). So you build a modern UX that uses the PDF API to fill out the PDF with the data from the UI, and then email the PDF to the externality, just like before, so that they're on-board with the new UX (since it doesn't affect them at all).

Once you build the new UX, you can then sit with your externality and figure out what they need in order to hook into the modern system. After all, they benefit from a single queryable source of truth, just like anybody else, and the customer is generating that source of truth when they put their info into the UI which ultimately emails the PDF. Once you build the UX for the externality, there's no need to retrain your original customers - they can keep using the modern UX you built for them before. All you have to do is update internally to make sure you're updating the sources the externality's UX expects, stop using the PDF API and emailing the results, and your migration is finished in a pretty simple way that is transparent to the customer.
> By the way, one reason people react strongly to objections like yours is that a very direct interpretation is that you believe the distribution of people in high status jobs actually does accurately reflect differences based on race and gender.

I think this is partly true. But then, a similar interpretation of "pro-affirmative action" is that one believes that whatever bad thing happens to a minority is never their fault.

I think both are only partly true.

The problem with affirmative action is that it (I don't know if it's always the case, but it seems to be often so) specifically considers minority status. It is obvious, I think, that this is not the kind of criteria a computer, say, would consider if it were to look only for the most qualified applicants.

On the other hand, you or someone else in the thread made a good point: this pro-minority bias can be seen as an effort to counter the systematic bias against "outgroups".

The problem is that I don't think we know the effect size of each of those: how strong is this systematic bias? In a protected status agnostic society, would all professional fields perfectly mirror population rates?

I don't think so. We know there are metal disorders/illnesses that impact cognitive functions (Down's syndrome) and obviously genetics is partly responsible (do Down syndromers have similar rates of Down syndrome babies?). Similarly, I don't think the success of Asians and Jews is due to some form of societal bias in their favor.

In the end, the question is whether the anti-bias bias is correcting towards 0 or in the other direction (i.e.: protected status is very important, just the other way).

I don't know what the answer to this one is.
I'm actually midway through this book and I definitely recommend it. The content manages to be both approachable and enlightening. I'm a backend software engineer with the latitude to architect systems at my company and the content so far has given me a stronger foundation for choosing how and where to manage our data. I really enjoy the mini-dives into the structures and decisions supporting the common databases you see today (B-trees, LSM trees, etc.) and discussing the trade offs between them. Now I find myself better equipped to evaluate the tools at our disposal for a given job.

I can imagine it may not dive deep enough for people who really understand the internals of a given data store and the content is probably available elsewhere. However this book is a thoughtful and engaging curation of a lot of information that I may have missed otherwise
I think it is reasonable to define a Scotsman as someone who is a citizen of Scotland and Agile as following the rules that are explicitly documented in Agile literature.

Many of the complaints in this article indicate that they are acting in direct opposition to what is published in Agile literature.

> Marketing and/or Product Management and/or Sales and/or the CEO constantly throw new requirements and new feature/functionality or constantly change existing architecture or design or functionality at the whim of the customer, at the "agile" development team who are expected (they are 'agile ' after all) to be able to react on a moment's notice

If you are following SCRUM to the letter, only a team's Product Owner is allowed to give them things to work on. Any other stakeholder who wants something done has to convince the Product Owner to include it; they are never allowed to give something directly to the team. XP doesn't require that new work always goes through a single person, but it does require that everyone coming up with requirements comes together in the Exploration, Commitment and Steering phases to help the developers properly prioritize work from the different sources.

> There is certainly no proper requirements review, certainly no design or functionality review

SCRUM includes an explicit place for this in sprint planning and backlog refinement. XP includes an explicit place for this in the "planning game".

> certainly no code review or proper software test engineering.

XP explicitly requires code review and testing. SCRUM doesn't require it, but it does empower developers to make that requirement. Work on something is not done until it meets the team's Definition of Done which is created by the team itself. The people on the team have the authority to require that proper code review and testing is done before work on an item is complete and the team can move on to new work. If they are not doing so, they have no one but themselves to blame.

> The other popular alternative is to just outsource to a bunch of 'agile developers' you have absolutely no control over in some third world country where the developers can't even speak or write English - which of course isn’t their fault because they were never taught or expected to speak or write proper English anyway.

Essentially the exact opposite of Agile. The Agile manifesto explicitly says "Business people and developers must work
together daily throughout the project" and "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation". Both of those are in direct opposition to using off-shore outsourced developers.
I teach a course on database systems, including one class on distributed databases (like Dynamo and Spanner) and another on dataflow engines (like MapReduce/Hadoop and Spark).

Students seem to find the Dynamo paper to be the single most enlightening resource. It does a great job of explaining Amazon's use case and how the solution fits the problem. I also reference the relevant Red Book chapter and some students value that context.

It's worth noting that students are very comfortable with relational DBMSs by this point, both in theory and in practice. It quickly becomes clear to them that NoSQL is better called "no transactions", as they know the costs and benefits of various isolation levels in a traditional RDBMS. If you don't yet have an undergraduate-level background in database systems I'd encourage you to seek that out either first or at least along the way to understanding NoSQL systems. My recommendations for how to do this as a self-learner are up on https://teachyourselfcs.com.
It turns out that "learning" is just fancy statistical modelling. It's not a misnomer, machine learning just takes the magic out of it.
Agreed. I was expecting some interesting data visualizations and other frontend topics.
Ok thanks that was very confusing with the dates. Doesn't help that they mentioned the test pilot flying an unrelated plane in the 80s, the foreman's son starting in the 50s, or getting his age wrong by 8 full years, but w/e.

Very cool read nonetheless, quite funny to learn that fake photos were prevalent back in the 60s, enough that newspaper companies would be so skeptical.
Excellent, I've actually been working on something similar and I'm glad to see it validated.

As I expected though, most people in this thread don't get it, which is understandable since it's pretty out there compared to the mainstream. I think they will once larger, "real" programs are written.

I don't think I'm gonna be able to "reword" this for people here so it suddenly clicks, you're probably just going to need to see it in action to understand it.
"The Martian" is really good book, and I loved the movie. I am looking forward to Andy Weir's new book. But ... I wouldn't put "The Martian" in the scifi AI category.
If you haven't already, you should read the article on writing v4 and why it is happening: https://loopback.io/doc/en/lb4/Crafting-LoopBack-4.html
+1 on "A Fire Upon the Deep" I really enjoyed that one.
It was far less common when your typical vehicle had a smaller rear blind spot than a T-72

There's a direct trade-off between safety and visibility.
"Playing with semantics" is a good description of programming language theory.
May be wrong but I think it's made to 'solve' centralised identity
You should check out Robopocalypse by Daniel H. Wilson
The part where it's not true lol.

Take bitcoin. Is it actually decentralized? You need someone to record your transaction on the blockchain. There are, in practice, like 5 gatekeepers - the minkng pools. You are lucky that they currently accept your transaction, but you already see they jacked up the fees. The fees will only get larger as there is more transaction volume and as the # of bitcoins awarded to miners goes down. There you go. You are once again back to paying the miners to be your trusted financial intermediaries. It's just called "miners" instead of "banks" but the database is nearly centrally controlled by a group of five mining pools who have most of the hash rate. Arms races always lead to centralization!

PS: sure you are protected in terms of current ownership, which is valuable, but at any time your account can be frozen.
My understanding is that the number of colors is just the maximum number of live values at any point, which is easy to determine, so the theoretically NP-complete part of graph-coloring is solved before you even start trying to pick registers. After that, it gets tricky to even define optimality, because you have to trade off the likely runtime costs of different sets of moves (which in my mind includes which variables to spill to the stack when). If there's a formal framework that decisively handles that stuff, someone please let me know.

OTOH, GP only actually said "NP problem", of which P is a subset, so they're not wrong. :)
I don't want to think about I/O. That's the point

I want to focus on connecting pure code together without thinking about the details of how that happens. I want this for the same reason that I don't want to think about manually allocating registers, managing memory, or caring about evaluation order

Also, like I mentioned, traditional I/O can't import functions or types, so this is strictly more powerful
I think all of Robert Forward's stuff would qualify. My favorites are

Rocheworld (AKA The Flight of the Dragonfly) - https://en.wikipedia.org/wiki/Rocheworld

and

Dragon's Egg - https://en.wikipedia.org/wiki/Dragon%27s_Egg
that is not going to happen in the industry, unfortunately. I worked there for years. the data in the article is probably correct, it takes about two years from the kernel->cpu_vendor->OEM on the development cycle for a stable product even in the fast-paced consumer electronic market, you just can not upgrade the kernel to chase the new releases which could cause instability chaos in the development team and put off the product delivery dates forever.
By our current understanding, superconductors only exist under extreme cold, a condition never occurring naturally in stars and supernovas. So the fact that neutrinos fly out effortlessly does not preclude the possibility of a superconducting trap of neutrinos.
Best Programming Language for High Performance
IN Germany there is a similar thing. Instead of having a barrier, they have lights to indicate which paths who can use and change them according to traffic.
Why we miss the objects that are right in front of us
Emailed you Nat (when you get a chance).
What's the appeal of taking pure functional all the way to an executable tautology? Inputs can be passed around in a pure FP world without reducing purity, so why remove them?

We never got around to output at all. Assuming the compiler can't write the output file before the program runs, how would you see the result of any program run in this world?

What about UI or network input?

I'm imagining that if only the compiler were allowed to do I/O, I'd have to rebuild Chrome whenever I wanted to see a new site, or even see an update to a site, or change my preferences. Wait, scratch that, I can't change preferences, because it can't save. Is the shell allowed to do I/O? What about output to the monitor, does that count? It's not a file, but it's Turing equivalent to an output file.
Is it just me or to me spot instances should deal with work and not storage, and hence your (stateful) units of work should be in a Queue/DB? (in a non-spot instance)

Attaching and detaching volumes is a good idea but I wouldn't use that to keep state
I think they meant "pretty clever"
NATURE Mastic: The therapeutic ‘tear of God’
"The Adolescence of P1" was a fun book (early AI)

Vinge, Baer, Benford, and Clark are all good hard SF writers. Some of Chrichhton's work. I suspect it was easier to write convincingly before the world caught up. These days it gets harder and harder to see past the next couple of decades.
Yup, foiled by smartphone keyboard.
As long as Linus refuses to provide a stable driver API, this won’t happen.

OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be stuck with one kernel (or any binary-compatible version). Every device requires entirely custom drivers for this, because ARM has no device enumeration.

Until Torvalds finally stops being so stubborn on this, Android and IoT devices will have such a short lifetime, and people will have to continue backporting fixes to ancient kernels.
Integrating a new kernel into an embedded device can be quite time consuming, and new kernels may introduce new bugs.

For example, back when I was working with Sheevaplugs, I found that, say, kernel whatever.13 worked really well, but whatever.14 and later would provide significant glitching in USB audio.

Each new kernel can require a lot of time configuring for the use case at hand, building, testing, etc. And then if a significant new subsystem is added (systemd-related features, for example) or internal kernel architecture changes, it would be incredibly time consuming to update the rest of the toolchain and on-device software to match the new kernel, and then validate the device performance again.

So it is better to have LTS versions with minimal changes. This makes security updates more likely on critical embedded devices, since manufacturers can updare the kernel without being forced to retool a ton of unrelated software.
Remember Churchill?

https://www.awesomestories.com/asset/view/Turing-s-Letter-to...
I'm not sure if "capped at" was the right wording. "Reduced to" might have been clearer.

If you bought a house through the trust at $100k, but now it's market value is $300k, you would only be able to sell it for an additional 25% of the appreciation ($50k).

http://www.mncltc.org/faq.html
My favorite: "Neuromancer" by William Gibson. A close second: "Accelerando" by Charles Stross.

(I met Charles Stross once. He told me that "Accelerando" was not his favorite of the books he's written.)
How does one prove they did that officially?
I agree. But maybe this is what's needed to get the companies that depend on such long term support to actually contribute their on-going patches publicly rather than only internally?

Ostensibly any patches found in an LTS kernel, must first be proven in a mainline release. But it'll be interesting to see just exactly how old and crusty these kernels end up becoming.
W. L. Gore and Associates
Very cool! Do you use the pdf standard form controls or is that too limited for this?

My lawyer seem to have a really good system (probably white-labeled), but the pdf's it generates have issued with annotations. I have to print them using Acrobat otherwise checkboxes are sometimes missing and hidden annotations are visible.
Anathem by Neal Stephenson, along with Seveneves.
Or they could put drivers in that are upstreamable.
> A bitcoin is just an entry in the BTC blockchain ledger.

I agree.

> The idea of the Lightning Network (which I assume you are referring to) is that you can execute off-chain transactions without needing to trust anyone.

Being off-chain, a LN transaction is not a bitcoin by your definition. While LN might be trustless, it's not the case than an LN-transaction is as good as a bitcoin in the blockchain. With LN, there's a race against time, whereby a node can lose funds received through LN, if it fails to settle on the blockchain. So the two (blockchain-tx vs LN-tx) are definitely not equivalent, but it's possible that future schemes can close that gap.

Timeouts are a necessary part of payment channels, since if you just send your bitcoins to a 2-of-2 multi-sig address willy nilly, the owner of the other key can hold your funds hostage unless you give him half. Hence the timeout, after which funds sent to the 2-of-2 multi-sig address can be redeemed by just a single public key (the sender's). The receiver needs to publish a transaction (that redeems the same 2-of-2 multi-sig output) to the blockchain before this point in time, or the funds received through the channel are up for grabs.
FizerPharm presentation is really good intro into Blindsight.

Watt's is a biologist who gives them plausibility and even ecological place that justifies their traits and behaviour. Hard scifi vampires!
> Today, it's on Google to maintain dead kernels that it is
> still supporting. The 2016 Google Pixel shipped with
> Linux kernel 3.18, which was first released in 2014 and
> hit end-of-life in January 2017.

This is good. If it is going to take so long to go from kernel to shipped phone, that kernel should be supported for a reasonable amount of time.
I've not come across anything that I would call 'epic' from a minimal set of rules, but some of my favourites that you can throw in your bag, teach in 2 minutes and play in 15:

Welcome to the Dungeon/Dungeon of Mandom - https://boardgamegeek.com/boardgame/150312/welcome-dungeon

Love Letter - https://boardgamegeek.com/boardgame/129622/love-letter

Hanabi - https://boardgamegeek.com/boardgame/98778/hanabi

No Thanks - https://boardgamegeek.com/boardgame/12942/no-thanks

Archaeology - https://boardgamegeek.com/boardgame/191300/archaeology-new-e...

Linko/Abluxxen - https://boardgamegeek.com/boardgame/153065/linko
I think you're missing something really fundamental. Decoherence happens at the sub-microscopic level -- unless things are very, very cold, in which case you can get macroscopic quantum effects. But at room temperature, by the time you get up to the molecular level things are already more-or-less classical. By the time you get to the level of a neuron they are (as far as we know) indistinguishable from classical. From the point of view of QM, there is no difference between being asleep and being awake. All of your mental processes are indistinguishable from classical.
Those are two different things, a badly written article failing to communicate a theory well on the one hand and and a bad theory on the other hand. I wrote the comment because of the former so that people coming to the comments first can decide to not read the article if they believe my comment. And while I tend to dismiss the idea of time being fundamentally linked to brains because of what I know and don't know about the inner workings of the universe, I did not express any opinion about the theory itself because the article left me pretty clueless what exactly the theory is and I also did not dig any further, for example read the actual paper.
*NIX, drives most of the world and is the reason why we exist the way we do today. It's also the reason why Google, Apple and other smaller outfits exist today.
USAA
Pets: Source of happiness for humans
Picked this book up a few weeks ago and starting diving into a yesterday! As somebody who spends more time on the data generation and analysis side, but is looking to move more towards the data engineering side, it's been great. Helps build out that "tree trunk" of knowledge to really grok what's going on.

Edit: I picked it up based off the recommendation of another HN commenter who said they picked it up after listening to Martin on the SWE Daily Podcast[0]

[0] https://softwareengineeringdaily.com/2017/05/02/data-intensi...