skysight-inc/HackerNews huggingface dataset:
The advice to use a single open/close call instead of multiple is great, but that is advice on how to effectively use the filesystem. It isn't in anyway, shape, or form beating the filesystem.
If you are looking for performance optimizations beyond Numpy (GPU or CPU) take a look at Numba by Continuum
I see. For the challenge. Thanks for the answer!
ActorDB could get you there, it's a distributed DB based on SQLite [1].

[1]: http://www.actordb.com
Some days it's robots taking all the jobs, other days it's who's going to take care of all the old people. Come on people, just pick one.

Unless you count hoarding canned food, you can't really save for the future. You can acquire claims on income in the future by buying stocks or bonds or whatever, but that income will have to be produced in the future, produced by young people working. Old people have always been taken care of by young people. The illusion of the financial system can't change that. There are relatively more older people now than there used to be, but on the whole that's a good problem to have, because people are living longer and have more control over their lives. The best way to deal with an aging population is to guarantee a decent standard of living for the young, so people don't have to wait until they're pensioners to enjoy income security.
Write them for everything (I'll note some exceptions). Use code coverage tools to see what parts of your code are not being hit by tests. You'll find some surprises there (tests not actually testing what they say they do). When something breaks write a test that would have found the bug, and then fix it. A good test suite will save you tons of time. If a piece of code is hard to test, it's bad code (lot's of branching logic, doing way too much in oe function/method, managing/changing too much state). Re-write it so it's easy to test.

However, don't test the compiler/interpreter and don't test your framework/libraries. Tests shouldn't look like this:

def test_foo():
foo = Foo(a=1, b=2, c=3)
assert foo.a == 1
assert foo.b == 2
assert foo.c == 3

This test will never fail and won't tell you anything. Don't test your dependencies code if you're using active, popular packages. Test that your code passes in the right values, and handles any errors that could happen in a reasonable manner.

The time savings you can get out of a good test suite are almost limitless. Good test save lots of time in development and prevent broken things from making it to production.
Only if it gets turned into a WebExtension:
https://github.com/akhodakivskiy/VimFx/issues/860
Here's one huge difference: https://news.ycombinator.com/item?id=14550931

(Specifically, this site is depriving me of income.)
Fabulous... imagine if they were living and were able to talk about the eons they witnessed!
By balancing the budget we wouldn't be getting rid of debt, we'd be stopping the growth of debt. Ideally, debt should grow at the rate of inflation, but there can be some large spending times and some low spending times. Debt shouldn't be larger than a significant portion of the economy.
That's not quite what I mean.

I mean an Erlang actor is a state machine isn't it? It accepts messages, and each messages causes the actor to either return some data based on its state, or to enter a new state.

State machine - so it's holding state isn't it? And it's mutable because you can cause it to enter a new state by sending messages.

And you have lots of these mutable state machines in your Erlang process - lots of mutable state.

See what I mean? I know they don't have shared memory, but each process is effectively a little piece of global shared mutable state. And that's bad!

In other parallelism models like fork-join, there is no mutable state. Tasks get input parameters, and produce a result. They don't have any state in any meaningful sense because you can't observe their state externally and you can't ask them to change state externally.
> Erlang code is single threaded. Each Erlang "process" is an isolated, share-nothing single sequence of instructions, and you don't use semaphores, locks, or critical sections in writing Erlang code. The BEAM VM is implemented as a multithreaded process, but this is not exposed to the Erlang code

The same is true for PHP.

No wonder Facebook developed HHVM for PHP and also uses Erlang with WhatsApp and other parts.
Maybe, but the blame for this situation can't only be placed on the young who see the system failures approaching. Maybe a system built to provide care to its creators is fatally flawed if it is largely dependent on the consent and participation of children and unborn people of the future?

At which point I would like to point out that this world can likely provide for everyone were the economic ideology focused on sustainability and maintaining (at least) baseline human resource needs instead of demanding permanent growth, potmarked by boom-bust crises every 10-20 years.
I can't find any source apart from this (which is NOT cited on Coindesk): https://www.wfp.org/news/news-release/blockchain-against-hun..., it does not say the same thing.
This is some actionable feedback, @dharness! Thank you.
That's one of the challenges of executing this — is finding good voices that a lot of people love listening to. We are working on this! :)

Btw, try listning to this voice on 1.2, 1.5, 2x speed. That's how i typically listen to my podcasts. Sounds perfect to me.

Also, what do you think about our female voice? https://readbyhumans.com/convert-case-studies-into-podcasts
There is a demo there. Would you prefer that voice, over our male voice?
A screen reader acts on behalf of an individual user. This is rebroadcasting someone else's content.
Moving large amounts of data around, that you don't need real time.

CSV is a grand solution, one that has a hell of a lot less over head than any other "api" that many HN readers would normally see.
It adds italics in Markdown. Try it out here if you want: https://stackedit.io/editor

It works in Slack and other chat apps, too.
I wasn't saying a CSRF token saves you here.

All I'm saying is that security is a complicated topic. People already misunderstand things like CSRF, CORS, resource protection, etc. And they already get them wrong.

CORS is designed to loosen the security protections added by a same origin policy. It is not designed to increase security.

Piling on CSRF protections is just blurring the use case for CORS. All this is going to do is confuse people more, and more people are going to get it wrong.
Sorry, my previous comment wasn't clear enough. Perhaps I misunderstood you, but you seemed to suggest that being female would uniquely qualify a new board member to promote a more diverse and inclusive culture. The research that I referred to suggests that this may not be the case or at least not as much as you might think.
Why customization is the key aspect of web crawling solution
The only downside I can think of here is that plain-text-only documents tend to defer images/figures and other non-plain-text media to external files (if they even support such media in the first place). This means that these additional files (and their formats) need to be considered as well.

After all, not all of us are able to learn by just reading a bunch of text. Some of us need graphical (possibly video) or even interactive material as well. Such material is at high risk of being lost (see also: the abundance of interactive science demonstrations online that are implemented as Java or Flash applets).
The Agreement That Got Signed Under a Tree on Wall Street
Travis Kalanick is not ethical enough to steer Uber
Why store a database file in each block when you could also store transactions? This is what Catena does: https://news.ycombinator.com/item?id=14548174. Also allows for some interesting things you can do with privileges, for instance.
With a screen reader you have first to go to the original content site. You may have to log in, you will probably see some ads. All of this gives proper attribution and money to the authors pocket. This kind of service goes all around that. The fact that they did not even ask authors first is mind boggling.
I'm as salty about baby boomers as the next guy, but it's a bit ironic that millennials don't realize that they'll be screwing the next generation over even harder. We are in the position we are in now largely because baby boomers didn't have enough kids to support them in their retirement.[1] But millennials are having even fewer kids. When millennials in western countries can no longer work, who will take care of them? Can they count on an endless supply of young immigrants raised and educated on foreign taxpayers' dimes?

[1] In the past, people had children so someone would be around to take care of them in retirement. Financialization of that process decouples the specific children from the specific retirees, but does not otherwise change the basic dynamic that there has to be a working generation to provide for the retired generation. You can't eat money in your 401k.
It's to emphasize a word since not all sites allow basic text formatting like italic and bold. As a result, people will use asterisks or underlines to indicate that a particular word is important.
Who is to blame?

Part of the original article is a lie (at least as how it pertains to the US). The social security system will eventually be unable to pay out at current rates. But notice how nobody worries about whether we'll still be able to spend 10x what everyone else spends on the military?

A lot of this is about how we plan on spending our money. The current argument is framed as "if we don't change anything, this might happen" but the change everyone focuses on is the change in how much money goes towards satisfying the retirement savings.

You notice nobody suggests buying less aircraft carriers or scaling back the military? Instead it's all about not reducing any other spending. Putting the spotlight on one particular form of spending and then declaring that if it can't pay for itself due to demographic changes, we should scare the shit out of everyone and privatize it and pour trillions of dollars into Wall Street.
Calling this a 'teachable moment' is really letting the person off the hook for observing and learning up before now.

If he hasn't learned by now what is appropriate behaviour, why do you think he'll ever learn?

And if he doesn't learn rapidly and advance with best practices in corporate culture and governance, then he's not capable of the leadership and management responsibilities of a board member.

The 'teachable moments' were at least 3 years ago, if not much earlier. The firing offence is ignoring them.
I must point out Jim Gray's paper To Blob or Not To Blob[0]. His team considered NTFS vs. SQL Server, but most rationale applies to any filesystem vs. database decision.

The summary was "The study indicates that if objects are larger than one megabyte on average, NTFS has a clear advantage over SQL Server. If the objects are under 256 kilobytes, the database has a clear advantage. Inside this range, it depends on how write intensive the
workload is," but keep in mind this is spinning media from 2006. Modern SSDs change the equation quite a bit, as they are much more friendly to random IO and benefit less from database write-ahead log and buffer pool behavior.

Also, when deciding between blob vs. filesystem, blobs bring transactional and recovery consistency. The DB is self contained, and all blobs are contained in it. A restore of the DB on a different system yields a consistent system, it won't have links to missing files, and there won't be orphaned files left over (files not referenced by records in DB).

Despite all this, my practical experience is that filesystem is better than blobs for things like uploaded content, images, pngs and jps etc. Blobs bring additional overhead, require bigger DB storage (more expensive usually, think AWS RDS) and the increased size cascades in operational overhead (bigger backups, slower restore etc).

[0] https://www.microsoft.com/en-us/research/publication/to-blob...
>Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.

+1

One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production.

It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but still pure with effects only via monads. [1], [2].

Following on and presumably related to that PureScript is strict. [3]

[1] https://news.ycombinator.com/item?id=1924094

[2] http://www.cs.nott.ac.uk/%7Egmh/appsem-slides/peytonjones.pp... (PowerPoint) Slide 40

[3] https://github.com/purescript/purescript/wiki/Differences-fr...
There was also a parameter to use stereophonic sound if your sound card supported it (mine didn't), so you tell which side monster sounds were coming from! Mind-blowing at the time.
"the legacy C++"

Interesting reading but the author seems intent on pushing some buttons.
> More advanced type systems, however, allow to specify the generic constraints explicitly.

Well, Java allows it, even if it looks a bit unglier than the Rust example.

<T extends Comparable<T>> T min (T a, T b) {
if (a.compareTo(b) > 0) { return b; } else { return a; }
}

And even without general availability of concepts (already in gcc 6.x), one can achieve it in C++ via if constrexpr.
I was also born in a country "with a strong social system". The so called social system is in shambles, and contributing to it is basically contributing to a ponzi scam.
I did nothing of the sort. You're trying to put words in my mouth, and I don't play these kinds of games. Bye.
The parent comment is a bit misleading, or completely wrong. SQLite also has to allocate blocks in the database for anything you store. Some of the structures and techniques that SQLite uses for doing this are very similar to the way a filesystem does it.

Instead, think about it this way. With a filesystem, the database is managed by the kernel. Every time you want to read a file, you might do four system calls: open, fstat, read, close. Or you might do mmap instead of read, but you're still doing four context switches, at least in typical cases. Switching to the kernel and back has cost. Normally this cost is small, but if you make a lot of system calls you'll notice the costs piling up. The kernel also has to check permissions to make sure that you have permission to read the file.

With SQLite, the database is inside your application. When you read a row, there's a chance that the row is already in your application's memory. This means no context switches back and forth between application and kernel.

Additionally, when you read a row, the entire database page is read into memory, which includes other rows too. The kernel won't do anything like that with your application--it won't give you img1.png and img2.png if you just ask for img1.png. Maybe they'll both be in the kernel's page cache, but you still have to open and read the file.
London fire: Flames engulf tower block
Next iOS update will kill your old iPhone Apps
At least in the U.S., we can rationally worry about both things at the same time! Social Security is bankrolled by a tax on labor income. Robots, however, produce capital income. We could easily be in a position where millennials have limited employment because of automation but nonetheless carry the burden of supporting the baby boomers in retirement.
DAX (Germany 30) Trading Setup
I played FS4 a lot as a kid, but I don't remember there being a jumbo jet with the modified cockpit shown in one of the screenshots. Does anyone know what that is about, was that an add-on?
How can it have a strong social system with minimal taxes?
Home values appreciating out of proportion to salary increases are another way this is occurring. Discussed a couple of weeks ago.

It's great someone who works as a bus driver bought a home 40 years ago and it's now worth a mint. For that person. For the young person wanting a home now it's a very bad situation.
I have to agree. I see this attitude in ever increasing numbers of German developers as our High-Tax System even openly admits to all the benefits you won't receive.

The amount of taxes one has to pay compared to the security one is offered feels strongly out of whack for the 60-200k/yearly family salary bracket.

There is braindrain, but also Stockholm Syndrome. I oftentimes see discussions between developers where ones that have left Germany's system get attacked behind their back for being so "irresponsible" and missing out on security systems here, while enjoying, after about two to three years of saving money elsewhere a lifestyle of financial security that is leagues above everything the german social security can offer. There are lots of reasons to stay in Germany, but social security and finances aren't ones if you are a talented developer that is just looking for a good life.

It's a strange tension currently, I'm unsure where this will lead in the long run.
Interesting recent stories out of Santa Cruz and mushroom poisoning (generally: hepotoxic), treated with Silymarin.

Well, 2014 recent:

http://www.slate.com/articles/health_and_science/medical_exa...
Not really, the biggest problem with the baby boomers aging was the "boom" part, there were a disproportionate number of people in that generation. Gen Y may be having less kids, but there will be less of them to support in retirement and the next generation might even get cheaper housing as the population shrinks.
By the time millennials retire, around 2045 and later, robots and AI are likely advanced to the level that they could take care of the old and produce most necessities of life. The labor needs of that future world would likely look quite different from what most of us envision now.
EU is generally a lot more consumer-friendly than US. Or company-unfriendly depending on your perspective.
What if companies interviewed translators the way they interview coders?
Ah, ok. My bad. Thanks for letting me know.
Web server replacement method
Web site for a variety of reasons need to replace the server, do seo people will worry about the replacement server affect the site ranking? Server for the importance of the site is self-evident, better server is bound to have a certain impact on the site's ranking.

1, website backup
Web site backup that is the database backup, replace the new server before the owners first of all the old server to download all the data to the local, if you do not know how to download, you can ask the space to help.

2, modify the DNS server cache time
Each domain name resolves the retention time in the DNS server. Webmaster in the site for the replacement of the new server DNS threshold value should be set as low as possible, you can speed up the domain name resolution effective time, easy to know the search engine as soon as possible to know the site has replaced the server. Otherwise, the spider is likely to crawl the site.

3, upload the data to the new server and complete the analysis
The stationmaster will be a good backup site data uploaded to the new server, and then check whether the site can visit, the database is missing, the background is not open, if there is no problem, you can resolve the domain name to the new server. At this point, need to pay attention to, and in doing these operations, the old site on the server to keep running. As long as the user to ensure access, spider crawling is normal, the site's ranking will not be affected by the impact of the replacement server fluctuations.
> It uses the thermal fluctuations intrinsic to the computer’s audio I/O system.

Took me a bit to find it, but here's the source of the entropy. This leaves out one of the most underserved clients of randomness: virtual machine guests. In that case I think it better to stick with haveged[0], or pass the host's entropy down to the guest and call it a day.

We really don't need a "constant" source of entropy as such is provided by Torbid, unless you're using some piece of software that insists on reading from /dev/random instead of urandom. Instead we need just enough random bytes to seed a well tested and suitable CSPRNG, such as one based on the Fortuna algorithm[1].

0. http://www.issihosts.com/haveged/

1. https://en.m.wikipedia.org/wiki/Fortuna_(PRNG)
Previous discussion:
https://news.ycombinator.com/item?id=14542874
From OP: "SQLite is much faster than direct writes to disk on Windows when anti-virus protection is turned on. Since anti-virus software is and should be on by default in Windows, that means that SQLite is generally much faster than direct disk writes on Windows."

I don't get this. If scanning the content is important (as acknowledged by the author), then bypassing the scan via blob storage is a security issue and the application should go through some extra hoops to scan the content before saving it to blob, and this should be measured and part of the comparison.

Also, if the SQLite files are exempt from AV scan, then the level field should also exempt the uploaded files folder in test. I mean, knowing the dice are loaded and then claiming it as an advantage does not seem professional.
$1B startup Automattic is closing its San Francisco office
you are right. this was also many years ago so my memory might fail me. Perhaps my internal server didn't have access to npmjs.
What are you considering?
One is 32 bits, the other is 64 bits. It occupies exactly twice as much space. It can contain far more information, but it is only twice as big on the harddrive.
I wonder if it's a front from a trading company and they look for hires there.
My thoughts and prayers to the victims and there families.
Comparing it against Rust doesn't really seem fair. If I wasn't using Haskell, I'd be writing Erlang, and last I checked GHC is much faster than Erlang/OTP. Certainly faster than CPython, Ruby, and most Node.js.

Trying to compete with Rust or C++ performance in Haskell is certainly frustrating to reason about :)
2 times 32 bits equals 64 bits...
I love the discussion thread on GitHub: https://github.com/HIPS/autograd/pull/175#issuecomment-30652...

As someone just starting to study machine learning it's inspiring and exciting seeing this kind of thing.
That statement doesn't need backing up.

It is self contained, and speaks directly to the nature of human opinion.
I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividing code into three stacks: data/state management, components, and stateful glue code (AKA reducers, components, and containers in the React universe). Redux is most useful in that it keeps you honest to this paradigm and that it provides some nice dev tools -- the library itself doesn't really matter. I don't think there's anything wrong with a global event bus in theory but in practice it often lends itself to abuse. In fact, I'm currently moving a legacy application to React/Redux and found that the global event buses were a good idea in theory, a spaghetti factory in practice.
I had the same experience: I really enjoyed the expressiveness and power of Haskell, as well as the strong type system. But Rust gives me all those things, as well as iterators for laziness when desired, without the pervasive laziness that had me constantly chasing down space leaks and adding strictness annotations.
2045 is about as far into the future as the first episode of "Seinfeld" is in the past. Unless a black swan event happens in AI development, the world will look pretty similar to how it does today.