skysight-inc/HackerNews huggingface dataset:
Building a Distributed WaitGroup with Go and Redis
It's more for consistency. You can still forget to use a not_null.
The fact that rmxt brought up some problems with a different story that Eichenwald wrote in this context is an ad hominem. Besides, there's no need to trust Eichenwald, the stories he links to are written by others, and the bulk of his article is argument, which you can agree or disagree with without any trust being required.
I've been in search of a good time-series database solution for some time now, and have pretty much given up on it and am in the process of rolling my own: https://github.com/grisha/timeriver

My issues with the present state of TS isn't the volume. I was looking for using TS outside of the DevOps world. Everyday things like your heart rate over time, price of gas at the nearest station, number of people in line at your coffee shop, etc. All these are interesting, and Graphite/RRDTool/InfluxDB/etc did not seem like appropriate storage, because to use it with your other data (which is most likely in a relational DB of some kind) you need to export/import it and who wants that.

I call this problem "data seclusion". When data exists in some kind of an incompatible format (e.g. Whisper files), it will end up ignored because of that extra conversion step necessary to link it with your other data. Data in Graphite and such is mostly good for generating charts, but TS analysis is so much more than that, even at its simplest.

I think that the good old relational database is fine storage for TS and we gave up on it way too early, especially given what's new in PostgreSQL. Making it horizontally scalable, distributed, using consensus protocols, etc - these are not time series problems, these are database problems and we do not yet have a good solution for these. (We have many that "kind of" work, support some features but not others e.g. Cassandra). Projects like InfluxDB are mired in solving the wrong problem which will eventually get solved at the DB level.

More thoughts on the subject: http://grisha.org/blog/2015/03/28/on-time-series/ http://grisha.org/blog/2015/09/23/storing-time-series-in-pos... and http://grisha.org/blog/2015/05/04/recording-time-series/
SoFi does mortgages now, seems like they started about a year ago. They seem to be willing to do a non-conforming 30 year fixed for pretty close to 4%.
Deregulation in Texas has spurred intense competition for customers.

Huh. Who'd a thunk it.

made possible by the nearly universal distribution in recent years of residential smart meters

This is key. Demand-based metering and pricing has been available for industrial customers for a long time but residential customers had dumb mechanical meters that only recorded total kilowatt-hours. This sort of thing will also become important as electric cars become more mainstream, to encourage people to charge cars at low-demand times. Otherwise everyone plugging in their car at 6pm when they get home from work, while also cooking dinner and turning on the A/C is going to stress the grid.
I consider my work (more debugging/analysis than anything else) more related to plumbing than programming. Can I call myself a digital plumber?
Not if you're calling into an API that uses not_null; it will automatically insert the null check.
It was 't from Infocom (thanks for that link). I just remember it weirded me out and it had a really generic name.
Ask HN: What can make me more lazy?
Hey Community!

I love to write automation scripts and also like playing with my IoT devices (Particle is amazing ^_^). Having said that, could anyone suggest me some script to write, which could possibly make me more lazier.
Thanks again everyone.
Starting an infosec career
I've got to call bullshit on this one. Sure SOME engineers need certifications, but most do not. Pretty much just the ones that build buildings/bridges here in the US. I've got 2 engineering degrees(CE/EE) and when I got out college, I took the first half of the PE exam (need to take the second part after 5 years in the field to be a PE) but the only reason I took it is because it is almost impossible to pass after you leave college since it covers the entire field, not just your specialty. It was a "Better off safe" sorta thing. All my professors basically said an EE/CE will never need a PE but you never know...

That said the term Engineer is definitely watered down, but this has been the case at least as long as "Custodial Engineer" has been a term.
Wow that's awesome. I decided to re-implement divisiblity by 7 in this manner, since integrating with <horrible system> could wait a few minutes. :)

https://gist.github.com/62553ded59ec7e289be6

Edit: s/division by 7/divisibility by 7

Thanks for pointing that out, omaranto!
The obvious answer is that the library may not do what you want. Some examples of what browsers want to do with images in different circumstances:

1) Just determine some metadata about the image (size and a few other things) but don't decode the pixel data yet.

2) Asynchronously decode the pixel data on a separate thread, notify when done.

3) Synchronously decode the pixel data on the current thread.

4) Asynchronously decode the pixel data on a separate thread, notify as you go. This can have variants along the lines of "Progressive JPEG" as opposed to just delivering more scanlines.

Now ideally a good library would in fact let you do all of this as needed (e.g. Firefox just uses libpng for PNG decoding, though even there it's patched locally to add APNG support). Not all image formats have good libraries.
True ultra long term storage with decent storage capacity could prefix each and every binary files with an ASCII text file detailing the file structure on the binary in enough detail that a competent programmer could write a parser.

If you were still worried about that, all binary files could be duplicated in ASCII (minus formatting etc.)
It looks like they (deliberately?) didn't mention the open source projects that were specifically build to address the shortcomings of graphite, like prometheus or opentsdb.
I agree. The vast majority of people in the world have access to housing, water, internet, toilet, transportation. Yes, they might have their own motorbike instead of car, but really, the qualitative difference is not the 10x as suggested by the difference in prices of those two things. Sure, the sidewalk sometimes is very rough, and the drainage on the side of the road carry heavily polluted water, and the outside of houses might not be painted. Inside most homes around the world, however, are quite pleasant.

Give this house a fresh coat of paint, and it'd fit just fine as a home in a developed country: http://i.dailymail.co.uk/i/pix/2010/03/05/article-1255622-08...
I'm responsible for a solution at $dayjob where I ended up feeding the data into multiple sources. I basically have incoming "events" and they get fed into Sentry (which in turn stores them in MySQL and Redis), InfluxDB (to use with Graphana), and soon Elastic Search (to use with Kibana). Each of these just provides a different way to visualize the data.
Can we build such state diagrams to check divisibility by other digits too?
You could always go "old school" and read from the old MIT "AI Series" papers. This stuff goes back to basically the very, very beginning of AI:

http://publications.csail.mit.edu/ai/

Also consider that the IJCAI (International Joint Conference on AI) publishes all of their past proceedings online. Of course, going to that site is like drinking from a firehose and I can't give you a good curated list of the best papers to read, but maybe somebody else has such a list.

http://ijcai.org/Past%20Proceedings/

If you want a book with some interesting stuff in it, here's one for you:

http://wps.aw.com/wps/media/objects/5771/5909832/PDF/Luger_0...

You might also look at the "classics" section on AITopics.org: http://aitopics.org/classics

Unfortunately some of the links are to pay-walled papers, so not too helpful if you aren't looking to spend money.
Thanks to whoever downvoted me. Seems I am arguing against people who downvote against the spirit of the rules and who can't even spell the thing they are talking about..

Regarding your point siliconc0w as I say in my other comment diets are experiments. Let's not conflate "my diet can defy the laws of thermodynamics" regarding weight loss with a diet directed at a different part of health. Nor should we forget that people can experiment with diets knowing the limitations of self-experimentation whilst simultaneously supporting double-blind peer reviewed work. Conflating people on a diet for the relief of symptoms with people on a diet because they think it suspends the laws of the universe is stupid, suggesting people with symptoms aren't allowed to experiment on a personal level while science grinds away at more solid conclusions is also stupid.

The second point is one of elementary reasoning. If someone points to a pile of papers with some published in 2014 and 2015 then a paper from 2013 with includes a couple of trials of ~30 people and ends inconclusively isn't a trump card. The paper, if you actually read it, makes no bold claims at all and is more of a meditation on how to methodologically advance our understanding, i.e. how to design experiments to exclude hidden coeliacs with better tests for them, the question of how gluten and gluten-free diets testing for NCGS need to control for FODMAPS, dairy and the like. They literally end with "Non-celiac gluten sensitivity is an entity awaiting validation, better diagnostic criteria, and, if it does exist, pathogenic mechanisms". And the studies they cite had mixed results on small n, again it's about more and better designed studies which I am sure those authors would agree on. But they were all just looking, as far as I can tell I didn't go to the studies they themselves cite, at basic symptoms. The MRI brain data came along in 2014, after all this.
> I'd love to see some independent org do an independent review of the strength/merit of the claims of each arbitration case, and whether there is still bias "accounting for that"

If only we had some independently-funded institution responsible for doing exactly that.
And the main reason I didn't buy a tractor is because a tractor would let me to start a farm.

The point is, people have different needs. Some like getting notifications on their wrist. Myself, I like smartwatches more for the input side - ability to control stuff without interacting with the smartphone directly.

Also, that's good that some people just don't see the need for it. It means the tool is useful. I hate the trend that hit the mobile market (and already affects the smartwatches) that makes companies design for lowest common denominator - it means people like me, who would like to use a specialized, feature-laden device can't get anything, because they don't exist on the market.
9pm - 6am sounds like prime Bitcoin crunching time.

It was my understanding that the limiting factor, or rather the "cost" of mining bitcoints, ultimately comes down to power consumption. Effectively if $/kWh * kWh/bitcoint < bitcoint value, you can turn a profit.
Yes. Malloc is a really good example of this, where malloc returning NULL indicates a fundamental resource is not available. If you dereference the pointer returned by malloc under those conditions, your program crashes, just like if you were to not catch an exception thrown at instantiation-time with a reference type. You should absolutely use NULL to represent the absence of some fundamental resource, like memory or a device. To the extent that a device is memory-mapped, it's the same thing.

NULL is just a tool. It's just a way for you to express some property of your API.

That said, some of the strategies outlined in the article could be very useful for avoiding use of pointers. Use of a class type implementing an interface as a "null type" is a very good strategy. Such a type could guarantee successful instantiation, and so avoid the need to throw exceptions or otherwise crash entirely. You could architect an application with those strategies and completely avoid the use of NULL and nullptr entirely.

But where your program is dependent on a finite resource, you must have a way to represent the absence of that resource. NULL and nullptr are convenient ways to do that without a ton of extra code. So no, don't avoid NULL.
Indeed so.

http://www.computerhistory.org/groups/storagesig/media/docs/...

'The drive, a 7,200RPM Deskstar 75GB drive, was released on 15 March last year [2000]. At the time, the press release announced excitedly that the drive was "the first IBM drive to use glass disk platters instead of aluminium ... allowing the recording head to read smaller bits of information that are packed more closely together. In addition, glass disks are more stable at higher speeds".'
That is only a test for divisibility by 7, not 'division by 7', which is typically understood to compute the quotient.
Is it the case even with the latest Grafana (2.5) that you still get more functionality by running graphite-influxdb as a middleman?

I have Grafana 1.9 pointed directly at InfluxDB 0.8 and here's one thing you _can't_ do: group a series by X, then plot only the top Y groups. Is that the sort of thing that using graphite-influxdb provides?
How to Rip and Convert DVD to MP4
This gave me an unreasonable amount of pleasure doing.
Buy Experience, Not Things
Yeah, that's probably the scenario with the least friction.
The author most likely didn't mention them because they suffer from the same limiting assumptions that graphite does. When you're dealing with multidimensional changing metrics, opentsdb has the same issues graphite does.
Yes, it's easy: to test divisibility by n make a graph with n verities labeled 0 through n-1; put black arrows from each vertex k to (k+1) mod n; and put white arrows from each k to 10k mod n.

(That's for testing divisibility by n of numbers written in base 10; for others bases just replace the 10 above.)
The courts often suck, but the answer ought to be to fix the damn courts, rather than the default knee-jerk answer of American politics: "let the market decide".
Dereferrencing NULL will not always cause your program to crash.
Created a fork with a solution.
Living and Dying on Airbnb
And where does the information about the ASCII format go?
Yup!

If we're trying to compute 3256 % 7 and we know that 325 % 7 = 3, then 3256 % 7 = (325 * 10 + 6) % 7 = (3 * 10 + 6)

Computing 10 % 7, 20 % 7 etc generates the white arrows.

I think unless we're checking divisibility by primes, though, the white and black arrows won't share edges
Because people forget to provide null checks.
Same with binaural sound. Mono was good enough for Miles Davis, it should be good enough for everyone.

No, seriously, your comment is useless. OP said he likes it for video games & you don't even address that.
The topic was the banning of Sati. It was just one example of the benefits of British rule. That it is such a salutary example is why I mentioned it. You are welcome to keep crying on Twitter that people said things you don't like but I have nothing further to say to you.
Can some one change heading so it is understood as software and not actual Graphite
It is amazing that so many societies in the world are able to function well, considering the pathetic nature of their legal systems.
Unrelated(ish), but thanks for mentioning libguestfs! I've been passively looking for the solution to the non-root filesystem access problem for a while.

Also, PSA: this project has a program that can read and write Windows registry hives.
Indeed. I wonder how long this can last before the surplus wind power is used up by bitcoin miners and residential aluminum smelters.
Had a guy interviewing for an intern position once say, after my coworker showed him a bit of code, "the biggest file I saw today was 500 lines, so I'm pretty sure I can handle it. I'm used to working on PHP scripts with thousands of lines. Now that's scary." He lost my vote in three sentences.
Enumerating some techniques for avoiding NULL is useful, but it sidesteps the real issue. It is important that programmers understand that avoiding NULL will not suddenly make your programs robust.

Generally speaking there is really only one case that you need to think about: what do you do when a function needs to return a value and it has no value to return. This often happens in error conditions, but it can also happen as a result of poorly designed code (for example the ubiquitous "doUpdate()" function that sometimes returns a result and sometimes doesn't, based on what was passed to it). I will maintain that initialization is a special case of this (I haven't initialized it yet, so I have no value to put in it).

However, more important than what you use to represent "I don't have a value" values, is what you do with it if you get one. In several of the examples in this article, a boolean is returned to indicated whether or not you have valid data in the parameters passed by value. This may seem "safe" because you don't crash, but there are often much more serious problems than crashing: data corruption, for example.

Let's consider the case where I gather some data from somewhere and write it to my database. In the case that my data collection failed, I certainly don't want to write random data that was returned in the parameter. What happens if the calling code neglects to check the boolean return value? This check is identical (and could literally be identical) to checking for NULL. The only difference is that if I try to an uninitialized, but valid data structure to my database, it will work. If I try to dereference NULL, it will crash. In many cases, crashing is preferred.

Even when you return a NULL Object, you still need to think very hard about what you want to do with it. What happens if someone tries to write a NULL Object to the database? We know things are very, very wrong. We could just skip it, but many times it would be prudent to halt execution of the program.

Too often I deal with programmers who blindly accept the advice that NULL is evil without actually understanding the problem that NULL is intended to solve. I have no problem with avoiding NULL (and in many cases it is a very good idea). It is important, though, to understand that you still have a lot to do to write robust code.
Well, many of the concepts of the lisp machine are extremely relevant to the current design problems of today's CPUs, primarily around security and privacy. The continuing disaster promulgated on the world by languages such as C can only be solved by enforcing type safety and bounds checking in hardware. There continues to be progress in making these easier and more efficient to implement. I'd suggest looking at the SAFE architecture papers, especially the low-fat pointer paper: http://www.crash-safe.org/papers.html
IMO that's even more of a reason for this. If the world continues normally, then old hard drives and CDs can just be copied onto new ones over and over again. If something ever happens, then everything will be lost. With this, we could preserve a huge amount of the world's knowledge forever.

However I see what they are trying to say. 300M years is a lot, when even 100 years would be great compared to current storage systems. And on that time scale, the rate of bit rot is less important than other factors.
Detroit Businesswomen Team Up to Get Rape Kits Tested
Well if the money is locked in, then all we're talking about is a prearranged spending limit, right? But I've just never heard of investors wanting that. They already have a lot of influence. And the whole goal is to get to the point where the startup will need (and spend) a lot more money.

If it were my money, I'd certainly be concerned with young founders overspending. But I'd solve that just by energetic board meetings and occasional calls with the CEO. And with VCs, it's not their money anyhow. Their constrained resource isn't cash, it's time.
FF, recent on Ubuntu, i5, works fine.
This "walk on a graph" is known formally as a Deterministic Finite Automata. One of the interesting results of automata theory is that every FA has an equivalent regular expression (a subset of the "regexps" in most modern programming languages).

Where is this going? Behold, a 12,701 character regex for divisibility by 7: http://codegolf.stackexchange.com/questions/3503/hard-code-g...

This doesn't use any recursive features (it is a real Regular Expression in the theoretic sense) so it can be checked in linear time.
Aaaand the jawdrop happened when I reached the last word in that sentence. Wow, kudos.

Know of any cool videos or anything similar that demo UEFI functionality on AA64?
Nothing stopping you but some NIMBYs who don't want the wind farms from spoiling your views.
Useful but dangerous:

If you have (1,2,3,4,NULL) as data in column foo, and you query

select foo from tbl WHERE foo!=1

Returns:

2
3
4

Which, makes sense, but can be very confusing if you're not explicitly looking out for it.

Redshift (and I think Postgres generally) will also, very confusingly if you're not aware of it, return no rows if your subquery returns any NULL values in a NOT IN scenario.

If bar is (1,2,3,4,5)

SELECT * FROM bar WHERE foo NOT IN (SELECT foo FROM tabl)

Will return no results (instead of a single row with 5).
As the adage goes: a fool and his money are soon parted.
NULL is just a tool. Non-optional nullability on all pointer types is a blight. 99% of APIs want to say "returns a guaranteed-valid pointer", and "takes a guaranteed-valid pointer", and have the language enforce those guarantees. C and its siblings just give you a "might-be-valid pointer" type, which introduces NULL into every API you create, whether you want it there or not.

I do agree that there's no fundamental difference between using a "might-be-valid pointer" vs. a sum-type (Option/Maybe/etc.) to indicate nullability. However, it's usually easier to get static analysis of the sum type—most type-inferencing compilers can ensure that when you destructure a sum type, you provide match-clauses for every possible instantiation of the type (i.e., for an Option type, they ensure you do the equivalent of a NULL check, and handle both the NULL and non-NULL cases), and so forth.

What I'd really like to see, though, is a language with data-parameterized "types" that unfold (as a last resort, when the concrete type cannot be inferred at compile-time) into runtime data-comparison branches. You should be able to have a raw may-be-valid address with no metadata tag, and then treat that data as having a separate type (a Just or a Nothing) depending on whether the memory address itself is nonzero. You write match clauses; the compiler turns those into NULL checks.

(As an aside, such a language would also allow for things like a type for "Float that only has an integer component", or "Even number", or "Positive number", or "Number in the range 5..23", or "String of length 5", or "String that encodes a valid Unicode codepoint sequence", etc. The type system would become your swiss-army knife for expressing invariants.)