skysight-inc/HackerNews huggingface dataset:
> A bold claim without evidence. In fact, the opposite may be true [1].

> [1]: https://www.bloomberg.com/news/articles/2017-12-08/the-bitco...

The same can be said about any money system in a capitalist economy (e.g., 1% owns 40% of the wealth in the US [1.1]).

> This is but one counterpoint; another notable problem is the centralization of bitcoin mining in China [2].

I'm not sure this is 'looming' today as the article boldly claims, but centralization is definitely a risk. It's important for everyone to participate in the system as they can for a more equal distribution of ownership - akin to how one should exercise their vote in US elections.

[1.1] https://en.wikipedia.org/wiki/Wealth_inequality_in_the_Unite...
I wonder what things would be like when phone cameras are as good as human eyes, the climax of consumer photography?
I'm experimenting with GPU based 2D rendering using signed distance functions as drawing primitives for quiet a long time now. My experience is that as soon as the object tree exceeds a certain size the CPU will always beat the GPU. The only way the GPU can win is when you have high complexity drawing primitives and a low amount of objects which is exactly the opposite one usually encounters in the real world. Maybe the partitioning approach you are proposing will help but only real world implementations and benchmarks will tell.
They should make a CLI tool, it stores your processed images one sec before it is invoked!

See also:
https://en.m.wikipedia.org/wiki/Thiotimoline

The major peculiarity of the chemical is its "endochronicity": it starts dissolving before it makes contact with water.
I am a developer. My go-to answer for "What is your weakness" type interview questions is that I am bad at estimates.
Irrefutable and "unequivically" true if you take some classical FOL as a productive method of producing knowledge, a philosophical assumption. Philosophy came first, mathematical logic is just a formalization of that and the reason it was formalized at all and not somethimg else is epistemological.

Your entire argument attempting dismiss philosophy is philosophy.
Relatedly, I'm curious about different ways that CS education can be framed. Speaking to teachers, one of the main reasons why many kids (and, crucially, parents) aren't interested in CS is the misconception that you can't be creative with programming. When kids find out that this is not the case, engagement rises. (There's also the point that CS seems to invariably be folded into programming, but I'm not sure this is the biggest problem.)

I wonder what the impact on uptake would be if the focus was shifted towards CS as a venue for building things and being creative and away from lines of monowidth code and indecipherable errors. More to the point, I wonder how this might be done.
Agreed.

The article claims that "Importance also makes a lot of sense" but actually, the way it was implemented in CSS makes no sense because eventually, given a sufficiently old stylesheet, all styles end up being marked with !important and then you're back to relying on source-ordering.
Your brain doesn’t make a 2 dimensional image based entirely on photons entering your eye. You generate a complex physical model of your surroundings based only partially on visual input and rely substantially on memory.
I have a love/hate relationship with numba. On one hand, the minimal setup is excellent. On the other hand, it has so many limitations and rough patches that occasionally we have been forced to abandon the numba code and reimplement in C -- by which time we've spent more time fighting numba than the C reimplementation takes. This has happened twice out of 5 major recent attempts to use it.

---------------

Numba CPU is pretty good. I'd recommend it, modulo some expectation control:

* In order to actually compile a function, it must be written in a very minimal python subset that feels like C

* Numpy is only partially supported in this subset. Expect to manually reimplement ~1/3 of your simple numpy code and all of your fancy numpy code.

------------------

Numba GPU is not good. I'd avoid by default, unless you're looking for a project to contribute to:

* When we first installed, it was trivially broken by the removal of a long-deprecated CUDA API that had happened a year prior. It was an easy fix, we just chopped the reference out of numba, but it was a bad sign that foretold problems to come.

* It has lingering subtle bugs. One time we passed in a float array, it made us declare the float type three times (silly but not bad), and then it ignored the types and silently binary cast to double (bad). We found a "ghost town" thread where others had the issue.

* It has severe structural limitations. To a first order, GPU performance is all about avoiding stalls, which are usually triggered by CPU-GPU copies, and Numba's limited buffer abstractions sometimes make that difficult (you have to destructure your code) or impossible.

* It doesn't play well with nvidia's perf tools. If you're doing GPU, you're after perf, and GPUs have lots of tricky caveats that can accidentally tank your perf, so this is a much bigger deal than jupyter (until recently) missing a debugger.

* If you're wondering if numba supports CUDA API XYZ, the answer is no.
> Anecdotal evidence (i.e. very low error rates during ZFS scrubs) suggests that manufacturers underrate their drives and they are much more reliable than that, but it is something to keep in mind.

I've seen plenty of drives returning invalid data with correct CRC over the years. On reliable server-grade Xeon + ECC hardware. Of course the vast majority of drives never do it, there's just no way to know which ones do until it happens.

Firmware bugs in weird corner cases? Cosmic rays? Perhaps, but I think it's more reasonable just consider it one of those weird things that occasionally Just Happen (TM) and just need to be protected against at a higher level.

All drives produced in the last 30 years or so are running ever more complicated software stacks. For example they all have features that move data at risk to safer locations without the host system requesting or even knowing about it. Their physical (like bits on spinning rust or NAND flash block) and logical (what the host sees) data representations can be completely different.

Plain old CRC errors, though, are way more frequent. I feel much more comfortable about those errors, at least the drive knows the data is corrupted.