mjschultz

`bcp` assumes `make` and `gcc` along with a handful of devel headers are installed.

You might still have the correct values in your DNS cache for the sites. It looks like the .pk registrar was hacked and the DNS for these site changed.

Since you're in Pakistan, you've probably recently resolved some of these names so you'd get the correct version.

I don't know about tumblr.com, but stackoverflow doesn't allow their site to be viewed within an iframe (security reasons). Nor does facebook.com or google.com. I also hope most banking sites wouldn't allow this.

That said, it seems like a useful tool when you are the developer and want to see how it renders for different viewscreens.

Wouldn't stripe's server logs also have the get params in cleartext?

Here is the Google Moon view of his landing site:

http://www.google.com/moon/#lat=2.460181&lon=23.708496&#...

If there was a moment to use QR codes for something useful it would be that receipt. The last thing I want to do is type some 34 character case-sensitive id into my browser to get my money.

Interesting. I may have accidentally stumbled on this hack a few years ago when I was sitting in an airport.

I had downloaded the (I believe) Boingo iOS app, which works by performing an in-app purchase for the amount of time you want to use their wireless network in the airport. I followed the directions exactly as specified, but instead of getting a "Purchase Completed" message I got a "declined" message. Despite not having paid for the wireless network time after that I was still able to connect and use the Internet without problem.

It may be that because un-authorized users are sometimes given walled garden DNS settings, it was causing a bit of confusion within the in-app purchasing system that results in free wifi for me.

(My alternative explanation is that I hadn't updated the expiration date on my credit card, so the purchase was declined but Boingo's app didn't differentiate between success and error from the App Store's system so I got the wifi anyway. I think this explanation is still the likely candidate.)

In any case, I told Boingo about the bug when I found it and after convincing them that it was their job to fix it and not mine. Since this was a few years ago I hope they've fixed the problem.

1. Press and hold a finger in the blue area (do not move this finger)

2. Tap a second finger somewhere else in the same blue area (again, do not move your finger only tap)

3. Observe the orange bar. It should become green when both finger are touching the screen. Response time should be near instantaneous. It is not. Additionally, about 1 out of 3 touches results in an inconsistent state in which the bar remains green after both fingers are removed.

I'd remove the "straight down" part altogether.

(Sorry, I misread the above post, but I believe LDLIBS is the Makefile built-in variable for libraries to link.)

Actually, in this case, I believe LDLIBS would be more appropriate since the OP isn't passing any flags to `ld` but rather the libraries for `ld` to link. I ended up getting hit be this in a simple Makefile a few weeks ago that worked in Fedora but failed in Ubuntu.

The target was "%.o: %.c", which make auto-expands to be (something like):

    $(CC) $(CFLAGS) $(LDFLAGS) $@ $^ $(LDLIBS)

But I had placed the libraries in LDFLAGS, instead of LDLIBS which caused Ubuntu to fail at finding a function in one of the libraries. Moving the libraries to LDLIBS solved the problem.

Implementation specific. It looks like it is a bug in the Linux kernel with how it adjusts the time. It is possible that Windows, OS X, and other BSDs will be affected by a similar bug, but that would be coincidental as the bug is not due to ntpd but rather how the kernel handles a request that ntpd generates.

More specifically, there is a condition in which the kernel tries to insert a leap second and, in doing so, attempts to acquire the same lock twice causing the spinlock lockup and (effectively) halting the kernel.

I ran into that problem a few weeks ago. After a fair amount of tinkering, I found that this:

    https://www.google.com/search?q=link:www.saygent.com

Works the way you want it to. You just need to add search before the `?` and you should be good.

I couldn't get it to reproduce on a VM (VirtualBox) either. I'm wondering if the SSE-optimized version of the glibc doesn't work the same way in a VM as it does on host hardware (i.e. SSE instructions are virtualized to some degree). Since the hardware doesn't support it, the library falls back to a version that won't trigger the bug.

(Again, this is just an unconfirmed theory.)

Here is the reference from the Ubuntu CVE tracker: https://bugs.launchpad.net/bugs/cve/2012-2122. So yes it looks like it is confirmed.

Also, the associated bug report: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/101....

Here is the fixed version of the MySQL code: https://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/35... (line 534 didn't have the test()) previously)

Well, the Ubuntu part came from HD Moore [1]. I haven't been able to confirm it on my Ubuntu 12.04 virtual machine instance though, nor does my virtual machine appear to trigger the bug using the CVE-2012-2122 checker [2].

But, that is just my single VM instance and I would assume HD Moore knows what he is doing.

[1] http://pastie.org/private/903voijkkz8nmde3yqj4rw

[2] http://pastie.org/4064638

Ah, okay. So step 5 is the else condition from the "if" that begins step 4. At least, until the API is upgraded to the new improved edition and most/all API apps are using the new version.

I'll admit, I must be the only one that doesn't quite get the jump from step 4 to step 5.

In step 4, we make the assumption that their API is out in the wild, in use, and sends the md5(s, p) in the request. I get that we take that value, run it through scrypt and match against our stored value to authenticate. So the database has:

    scrypt(s', md5(s, p))

No problem authenticating the API requests with that.

Step 5 says once the user logs in with their actual password, we update entirely to the new scheme of scrypt(s'', p) and store just that. Now the database only has:

    scrypt(s'', p)

But the API user still sends md5(s, p) to authenticate, right?

So then what happens when that same user goes back to the API-using app? It's still uses the API so it'll send the MD5(s, p) and fail since we've discarded the transitional scrypt value when they logged in via the web interface.

Is there a deprecation period that supports both types while API using apps updated to a new API for the new scheme?

Well, in the eHarmony case we're talking about MD5 hashes, so even if you self-salt the password but still choose a weak password a good password cracker will find the password fairly quickly.

As an example, yesterday user rorrr posted this comment: https://news.ycombinator.com/item?id=4076840.

> > MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication.

> Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this:

    MD5(password + salt) = "b520542710812f347432232b2a1fba83"
    salt = "MD5 rules"

Self chosen salt, unknown password, known MD5 hashing method. Fire up a password cracker and feed it in a decent dictionary, and you get the password = "Spiderpig1".

    $ echo -n "Spiderpig1MD5 rules" | md5sum
    b520542710812f347432232b2a1fba83  -

No rainbow table needed.

It might help, but I think the cracking tools would simply get an update that tries `password` and `<salt>password` (and even `password<salt>`).

As the salt is guessable (as it is in your examples) it just turns into a cat-and-mouse game that the crackers win every time (since for every one of you there are probably 2 or more of them).

    $ echo -n "Spiderpig1MD5 rules" | md5sum
    b520542710812f347432232b2a1fba83  -

Thus the password here is "Spiderpig1"

MD5 is broken.

Right, that's what my assumption is too but I didn't see anything in the post that says "recently logged in users" or "once you log in you'll be protected by the new scheme."

Just "members whose passwords have not been compromised benefit [from the new scheme]".

> members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.

If we presume that the 6.5m password dump was the past version, it shows that they just hashed the passwords before. This sentence (if I'm interpreting correctly), indicates that they were plaintext and were recently changed from plaintext to hash(salt+password).

I must be missing something in my interpretation though, because there isn't any evidence that they had the plaintext passwords to begin with.

(My assumption is that he means any user that has recently logged in was transparently moved to the hash(salt+password) scheme they are using now and previously just had hash(password) in place.)

Doesn't this imply that LinkedIn doesn't salt the password prior to storing it. So then a good chunk of those passwords will be in a rainbow table.

That graphic isn't even internally consistent. I measure the 2000 "computer usage" circle at 56 pixels in diameter and the outer 2008 circle at 195 pixels. The text states usage in that time frame has increase 342%. Visually the change is 1,212%.

In text it states that Hitatchi came out with the first terabyte drive which holds 1000 GB. Later, in graphic form, it shows 1024 GB = 1 TB.

In the Internet Users by millions chart the author uses a bar graph (time is continuous, why use a bar graph) with no x-axis labels and then to express hard drive price over time we get a line chart (still no x-axis label). The missing labels are okay because there are callouts specifying the dates, but the change in graph type is weird.

That just means you have a local formula that knows how to build and install c, but you have not shared it with the community so no one else will have access to the formula. You'd need to fork, push to your fork, and create a pull request to the main homebrew repo to try for inclusion.

Also, it is only my hunch that they wouldn't accept the formula--you can still try. I'd still rename the project to be more descriptive (dir-c?) as there are only two homebrew formulae that have single char names (R, which has been around since 1993 and Z, which I'm surprised got included).

Are you sure you committed it to the homebrew repository on github? Your github page doesn't show any activity that indicates you've forked the homebrew repo or created a pull request in the past 14 days (since you made the "c" repo).

Even so, based on the general rules for homebrew inclusion they would reject the formula because:

1. I don't think they like names that have the potential to conflict with others ("c" is in that category). The shortest name I see in their repo is two chars.

2. Typically they only want widely used formulas ("We generally frown on authors submitting their own work unless it is suitably notable." [1]).

[1] https://github.com/mxcl/homebrew/wiki/Acceptable-Formula

I think his refusal to accept from the web interface has more to do with the web interface being so far out of his normal workflow that it would be too disruptive for him. If you accept this pull request it might set some sort of precedent then you'd have to shoot down the next one--might as well just stop it in its tracks.

I didn't realize all the tools git has built-in (therefore developed with Linus's workflow in mind) for handling patches until I was poking around today:

    git format-patch origin

This creates a git-style patch for every unpushed commit I have. git-style meaning it's actually an email with the log, diffstat, and patch in it. If there are multiple commits the subject of the email will be [PATCH 1/n] <first line of commit>. When you're dealing with many patches a day this gets the point across fast.

Better yet:

    git send-email origin

Same thing as above, but it hooks into your system's sendmail and sends the patch email(s) for you.

On the receiving end, you've got:

    git apply --check <patches>

You can make sure they'll actually work against your copy before diving in.

And most important to Linus is probably:

    git am --signoff

Which can hook into your mailbox and apply all the patches with commit messages and add the Signed-off-by line with your email account.

So if your workflow consists of looking at a patch in the terminal, then applying and committing that patch many times a day these things are very important to you and they provide you with the information you need very quickly.

Compare that to the point-and-click web interface of github, sure it works at low volumes but when you scale it up it becomes clumsy and slow.

I suspect his complaints about commit formatting and quality of github contributors doesn't help are more of the two more annoyances variety.

The first poster in this thread made the statement: "If I need a quick dynamic page on my server, it's much easier to do this in PHP than in Python or Ruby."

So yes, it really does matter in the context of this thread. On the whole I agree with your philosophy that frameworks are there for a reason: you get many features for almost nothing.

But sometimes you just don't need a framework, you need something quick-and-dirty that just works.

But I never needed to worry about those three lines in PHP, to a new user that is important. To you and I they come naturally.

PHP "is especially suited for Web development and can be embedded into HTML" [1]. Python "lets you work more quickly and integrate your systems more effectively" [2]. They can both do the task of the other, but the upstart time for a developer to handle the task of making a web app is smaller for PHP.

I've never taken the non-framework approach with python for anything significant, but how does it handle cookies, GET and POST fields, sessions, and file uploads? In PHP you'd have $_COOKIE, $_GET, $_POST, $_SESSION, and $_FILES as built-in global variables.

Are these differences still insignificant?

[1] http://php.net/ [2] http://python.org/

Let's look at the PHP version:

    Hello World!

One line. I didn't have to worry about Linux/Windows, knowing HTTP headers or the fact that I need two CRLFs after the last header[1]. I just wanted a page that says "Hello World!" and that's what I got.

Don't get me wrong, I would never choose to write a web app in PHP over python. But it is brain dead simple to go from nothing to something in a few keystrokes. Which is precisely what people just learning to write web apps want (right or wrong).

[1] I can't remember how long it took me to figure out that I needed the second CRLF after the "Content-Type: text/html" when I was learning perl (or even the fact that I needed to specify the Content-Type in the first place).