phkamp

53 ms·

301.
by phkamp 14y ago
I think it's perfectly fair. UNIX was originally written as pair-programming. Brooks refers to agile in The Mythical Man-Month (he didn't invent it, check his references)
302.
by phkamp 14y ago
Who said anything about Microsoft ?
303.
by phkamp 14y ago
No, autoconf happened because UNIX abandonned the cathedral model and went bazaar.
304.
by phkamp 14y ago
You are not even in the same zip code as the point I'm trying to make, which, I guess, sort of makes my point. Nobody says you have to write iOS games using the same methodology as avionics, what somebody is trying to say is that random wal
305.
by phkamp 14y ago
Because no words are without context.
306.
by phkamp 14y ago
You mean: "In 2001 we reinvented XP/Agile because we couldn't be bothered to read the old literature to see if somebody else had done something like that before" ?
307.
by phkamp 14y ago
I wonder if you bothered to check who wrote that article, before you started speculating about things you could have found out with a few google searches ? You seem to assume that cathedrals are "slow-moving, centralized, big up-front" desi
308.
by phkamp 14y ago
... but evolution will also quite happily run you over a cliff which you have been avoided if intelligence were applied. Not to mention the fact that the bazaar is never going to put a man on the moon. And yes, I wrote that piece.
309.
by phkamp 14y ago
Cleaner for who ? Easier for who ? That kind of cookie usage just makes it Somebody Else's Problem instead of your problem.
310.
by phkamp 14y ago
Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ? Putting the cost of storage where the decision to store is made is sound economic practic
311.
by phkamp 14y ago
They are not wrong because I say so, they are wrong because they are wrong. When it gets to the point where EU regulates something, the way they did with cookies, it should be painfully obvious to even the most casual observer, that there i
312.
by phkamp 14y ago
Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim
313.
by phkamp 14y ago
No, servers should hold _all the state_ and clients none. If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser, rather than have two shopping baskets. Servers storing stuff on the cli
314.
by phkamp 14y ago
No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate. Second, there ar
315.
by phkamp 14y ago
You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any
316.
by phkamp 14y ago
(probably pressing wrong reply link here ?) Cookies are almost never mentioned in Vary: so all caches have to assume that the precense of cookies means non-cacheable.
317.
by phkamp 14y ago
The client/user-agent gets to control what session-id gets sent to which sites. That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-
318.
by phkamp 14y ago
No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs). One example was multihoming (having more than one ISP) serveral smart proposals were floated
319.
by phkamp 14y ago
I agree that anybody with sufficient clue can and will use cookies as id only. Unfortunately such people are evidently few and far between. Banning cookies and having the client offer a session identifier instead solves many problems. For s
320.
by phkamp 14y ago
This is more a reflection on where you got your advise in 2003, than what was considered best-practice. Salting became best-practice in the 1980ies, but the "lost generation" of dot-com wizards never bothered reading "all that old stuff", s
321.
by phkamp 14y ago
I think you're setting the bar too high for tech journalists, lets aim for them knowing the difference between "md5" and "md5crypt" first. But no, I don't think it is at all obvious why LinkedIn used unsalted SHA1. LinkedIn went through an
322.
by phkamp 14y ago
... and since you are not danish, you don't realize that base64 emits the danish word "badeanstalts" and therefore fall to even the most trivial dictionary attack.
323.
by phkamp 14y ago
I've been offline for some hours, and just wish to add a few concluding thoughts here: No, I'm obviously not proposing that people do something stupid with crypto, we've had enough of that in recent days already. But I am trying to provoke
324.
by phkamp 14y ago
Collision resitance is not really a worry for a password scrambler, until the probability gets into the 1e-6 range or above.
325.
by phkamp 14y ago
I reinforces my belief in humanity that it did happen, I have been pondering for a long time how to do a "People of Earth, your attention please..." which would reach the necessary audience.
326.
by phkamp 14y ago
MD5 is not vulnerable as used in md5crypt.
327.
by phkamp 14y ago
Such a toolkit would probably be a good idea. Tie a card-carrying cryptographer to a chair until he delivers it ?
328.
by phkamp 14y ago
Yes, of course. I have clarified the text now on this point.
329.
Md5crypt is no longer strong enough(phk.freebsd.dk)
176 points by phkamp 14y ago|136 comments
330.
by phkamp 15y ago
The reason why struct packing would be a win is probably not performance, but code readability and less bugs. Making be/le/native conversion a job for the programmer is not only error-prone and a waste of time. The compiler could safely opt

More ›