mjschultz

Both my cats get up on the refrigerator easily.

I was curious so I decided to post some of the Google links about this:

* man page: http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....

* Q&A style blog post: http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubunt...

* A "why this is scary" blog post: https://tim.siosm.fr/blog/2014/04/25/why-not-ubuntu-14.04-lt...

I'm referring to this code on the originally linked page [1] (you'll have to scroll back a bit because your header blocks the content).

In the context of this thread, brghts states that this is dangerous because if you compile with -DNDEBUG the assert is optimized away.

So if I copy that code with the assert statement, it will be optimized away and your code no longer performs the NULL check. This is bad.

As you mention, beginners tend to copy code off the Internet and cause bugs. If you recognize this and claim to be teaching people you should not use bad practices in your example code. Period.

If you don't want to muddy the waters with your custom debug macros, then you should still play it safe when checking return values the a beginner may simply copy and think is correct.

[1]: http://c.learncodethehardway.org/book/krcritique.html#code--...

In a chapter about deconstructing someone else's book, your own book also does dangerous things according to yourself:

> The problem is, as with every book with code ever in the universe, beginners will copy that code out and use it somewhere else and then the function is wrong.

Yet, if a beginner copied some of the code in this chapter they'd have the exact bug you are talking about here (using the NULL pointer returned from malloc()).

I think you should probably expand that into the safer checks (don't forget to free(line) if longest is NULL too!).

I seem to get a 500 error page whenever I search for something along the lines of "NOT label:css". I was hoping to be able to find issues that are not labeled as something.

Other than that this seems like a great improvement!

You might want to check out the CELERY_SEND_TASK_ERROR_EMAILS configuration option: http://celery.readthedocs.org/en/latest/configuration.html#c...

Here is his response to that question on the mailing list:

http://mail.tarsnap.com/tarsnap-users/msg00846.html

That code should only create the dict/namedtuple instance once, then access it many, many times.

The creation occurs in the --setup portion. The field accesses occur in the actual looping portion of the timeit code.

The --setup code (creating the namedtuple and dict) is only executed once.

The timed portion is simply the field accesses.

Does the --setup statement really get timed?

My reading of the docs[1] has always led me to believe that it doesn't. For example, "It is possible to provide a setup statement that is executed only once at the beginning"

[1]: http://docs.python.org/2/library/timeit.html

I'm probably doing it wrong but I measured exactly this yesterday and the dict version was faster:

    $ python -m timeit --setup "from collections import namedtuple; Point = namedtuple('Point', ['x', 'y']); p = Point(x=0, y=0)" "p.x + p.y"
    1000000 loops, best of 3: 0.284 usec per loop

vs.

    $ python -m timeit --setup "p = {'x': 0, 'y': 0}" "p['x'] + p['y']"
    10000000 loops, best of 3: 0.0737 usec per loop

Maybe the use isn't right because I agree with your belief that namedtuple is suppose to be more performant.

To answer your question directly, no I don't think so (perhaps some updated theories, but nothing concrete).

But the article does cover more than just the incident, I found the whole thing fairly interesting.

Beyond the passing knowledge I have from growing up in Chicago-land around the time and the Wikipedia article on the subject, I thought it contextualized the FCC policies around the time of the incident and how the hack worked (from a high level). It also pointed out other signal intrusions from the same period and the FCC/FBI's methods to track down the perpetrators.

Also, here is the Wikipedia article on the matter [1]. And a Reddit thread (presented as one of the theories in the article) [2].

[1]: http://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_i...

[2]: http://www.reddit.com/r/IAmA/comments/eeb6e

For anyone interested in looking for at this, here is the wikipedia article: https://www.wikipedia.org/wiki/Flow_(psychology)

Safeway is called Dominick's in Chicago (Safeway Inc. purchased Dominick's in 1998, but left the name because branch loyalty I would guess).

Source: Former Chicago native that purchased Safeway branded food at Dominick's.

I think their policy is typically to update to the latest model if the order hasn't shipped yet.

The same thing happened to be when I ordered a MacBook back in 2007, where a few days later they announced better specs and I got a notification saying they updated my order to reflect the changes.

It's one of the reasons my next laptop will probably still be Apple.

Or you're reading it upside-down, making it "06/" which would mean it was taken in June (much less surprising since it is now early July).

Here's a previous discussion of this post as well: https://news.ycombinator.com/item?id=5600883

It's also using dygraphs javascript visualizations for the timeseries instead of Google Charts.

Here is a recent discussion on chromium-dev about the password manager: https://groups.google.com/a/chromium.org/forum/#!searchin/ch...

Evidently, only 0.0085% of users toggle on the "Use a master password"

But if there is already malware on the user system, it just needs to wait until the user authenticates once in Firefox to get the master password, then it can fetch all the other passwords. Right?

Before everyone gets their pitchforks out, why don't we look at the URL and see that it has the "sample-" in it? Meaning that this is an example of words that can be filtered. It IS NOT a list of words Disqus automatically filters.

There is a filter tab in the Disqus admin area, one of those tabs is "filter," here is the text around below the restricted words input box:

"Separate words with commas. You may use .* (dot asterisk) as wildcard, but be careful not to be too aggressive. For example, s.*ck will match suck, but also sock and stack. Words must be at least 3 characters in length.

Here is a sample list of restricted words[1]."

[1] http://mediacdn.disqus.com/1362527340/sample-badwords.txt

Oh yes, in this case there is almost no risks for the client but I'm assuming someone will make a django plugin/ruby client/whatever plug-and-play version of this which may not have the same low bar of getting subscriber content on a site where paying is opt-in only.

(I wouldn't mind my bank using this, it's better than what they have in place...)

> It seems a bit harsh to judge the strength of an authentication scheme on the metric of "How well does it stand up to a system administrator storing and serving publicly all in-use authentication credentials?"

Is it harsh? Would it be harsh to judge an authentication scheme that stores all passwords in plaintext? Server logs don't typically contain data that should be considered secret. IF this authentication scheme led to secret information being stored in a file that wasn't expected to be secure, that would be a major problem, wouldn't it?

This type of authentication hasn't stood up to a large amount of scrutiny, so it is important to think through some attack vectors that might be opened up. This was one I thought up, but it isn't an issue since the tokens are one-shot.

For the record, I like this authentication scheme but that doesn't mean it shouldn't be challenged.

> The URL is only valid once

Hmmm, it looks like you might be right. I tried it earlier with one in a private window and it worked twice, but when I just tried again it was invalid/expired (though the email is 50 minutes old).

And I certainly agree that if the server is compromised you've got more problems, but in the IEEE example the server wasn't hacked they just made a mistake by making the logs available.

Edit: yup, I must have made a mistake (not closing private window or using non-private window) in my test.

Wouldn't the URL be in their web server logs? Since the URL only last for an hour it would be a small window (plus their web server was hacked), but you could access other user accounts that way.

Usually username and password are sent via POST not GET so the logs don't have that data (unless you're IEEE and user GET and have your logs available through FTP).

I would assume the cookie is still valid and you're authenticated, or you type the email address and you get a fresh token.

The deluge wouldn't be worse than a targeted attack with a reset password style system, right?

Your mobile device has email, right? Mine does. You'd just type your email into the site on mobile, then get the link for your device's browser. You'd have to type email, app switch, the click link. I don't think that is too bad actually.

Unless Spotify has some backdoor API with Facebook, it seems like a major oversight in the Facebook API that an (any?) app can re-register a deactivated account and give itself whatever permissions it wants.

Just because Spotify accidentally (or purposefully) took advantage of that hole doesn't mean it's not Facebook at fault here.