skysight-inc/HackerNews huggingface dataset:
Thanks!

Grabbing the sources from https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly and compiling them more or less as recommended (and unlike they are compiled in the talk):

$ clang -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done
Self-check passed
Speed: 197.2 MB/s
Self-check passed
Speed: 196.1 MB/s
Self-check passed
Speed: 196.1 MB/s
$ gcc -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done
Self-check passed
Speed: 209.7 MB/s
Self-check passed
Speed: 209.2 MB/s
Self-check passed
Speed: 209.1 MB/s

This is a baseline for us. It has nothing to do with Zig and nothing to do with Andrew's machine (hardware or compiler versions).

But wait, the page above suggests that adding -march=native might help. Indeed it does:

$ clang -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done
Self-check passed
Speed: 255.6 MB/s
Self-check passed
Speed: 259.0 MB/s
Self-check passed
Speed: 254.3 MB/s
$ gcc -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done
Self-check passed
Speed: 275.1 MB/s
Self-check passed
Speed: 268.4 MB/s
Self-check passed
Speed: 270.0 MB/s

In the talk Andrew suggests that the difference might be due to using rorx instructions, which Zig might be able to do due to aggressive loop unrolling. Does -funroll-all-loops help GCC? It turns out that it doesn't, and that it cannot, on this program, because the C code for sha256_compress is already fully unrolled.

But anyway, are we using rorx instructions at all? We are, but only with -march=native:

$ clang -O3 -S sha256.c -o - | grep -c rorx
0
$ clang -O3 -march=native -S sha256.c -o - | grep -c rorx
542

And:

$ gcc -O3 -S sha256.c -o - | grep -c rorx
0
$ gcc -O3 -march=native -S sha256.c -o - | grep -c rorx
576

[Edit: Changed the grep from "ror" to "rorx", which changed GCC's numbers a bit; it does generate "ror" without x without -march=native.]

So. Testable theories:

(a) On Andrew's machine, the same setup but with Clang using -march=native would outperform or at least match Zig.

(b) Zig's compiler internally uses the equivalent of -march=native, possibly implicitly, at least in --release-fast mode.

Nothing here is meant to imply that Andrew is dishonest. There are just lots of variables to take into account, and sometimes we don't. Also, "slower/faster than C" by a few percent is not very meaningful if even C compilers disagree by 6% or so, and the same C compiler with the right flags disagrees with itself by a lot more.
How to Check for GraphQL Errors with JMeter
0patching Foxit Reader Buffer Oops Integer Overflow (CVE-2017-17557)
> The brightest minds of our time

Would you rather they went back to doing what they have been for the last 15 years? Pushing adverts and hoarding data.
I'm sure that we'll have that figured out once we can manage interstellar travel.
Attackers Are Embracing Automation, Why Aren’t We?
btw let me know if you'd be interested in collaborating on such a thing
My wife loves her moissanite ring. We looked at diamonds last year for some jewelry and she said that she wanted more moissanite jewelry instead!
That's what we do in the Cyrus IMAP scheduler for future alarms. We set the trigger at most 30 days in the future, and at that point it will re-calculate when the alarm should fire. Using the tz database at the time each time around.

Of course, calendar events in icalendar have the tzdata stored along with them, in theory, so they should never change unless your client updates them. Which leads to its own world of fun.
Ringing the chords of the Universe: how music influenced science
"At least we're not doing planning poker" was a running joke response to any kind of crazy process stuff we were forced to do on my last team.

Maybe it works better for small projects/teams, but in my experience it's a massive waste of time.
And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.

Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc.

Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.
you have a good point that first as a technical guy I should probably not focus on learning new technologies, but how to do business and get customers
CVE-2018-11235 flaw in #Git can lead to arbitrary code execution
Apple Safari Ships Service Worker and PWA Support on iOS 11.3
Reverse emulating the NES
> There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one.

This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum.

You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.
It would often be quite impossible to determine which team scored a goal, for instance in 'scrimmage' situations, or own goals.

Plus it would create weird situations where a attacking team would stop a goal from the other attacking team on the line and try to get in on their own name.
To follow up this question: Isn't that just a gamble too? I buy a company at 10, it goes up to 20, should I get out? I think it will get to 30, the next day it goes to 2 and soon delisted.

I can vouch, I have done this. I have no idea what I am doing.
I was thinking as well that its less abstract. Biology research takes a lot time and of work to filer through to practical applications. AI research is generally doing something practical straight away.
For the curious, `:` is the noop builtin in bash. I use it mostly as I would use `pass` in python, since empty conditionals or functions are a parse error.

if whatevs; then
:
fi
The article mentions the smartphone or eventually autonomous cars will be able to time their speed to alleviate the "wait times" at the light. Its not just detection but immediate action thereafter to the vehicle, not just the lights themselves.
> If I had to pick the most destructive part of Scrum, it's the sprint commitment.

I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following:

- Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead.

- Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water.

-Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment.

- Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story.

In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems:

- Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team.

-There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this.

In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point.

Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.
There's an easier way than using dconf dump twice and looking at the diff: You can use dconf watch. http://catern.com/2014/12/21/plain-text-configuration-gnome....
No, that's like saying all lineages die out; there's no reason a company shouldn't continue operating profitably indefinitely.
Also note the historical, mind-bending three-way baseball game (Dodgers vs. Giants vs. Yankees) to sell War Bonds just a couple weeks after D-Day in 1944: https://www.cbssports.com/mlb/news/just-because-june-26-1944...
> He saved just $180 per month?

It's Northern England. he likely wasn't paid that much.
Yeah! We work around that in our logic at FastMail by choosing the largest population area which exactly matches the tzmapping data (generally it's from an icalendar file with some weird name and some rules which show the next couple of timezone transtions)

It's ugly and horrible, but that's life.
The Coming Arms Race in Smart Contract Infrastructure
You did say hash function.

Would you mind jotting down that proof?
An AI "winter" is a long period in which [edit: funding is cut because...] researchers are in disbelief about having a path to real intelligence. I think that is not the case at this time, because we have (or approaching) adequate tools to rationally dismiss that disbelief. The current AI "spring" has brought back the belief that connectionism may by the ultimate tool to explain the human brain. I mean you can't deny that DL models of vision look eerily like the early stages in visual processing in the brain (which is a very large part of it). Even if DL researchers lose their path in search for "true AI", the neuroscientists can keep probing the blueprint to find new clues to its intelligence. Even AI companies are starting to create plausible models that link to biology. So at this time, it's unlikely that progress will be abandoned any time soon.

E.g. https://arxiv.org/abs/1610.00161
https://arxiv.org/abs/1706.04698 https://www.ncbi.nlm.nih.gov/pubmed/28095195
> It's Deep Blue, not Big Blue.

Big Blue is fine - it's referring to the company and not the machine. From Wikipedia "Big Blue is a nickname for IBM"
Peeing from sufficient height also traps CO2. Can anyone confirm?
Well, I guess it could be true that some people are "brainwashed" to trade bitcoin. But I think there are some differences between the two.

First, diamond is not in itself useful. While it some industrial uses, that is not where its value comes from. The value of diamond is the result of misinfomation about its rarity and an extensive marketing campaign. On the other hand, BitCoin (or rather, blockchain) promised to be a distributed exchange, and more or less acheieves that. And although it is debateable whether its current valuation is reasonable, at least that grows organically from its use.

The value BitCoin and diamond are both influenced by their limited availability. Diamond supply is tightly controlled by a corperation, but there is no guarantee that corperation will continue to have this controll indefinitely. On the other hand the limit on the number of bitcoins is more rigid and will only break if someone took controll of at least half of the network.
This looks pretty neat! Thank you.
Cool! Check this out too (couldn't find the original link)

https://www.huffingtonpost.com/2013/05/23/led-wedding-ring_n...
What? A PRF having a secret key is not “security by obscurity.” I am documenting how the entire process works and where the security properties come from.
There's an important difference between criticizing a tradition, and criticizing individuals. The tradition, in this case, was greatly magnified by the parties who have a vested interest in people spending a lot of money on rings. That aspect of it conveys little benefit to the people who partake in it, or, as others have already noted, is even negative by encouraging people to spend too much of their income at a time in their life when they really ought to be focused on saving and making efficient use of their funds.

Rituals are good. A gift exchange can be great. A visible symbol is important to some people (I wear a wedding band and I like it). But the current tradition encourages something financially foolish for most modern couples.
What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences."

This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig?

What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
Cabal uses a SAT solver. It's in the middle of a beta for replacing it's global package management with per-project package management by default (so-called new-style builds). There were some warts in the past when it couldn't manage different versions of the same package, I think because of a ghc issue but that is in the past.

Most industrial users use stack or nix on top which reduce the use of Cabal's version solver.
One of the more silly articles on HN in a while. Waymo has cars as I type this driving around Arizona without safety drivers.

People were freaked out by the Google demo of Duplex a couple of weeks ago as it was just too human sounding.

Can give so many other example. One is foundational. The voice used with Google Duplex is using a DNN at 16k cycles a second in real-time and able to offer at a competitive price.

That was done by creating the TPU 3.0 silicon. The old way of piecing together was NOT compute intensive and therefore doing it using a DNN requires proprietary hardware to be able to offer at a competitive price to the old way.

But what else can be done when you can do a 16k cycles through a DNN in real-time? Things have barely even got started and they are flying right now. All you have to do is open your eyes.

DNN - Deep Neural Network.
The principal/agent problem.

insurance, auditors, government regulation, government backed loans. All have their own problems with this.

I know in mortgages, appraisers are randomly selected. Where as before they were selected by the mortgage company for what value they could get for the house. The problem now is they have no accountability to anyone.

part of the problem in health insurance consumers aren't price sensitive so prices just keep going up. (obviously they're are more problems that that)

governments have regulator capture issues.

shop your auditor(regulator) is a problem.
Not true for KDE. We (the developers) like the UI/UX people. The main criticism from users seems to be that KDE UI isn't polished enough, which is not exactly sending away those who want to improve it.
Yes - if nothing else that burns much less of our limited energy supplies.
In theory, companies pay dividends, and the price of a stock is effectively the time-discounted value of all future payments (including any final sale).

Separating that from the “bitcoin” part of a stock’s price is, of course, the major question.
Why and How to use a Password Manager?
The purpose of all the jargon that Scrum introduces is to avoid naming collisions with prior terminology.

You probably have a good idea of what a product manager should be doing but someone else in a different company might have a different opinion. Introducing a new term eliminates this source of confusion.

Admittedly, all the jargon you encounter when learning about Scrum can make you feel like you're joining a cult. However, there is a reason behind introducing it.
Affine subscripts: strength reduction for array indexing in early Fortran
Oxygen is also present everywhere these problems occur, so clearly oxygen is at fault...
Kepler.gl: Uber’s Open Source Geospatial Toolbox
Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it".

Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective ownership aspect. Product owner gets to set priorities, but it should be a collective discussion. Every dev should be allowed to express their opinion and it's the job of the product manager to referee.
A lot was going on with Java in the early days. On the one hand, SUN resisted it, back when Java was not open source, then open source but with a heavy hand on it.

On the other RM Stallman also resisted everything Java, because it did not mesh with his vision of the future. (Prop up everything GPL, unless the proprietary solution is already an industry standard.) My favourite example was how GCC was on the cusp of getting a backend which could emit Java byte code. Imagine that!

That could have kickstarted all the JVM languages a decade earlier. Alas, many forces were against such things.

Now, we have everything on everything, but most of all Javascript everywhere. Weird. :-)
I'm not confused :-) Maybe I don't set it out clearly enough, but I'm criticising Scrum as it is widely practiced, rather than how it ought to be done.

And yes, integrating it with the rest of the company is the biggest question, e.g. if you really are agile, what does your sales team tell customers about future upgrades?
They made enough money in a volatile unregulated market that their salaries seem minuscule. So, they go and burn more of their money in the same volatile market at this time. What can go wrong?

May be they took some money out of their quick earned profits, and saved enough for their life. The rest is what they are going out to gamble with. Now that doesn't seem unreasonable.
> I don't really feel like the pure knowledge of what world we live in by itself would have much impact.

If we live in a world where P=NP, I think there would be a fury of changes in crypto, because a constructive proof wouldn't be far behind. Once people know something is possible, they quickly find a way to do it.
Maybe the fact that everyone becomes old, whereas with other protected classes, everyone does not eventually gain membership into that class. So society as a whole is more sympathetic to discrimination that favors the older maybe because we can see ourselves in their shoes.
There's no trading floor any more, mate. Well at the very least said floor is a quiet place. Its all hft and electronic trading these days.
No, you are absolutely right. And modern transfer learning improves this even more in many domains.
> done right it is effective.

That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum?

I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover.

I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.)

And

> apparently it has to involve something called “Jira”.

hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better.

Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira.

We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial.

I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team.

I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.
It's the same in ksh at least, so one is covered in the BSDs. It could be also implemented as a separate tool, but not as convenient, because of additional quoting - I did once.
Common Pitfalls of DevOps and How to Avoid Them
Self-promotion is a plague in this industry. First page of Google results regarding any JS framework topic is some marketing folks aiming to be hired/contractors, promoting outsourcing/nearshoring location, without any meaningful content created. Then this laughable community celebrities and "authorities". Crockford, Zakas, Souders, Resig - ever heard of them? In three years nobody will even remember or care about that Angular-Google guy, or React-Facebook guy, or ngrx-whatever guy... except those who end up maintaining some legacy codebase and cursing the universe.