ijoshua
ijoshua on Hacker News
> Where can you point me to "better documentation than PHP"? This is a major difficulty for new people getting into Python-- the documentation is really quite poor and out-dated.
I disagree that the Python documentation is poor or out-dated. However, it is fragmented in what could be considered a confusing manner. I’ve often been searching for a particular piece of documentation, wondering if I should be looking in the tutorial, the library reference, or the language reference.
Python‘s way of accomplishing this is as easy, although the use of `locals` should indicate that this isn’t generally something you should be doing:
post = {'name': 'ijoshua', 'email': '[email protected]', 'extra': 'data'}
filter = ['name', 'email']
for k in filter: locals()[k] = post[k]
print name, email
I don’t know the details of the compiler, but the negation operator on int objects also has a corresponding method: `__neg__`
-1 == (1).__neg__()
Principia Discordia; or How I Found Goddess and What I Did to Her When I Found Her
See those arrows? That’s human moderation. Just don’t click on the up arrow if you think it’s spam.
The privacy implications and “unintended consequences” of participating in Facebook are shocking.
It was an apostrophe, but since Arc doesnaEURXt support Unicode, fuck it.
The patent appears to predate PLTaEURXs work.
How did you arrive at these conclusions? Did you use some programmatic analysis of CL source code to report these stats? Which codebases were your reference?
I looked at it very briefly. The codebase is actually pretty small. It appears to depend heavily on memcached.
Whatever language, I just hope it comes with decent documentation.
Given Lisp, I can implement a Lisp interpreter easily:
(loop (print (eval (read)))
If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases.
Here-say and speculation, although not that far fetched.
"Honour thy error as a hidden intention" - Brian Eno's Oblique Strategies
I'd like to see a scoring system that evaluates the discussion or thread as a whole, rather than the individual contributions; a metric like a signal-to-noise ratio, where a thread gets a higher score for being on-topic and relevant, or a lower score for degenerating into a pissing match.
<q>You just participated.</q>
I did not realize this was an argument. I guess I lost.
Seriously, though, the most interesting arguments don't resolve for quite some time, if ever. For example, who was the winner in the infamous Torvalds v. Tanenbaum argument over monolithic versus micro-kernels? One could say that Torvalds "won," in the sense that Linux became far more successful than Minix. Yet, Windows and Mac OS are both based, in part, on a micro-kernel architecture, and both have a greater share of the market than Linux.
Easy. The losers are usually the ones who participate.
Are you referring to the "JavaScript API" or the "Data APIs?" Because the Data APIs are pretty plainly based on the Atom Publishing protocol, with only a few extensions. Yes, many of Google's APIs are now based on Atompub, but that isn't something that Google invented from whole cloth.
Google doesn't have to keep your data for you. The OpenSocial API is just a specification. Google's own applications implement the specification, and you can too. The API is designed to be able to work with data on any host. It's in the very nature of the addressability of the API's data. Look in the documentation, and you'll see lots of URIs that look like:
http://{domain}/feeds/people/{user-id}
Notice that "domain" is a variable. In any case, why would you worry about Google being able to store data that is publicly accessible through a standardized API?
"But I think they're inherently slower for things like reporting."
I wouldn't say the deficiency is _inherent_, but the powerful indexing ability of a relational DB that we take for granted seems to be necessarily _ad hoc_ in an object-oriented DB. From my understanding, the index in an OODB is just another object in the database, which may be a B-tree, a hash table, or a simple sequential list. So far, that's fairly similar to the RDB. However, the indices in the RDB are closely coupled to the table that stores the records. The RDB "knows" that it should update the index when the table is modified. On the other hand, there isn't a table of records in the OODB, so there isn't a close coupling of the index to the data store. It may be entirely up to the application to manage the integrity of the index.
PG, I'd be interested to know why you chose to implement a voting/rating system for stories on news.yc. That is, did you consider a "weightless" submission system like, for example, MetaFilter, where front-page postings are a privilege that every member has equally. I've been a member of MeFi for several years and the effect of "gaming" has never really been an issue there, because there is no reification of trustworthiness in the form of a "karma" score. Certain members there certainly have name-recognition based on their history, but this gains them nothing in terms of influence on the focus or direction of the site as a whole.
"Most people aren't smart at all."
Very correct. In fact, nearly half of all the people you'll meet have a "below average" intelligence.
I would like it better if the "Comments" box didn't obscure the content. Even on my 1680 by 1050 monitor, with the browser window scaled to full width, I cannot move the comments completely out of the way. If the main content area was aligned to the left side of the page, rather than having equal horizontal margins, I could easily fit the comments into the margin.
[Edit: it seems that I cannot type Unicode characters into a comment here...]
Oh noes! Write your congressperson!
Posted by
ijoshua on Monday September 17, 2007 @06:37PM
from the wolfram.schneider.org dept.
http://wolfram.schneider.org/bsd/7thEdManVol2/password/password.html
This paper describes the history of the design of the password security scheme on a remotely accessed time-sharing system. The present design was the result of countering observed attempts to penetrate the system. The result is a compromise between extreme security and ease of use.
As stated in the last few paragraphs, the simplest way to guard against this sort of attack is to salt the data before hashing it. What he doesn't discuss is how to choose a salt value. In a good hash function, every bit should affect the output, so really only a couple of bytes are needed for a good salt. Additionally, the salt value can be random and may include unprintable ASCII characters. Furthermore, a new salt can be created for every password. Now, if two users have the same password, the ciphertext will be different for each.
I've used this technique to store sensitive personal data which must be recoverable (i.e. credit card numbers.) When a new number is obtained, a few bytes of salt are randomly generated. The data, plus the salt, are passed to a symetric cipher, and the ciphertext and salt are stored in a database.
[edit: there's some discussion of this in the article comments.]