skysight-inc/HackerNews huggingface dataset:
I'm not keen on saying too much about Chrony, I'd rather let people without a stake in the game provide comparisons.

But obviously: if I had throught it was just the thing, I wouldn't have started writing Ntimed.

I also don't expect Ntimed to out-compete Chrony, and if it did, I'd have to start a fourth alternative myself, to keep competition healty.

A very large part of NTPDs problem was that there were no competition, which meant that everything got crammed into NTPD, come hell or 300KLOC.

We saw this also with GCC, which had become a stagnated arrogant monopoly, and suddenly LLVM forced them to care about users again.

Having competing projects is good thing, and I hope Chrony sees things that way too.
I agree that proactive service calls would be just awful. There is nothing I hate more than being pestered, by anyone.

Having said that, it would be really good to have automatic systems that detect problems. This is done by us with technology, but it could also be done for brick-and-mortar business with some kind of standardized management process.

Two applications come to mind:

(1) Have engineers fix things before the problem reaches the customer

This is what people really want: It just works, and they don't have to bother with it.

(2) If the customer does call, and tests say things have gone wrong, he immediately gets sent up the queue and the rep is warned that this person actually is having legitimate trouble and needs to be given more attention and goodies.

Danger: You need to constantly align your test systems with your customer's experience. Wrong confidence is even worse than ignorance.
So much about ISP <> customer confidentiality then!?
Have all of those IP addresses published as related to the hack been marked as dirty by Spamhaus e.a. before or after the hack - dates shown in the post are 20-Dec etc - after the hack was published.
So, so far we've seen 0 actual proof that NK is behind the Sony hack, big allegations from the US government, NK which wants to be included in the investigation and the US which doesn't want NK included in the investigation.

I'm having this strange feeling of déjàvu....
Thank you for publishing your code. Very nice to read through it. Can you tell me, is it possible to 'like' or unlike someone else's article, by guessing the id?
I suspect that the popularity of dystopian fiction is not primarily because of ecological fears or the like, but rather because they provide a setting that contains many elements that we miss in our society. So it's more about unfulfilled current needs and wish fulfillment. Even in horrible zombie apocalypse stories.

For one, in many of these stories people are forced 'back into nature and self-reliance', which we like because many of us, especially in urban environments, try to get out of the artificiality we feel is all around us (this might also explain the 'hipster' phenomenon of carefully-crafted illusions of dive bars, and the love for self-made products and art).

Second, we have a fear of increasingly global, powerful and murky institutions. We 'confront' these fears through dystopian fiction.

Third, and perhaps most importantly, I have noticed a rather shockingly high level of loneliness among my urban-setting peers (mid-twenties to late thirties). Even with a decent amount of individual friends, it seems that people miss 'community', a desire that I suppose used to be satisfied through churches, smaller towns, and more traditional 'extended family' structures. Our friendships and lives in general are much more fragmented then they used to be.

What fascinates me about most popular dystopian fiction is that there is a very strong emphasis on small groups of people banding together, forming strong bonds in the light of adversity, learning to trust each other, and basically spending all their time together, in a tribal fashion. I think more than the dystopia, it is this effect of a dystopian setting that we love.

Perhaps in the past the 'need' for satisfying that desire of being part of a small, tight group just wasn't as strong. Or perhaps they were more easily expressed in more conventional ways (consider a progression from The Cosby Show, to Friends, to New Girl; a move away from families to friends-from-back-home to somewhat random people in a loft because they can't afford their own place).

I'm well aware of the fact that these are just some thoughts, and I haven't done much research yet on the subject. I could be quite wrong. But it's my two cents and something I've been thinking about a lot lately.
It depends on what I'm doing.

Most of the time I can afford to simply refresh and see the results. This applies to both my backend and frontend work some 99.99% of the time.

Occasionally, however, I find myself writing something slow, like a snippet that accesses the database and "mangles" some data. In these instances I try and write a bit more code before checking my progress, so as not to waste too much time watching reruns.
The major use of bitcoins currently seems to be as a store of value: http://www.coindesk.com/analysis-around-70-bitcoins-dormant-...
I experienced suddenly loosing my job, wife and house all in a few weeks time during the dot-com crash in 2001. I went from managing a group of 16 web developers in a large international ISP to do web server sysop. I was lucky. There were 45 others that applied for the same job, and I was really just a university dropout. In 1997 I contacted 7 different companies just for fun to see if they would offer me a job. They all offered me jobs. One guy offered me a job in less than 5 minutes without knowing anything about me, except that I knew how to write html and cgi scripts. It was simply to easy to get a job back then.

Later I went on to finish a masters degree in computer science and have two more kids.
If a price of a house has dropped to 0 or near, it would indicate collapse of related systems nearby Electricity/Crime etc. Lot of barren houses in Detroit are an example.
(Disclaimer: this is merely nitpicking, I get the gist of your original post).

I think your split of "Worse is Better"/"Better is Better" languages is a bit arbitrary. Everyone agrees that C is a Worse is Better language, but the rest? In particular, I cannot decide whether you equate OAOOW with Worse is Better or not -- Python is OAOOW, but I wouldn't say it's a Worse is Better language (and claiming it is because "you don't need speed" is like saying Haskell is a Worse is Better language because "you don't need the ability to easily reason about runtime performance". Every language claims "you don't need X"; that's clearly not enough to classify it as WiB).
LR parsers like yacc are obsoleted by Earley parsers, which Cox apparently didn't know about in 2010. Quoting <http://loup-vaillant.fr/tutorials/earley-parsing/what-and-wh...:

The biggest advantage of Earley Parsing is its accessibility.
Most other tools such as parser generators, parsing
expression grammars, or combinator libraries feature
restrictions that often make them hard to use. Use the wrong
kind of grammar, and your PEG will enter an infinite loop.
Use another wrong kind of grammar, and most parser
generators will fail. To a beginner, these restrictions feel
most arbitrary: it looks like it should work, but it doesn't.
There are workarounds of course, but they make these tools
more complex.

Earley parsing Just Works™.

On the flip side, to get this generality we must sacrifice
some speed. Earley parsing cannot compete with speed demons
such as Flex/Bison in terms of raw speed. It's not that bad,
however:
• Earley parsing is cubic in the worst cases, which is the
state of the art (and possibly the best we can do). The speed
demons often don't work at all for those worst cases. Other
parsers are prone to exponential combinatorial explosion.
• Most simple grammars can be parsed in linear time.
• Even the worst unambiguous grammars can be parsed in
quadratic time.

My advice would be to use Earley parsing by default, and only
revert to more specific methods if performance is an issue…

In 2014, we now have Earley parsers in C, JavaScript, Lua, Perl and Python.

Further discussion on killing yacc:

http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv...
http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv...
http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv...
http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv...
My lame cartoon about this affair:

https://github.com/scardine/random-writings/blob/master/text...
Overlay Blocker closes overlay popups even if the X button is disguised
Check out this demo http://www.castbin.com/casts/rdcTPbRz (It is made using my own tool.)
I would be surprised if it does anytime soon.
async/await's would conflict very much with the complete lifetime system.
After an await your programs state might be completely different. Things that are on the stack have to be saved for the duration of the await and must be restored. However destructors may not run in between. And you must even take into account that the await might never finish.

I think the original Rust did not even have a need for async/await because it used "lightweight" tasks for that purpose. But now these are out.
I've lived in many places around Europe, and I've lived among Americans from all over the US, and I definitely noticed a difference. Perhaps you're right about cocktails, but in most cases American used ice where the Europeans didn't (a glass of coke being a prime example). They would even did this in winter, which always seemed funny to 'us' Europeans.
That's the slow start algorithm, part of standard TCP congestion avoidance:

http://packetlife.net/blog/2011/jul/5/tcp-slow-start/
Obama to See If North Korea Should Return to Terror List
The biggest annoyance with NTPD is that it will give up synching if the time delta is too large. It just shows that the software was primarily coded to be a server. If you just use NTPD to keep your machine times in sync `chrony` is a better solution for now.
Asynchronous Ad Hoc Real-Time Stream Processing Framework
Jobs was nowhere near Apple when the Newton was developed. He also pivoted Next away from selling fully integrated computers in the 90's and competed in software licensing.
The life of a Marine Biologist
I'm making a language that is equivalent to (and compatible with) C++, but has a regular grammar, bison is quite pleasant to work with, and the lalr grammar is potentially reusable elsewhere (in javascript, with jison, in haskell, with happy, in go, with go-yacc and so on).
It also allows me to change the language structure very quickly which is very important when designing the language.
In the future I'll write a recdes parser as well, because I also want pretty error messages, but the parser generator saved me a ton of time so far and will continue to for a while.
I also don't see that as a problem either. There are 2 seperate issues:

a) Be able to await the result Future/Task objects instead of attaching callbacks to them. This is done by source code rewriting and has no dependencies on an IO system.

b) Having IO libraries that return future objects. You can do that with IOCP as well as with unix poll based architectures. Might be a little bit easier with IOCP, but it's no deal breaker. I already did an implementation for epoll once. You simply spin up an eventloop in any thread. Any IO read/write returns a future object, posts the work to the eventloop and as soon as the work completes the eventloop completes the future.
It has its value for "quick and dirty" parser generation for experimentation, or for use in DSLs/ small tools where throwing something together is sufficient. But I agree with you overall - much more sophisticated parser generators than Yacc have still not gotten us to a point where using a parser generator for a full scale compiler for example is particularly viable as a long term strategy.
From the article: "...though Bison still retains yacc's infuriating lack of detail in error messages. (I use an awk script to parse the bison.output file and tell me what really went wrong.)"

Oh dear. Now I'm going to have to get a new Irony meter, because mine just blew...
Yes I did. The closest commonly listed illusion I can find is the Zöllner illusion[1], but that uses uniformly lengthed, angled short lines in differing directions to make parallel lines look unparallel. This uses a biased saw-tooth to create the impression that the trend of the line gradually curves down. I wonder if it has a name.

Interesting effect. It could be used nicely in many graphic design contexts, although probably more subtly than demonstrated here.

[1]: http://en.wikipedia.org/wiki/Z%C3%B6llner_illusion
Just another Sourcecode Viewer for iOS
The USA is very corrupt. Operation Northwoods, 9/11, this.
Yeah... It's been years since I thought about this, but: for linux you basically have two options: fork() and pthreads. Fork creates a new process and IPC between the parent and daughter processes can be cumbersome - and it's not a terribly good system since if you're spawning a process to do a different task, the default state contains overhead of the old task. Pthreads gives you shared memory (and simple mutexes to protect critical data) but that's about it.

Beos' app model discouraged the use of fork() - but you could if you wanted to - and instead had a pthreads-like kernel level support for threads with some very nice C classes that handle message-passing and the like; interthread communication was baked in in too so you could have strong IPC without pipes. BeOS also came with a hybrid spinlock-semaphore mutex called the 'benaphore'.

There were some very excellent C++ wrappers for all of these too, the BLooper class was a by-default message handling loop (for example).

Finally, the threading model was pretty cool, it was a logarithmic stochastic time allocator with a range of "hard priorities" that would give you RT control (but could also freeze your machine if you had an infinite loop). Unfortunately the kernel had a tendency to thrash threads between CPUs in a multi-cpu setup. I think this was fixed in Haiku.
I don't see why the OpenBSD developers would want to avoid their strategy of producing secure code.
The erratic price could also hurt the economy, if Bitcoin was widely adopted.

Customers will be careful in spending their Bitcoins, if they believe that the price will be higher tomorrow. Likewise business would either overprice, rather than running the risk of losing money, if they cannot convert their Bitcoin to something more stable fast enough. Both are elements that could lead to decreased spending.
ESET Ireland Offers Tips Approved by Santa for Safe Holiday Shopping
What exactly do you find creepy and what makes her religion a "cult?"
Earley parsers give no guarantee that the grammar is not ambiguous. This is very important, since you don't want your parser return some arbitrary parse tree, but you want guarantees that the parse tree that you intended is returned. yacc does this IMHO in the correct way: give warnings (shift/reduce or reduce/reduce conflict in case of a possible ambiguity) and let the user resolve these manually. Since these conflicts are a strong sign of a bad specification of the language, the parser generator should be very cautious in resolving these ambiguities - doing this automatically probably leads to strange consequences the user did not intend.
The problem is this is optimising entirely for the wrong thing.

And "killing Yacc" is a pointless exercise if the point is to get traction. What it needs to compete with is hand-written recursive descent parsers.
I think some of the ideas behind maze generation can be applied to procedural level generation in general, whith some clever tweaks at least.

Here is an approach in Python albeit not as interactive as the mentioned article:
http://pixelenvy.ca/wa/ca_cave.html

In case people didn't recognize, the author of the articel is also the author of this book which is for free (kudos!) on the interwebs and can be bought as a eBook.
http://gameprogrammingpatterns.com/
It's a microkernel: it is intentionally minimal. Microkernel operating system design is from the 1980s is different from the monolithic, bulky and older operating systems designs you are used to (famously including Linux, see the Tanenbaum-Torvalds debate). It has all the features that it would likely ever need already.

Instead of having all the services required for an operating system in the kernel, the kernel just implements the bare minimum including fast IPC. Things that traditionally are implemented in the kernel (filesystems, device drivers, other modules, etc) are all implemented as services living in userland and are assigned the minimum necessary additional permissions for them to perform their task.

You can build a *nix like system on top of seL4. You can even run Linux itself on top of seL4, with L4 acting as a hypervisor.

An operating system doesn't consist of just the kernel.
I like the game for an open-source project, but as a serious project, it's not very difficult to program otherwise(no pun intended).

Not sure if anyone knows, but the game is very, very similar to the Google Chrome Unable to Connect to the Internet game.

For those who don't know about the game, disconnect from Internet, open google chrome, hit any webpage, and once you see the "Unable to Connect" Dino, just hit the "up" arrow on your keyboard for hours of fun...
I don't really buy it. This doesn't explain why a chassis intrusion alarm was triggered, nor why a large chunk of logs are now missing.
Helloify – Multi-Platform Business Messaging for Productive Teams
United Therapeutics are a strange company. In 2010, they released a supplement to their annual report in comic book form - http://files.shareholder.com/downloads/UTHR/1290392365x0x466...

And the following year, released it as a musical.
Also, where's the rainbow overlay? THEY TOLD ME THERE'D BE A RAINBOW OVERLAY!
Still not that much better than jacking a private car.
Flexbox Adventures
The Baltic States: The New Hotspot of Tools for Developers and Designers
Lessons I've learnt while teaching
Cloud castles: NASA wants to deploy manned solar-powered airships to Venus
Nice tool! Thank you for sharing!
Which bit of the requirements do you think is impossible?
too addictive :-)
Does this make sense as a counterexample?: Take a picture of the gold bar, you have now stolen the Bitcoins without taking the bar.
Totally agree with this point.

Asking users for too much information up-front will put them off your app before they even get into the first screens.

I'm working on a couple of projects where this conversation has come up. After some qualitative interviews with our target group, it became abundantly clear that this group (under 40 urbanites) are increasingly aware of privacy issues and social signups. They specifically cited Spotify as the culprit. Turns out there were some closed OneDirection fans, and Spotify outed them using social playlists.

So if you are going to ask for that info, please tell the user WHY that info is necessary, and WHY it will make a better user experience.
Should We Believe in Santa Claus?
> I'm bothered by the need for "unsafe" code in pure Rust that's not calling hardware or C code.

Why is this bothersome?

I'm curious, as to me the advantage is not in full-program safety, but in having a distinction between portions of a program that are guaranteed safe and portions that aren't.

Or, to turn it another way, Rust isn't giving you guarantees about 100% of the code you're looking at: it's vouching for the >0% (hopefully!) but <100% that's marked safe.

It seems an elegant, realistic engineering solution to a hard trade-off between performance and safety.
Last time I needed a maze I implemented Kruskal's algorithm, which is generally useful for finding the minimum spanning tree of a graph. You just run it on a lattice graph where all edge weights are the same and you have yourself a perfect maze.
I don't know, sometimes something in an article triggers another stream of thought or tangent, and its a comments section, and other people might want to discuss that. I don't necessarily agree with the comment (as I have next to no visibility of this) but certainly don't mind reading comments on it. Maybe I'm wrongly using the site!
> you don't want your parser return some arbitrary parse tree

You have a mistake in your assessment of Earley parsers. For ambiguous grammars and input, they do not return an arbitrary tree, but all possible trees. In this regard they are no worse than yacc: "the user resolve[s] these manually" by picking the correct result(s). To a human, it's visible at a glance which is the correct result(s), entirely without needing to learn how to decipher these bizarre warning messages you mentioned.

> conflicts are a strong sign of a bad specification of the language

So what? That's not pragmatic thinking. We cannot go back in time and influence the design of ambiguous computer languages so they are not ambiguous. Natural languages never are without ambiguities!

The parsing job needs to be done, no matter the complexity of the language. Instead of wishing it weren't so, just use a tool that can deal with it. Earley parsers can, yacc cannot.
Developers are a strange bunch. I've never heard someone say, "Wow, look at that optimized code! I can't wait to work with this dude!". However, I have heard many times, "Working with this person is great. They do everything from expressive code, to small logical commits to make my life easier."

It's almost as if many of us would rather be seen as an elite, rather than seen as a pragmatic developer.
This is what I don't get... _Why_ is 'type' theory _a logic_? A type is an enumeration of values (terms), right? What's that got to do with truth values and how they may be manipulated? I've read some of the papers/texts you posted in that tremendously helpful summary (thanks by the way!) and talking about type theory always segues into talking about logic. If you could explain that _one_ thing I'd be so happy. To me, type theory seems like set theory done right...
Did you really just combine "fact of capitalism" and "it's unfair for the current company to feel cheated" in the same sentence?

Where in the facts of capitalism does it say that companies will be fair in how they treat their employees, and that time off to seek employment elsewhere is part of being fair?

In fact, I thought it was the other way around. When someone changes a job, they get a revaluation of what their job is worth. Often the job change comes with a salary increase and higher status in the new company. This serves to raise the price of a worker. By discouraging workers from leaving, a company can keep its wages lower because the workers are not as coupled to the market rate.
I thought it was an expert system too. Maybe there should be some direct sharing with the team. Especially if you can integrate this with Slack that would be much better.
Mathematicians Make a Major Discovery About Prime Numbers
"Teach Yourself Programming in Ten Years" by Peter Norvig
http://norvig.com/21-days.html
[CODE] Reverse engineering Omegle
Sharing this with my design team. Thank you! Great work!
I don't think the reasons are gone completely. Having children is much more than mating with someone and taking a test to determine that the children are yours. I want to have children one day, so I'm very careful with who I select for a partner, because I want her to be there with me raising our children, and be very committed to the family.
The way I think of bitcoin and cryptocurrencies is as a huge thing looking for a ledge to hold on to. It's pretty likely that it will fall off and crash but if it manages to cling to the cliff and get to stable ground, it's a big deal.

So, value store, unit of account.... some other gainful employment this technology can create by blending it together with other things.... Any way for bitcoin to be useful at this point helps it cling to the cliff.