cduan

There are at least two reasons why this analogy is weak.

1. Wikipedia is a source of information that is supposed to be true. Thus, it has a need to eliminate biases and unverifiable sources of data, and disallowing self-promoting articles serves that goal.

Sites like HN, however, are sources of information that is supposed to be interesting. Here, biased sources of information are welcome, because readers are seeking the opinions of others--that is, the biases of others. So the need to avoid bias is lessened.

2. Most Wikipedia pages are rarely, if ever, edited, and even less often fact-checked. Thus, a self-promoting article there can last for a long time, appearing as legitimate as any other.

On HN, posting an article gives it only one vote. Articles only make it to the top after review by several readers that are not the initial poster. So even if the initial vote was tainted by self-promotion, the other votes, presumably legitimate, can offset this.

I think the lesson is: the front end is the most important part.

Think about running a restaurant. You have to order ingredients in a timely manner. You have to get supplies and consumables such as utensils. You have to deal with the lease. You have to pass health inspections. And so on.

And does this customer writing his review mention any of this? No.

It's really easy to get caught up in back end stuff. What web server are you running? What language is your app in? Memcached? MySQL? CouchDB? Functional programming? Etc.

Certainly, you have to have a decent back end so that you can have a front end in place. But your clients review the quality of the front end, regardless of what's behind it.

Why not create separate accounts for each service? If you are really security conscious, you could even have a separate password for each one.

For that matter, you might simply solve the gmail/blackberry problem by making a second account for your email, setting your primary account to forward to the second account, and setting the phone to check the second account rather than the first.

For that matter, the Harvard Book Store is not part of Harvard University. It is an independent bookstore.

(No one's going to read this comment, but we might as well get it right.)

It is a derivative work when you transcribe subtitles because you put in your own creative (and copyrightable!) elements into it. You choose how to represent sound effects, how to disentangle crosstalk, how to transcribe dialect, and so on.

So, if the movie creator decided to rip your subtitles off and sell them, you could actually sue the movie creator!

As a practical matter, it makes little difference. Most judges won't parse this finely, and you are equally liable whether under the copying or derivation right.

Here is a little copyright intro for you. This is not legal advice; if you are in need of particular answers for your situation, please consult an attorney directly, as other commenters have indicated.

Copyright protects original creative expression. This is in contrast to general ideas, which cannot be protected by copyright. The difference between ideas and expression is hard to define, but a common example is that the concept of a story about two lovers torn by warring families is an idea (and thus unprotectable), whereas the particular story "Romeo and Juliet" is an expression of that idea (and thus protectable).

I think that most people would agree that the words of a movie are creative expression, and not general ideas.

What does someone else's copyright prevent you from doing? Copyright gives the author of a work four main exclusive rights: the right to make copies, to make derivative works, to distribute copies, and to publicly perform the work. If you perform an act that is within the author's exclusive rights during the term of a valid copyright, then you may infringe the copyright.

Subtitles and translations of subtitles would probably be considered derivative works, since they are derived from the original work, namely the movie.

There are also defenses to copyright infringement. Two come to my mind: fair use and the DMCA.

Fair use permits you to perform acts that would otherwise be infringements, because of certain public policy interests. It is extremely difficult to determine what constitutes fair use. Two considerations that are important factors are whether your use of the copyrighted work contributes something new to society and whether your use is taking away from a traditional revenue source of the author.

The DMCA provides a shield for website operators who accept user-provided content. If the website operator complies with certain requirements regarding taking down infringing content promptly, then the operator will be protected from many claims of copyright infringement.

Keep in mind that this is purely based on US copyright law, so things may be different if you are elsewhere in the world. Plus I am not considering the business side of things.

It is highly useful for EULAs and Terms of Service.

The practical problem with eval() is that people overuse it. This led me to once find a wonderful little code fragment written by a codeveloper that, when boiled down, was:

  eval(":" + symbol.to_s)

which converted a symbol to a ... symbol.

I still do.

Ok, virtual terminals (though I did use a VT220 for a good while). But I do still stick to an 80x24 screen. My theory is that if my code is too complicated for me to understand without expanding the screen, then it needs to be refactored or reorganized.

I made myself a credit-card sized copy of the relevant bike laws for my state (California), so I can pull it out and read/give it to people like this. I've only actually done it once, but it sure shut the guy up fast.

Just to be sure, this was about using TeX, not LaTeX. The relationship between them is much like Ruby and Rails: LaTeX is a package of macros that operate on the TeX programming language.

TeX is an enjoyable language for programming--it's something like writing in lambda calculus. It's too bad most people don't realize it's a complete language. I use it all the time for generating automated documents and such.

I'd also offer them an option, like a mouse to point with.

You are absolutely right. And when a corporation is damaged in this manner, it has the opportunity to show its actual damages for staffing, promotions, contracts, and everything else.

The issue with statutory damages is that they are awarded without regard to actual injury. They act, more or less, as a punishment or deterrent. So even if the corporation truly suffered no damages, it still can receive a few thousand dollars. (Note that taking statutory damages is an option: if your actual damages are higher, you can opt for those instead.)

I'm not necessarily saying that statutory damages are a bad thing. The problem I see is the inequality in their distribution: because copyright registration is costly, statutory damages are ultimately only available to the profit-seekers. One possible idea would be to cut out the registration fee, making it easy for everyone to register their works and thereby receive equal protections.

With regard to US copyright law, one important point not mentioned is statutory damages for infringement. Generally, if you are found liable for infringement, you owe "actual damages," that is, the amount of harm you did or profit you gained from the infringement. However, if the copyrighted work was registered, then statutory damages may be available, meaning that you could be liable for up to $200,000, even if you caused no actual damages.

My personal opinion is that this leads to a strange imbalance in the copyright law. If an individual makes a creative work (e.g., a blog post) and makes it available for free, the individual is never going to pay the $60 to register the work. So when someone else comes along and rips off the blog post, the individual only wins actual damages, which the other person argues are minimal because the blog post was up for free anyway.

But if a big corporation makes a creative work for profit, it expects to make more than $60 off the work, so it registers it. So someone who copies the work is suddenly liable for hundreds or thousands of dollars in statutory damages, regardless of the harm actually done.

This seems, to me, to create an unbalanced incentive: works created for profit receive greater protection than works created for free. There are a number of legislative options to fix this, which I will leave to the rest of you to devise.

Tofu is a protein too! The great thing is that all these things are easily interchangeable, so you use whatever you like.

Your post did remind me of an advanced technique. If you are cooking chunks of protein, the best method is to first fry the protein, then take it out, and then follow the original recipe. Why? Because you want to get that browning, and you only get that with direct contact between the protein and the pan. (This is known as the Maillard reaction.) But if you leave the protein in the whole time, it dries up faster than the vegetables (they have cell walls that are hard to soften).

Let's raise the level of abstraction a bit.

1. Heat oil in pan (until oil is hot; should flow like water)

2. Add vegetables (almost always including onion); cook, while stirring, until soft.

3. Add seasonings (salt, pepper, spices, garlic, etc.)

4. Add in a protein; continue stirring, until everything is cooked through.

5. Optionally, add a liquid and simmer.

This process is the basis for cooking a lot of foods, and it pays to get it down really well. Consider:

- Protein is ground meat; liquid is a can of tomatoes. This is pasta bolognese sauce.

- Lots of vegetables; liquid is soy sauce and optionally a slurry of cold water and cornstarch. This is a basic Chinese stir fry.

- Protein is ground meat; liquid is mixture of beef stock, crushed tomatoes, and a can of beans. This is chili.

- Vegetables are bell peppers and onions; meat is andouille sausage; season heavily with Cajun spices; liquid is chicken stock and long-grain rice. This is jambalaya.

Sure, these aren't real recipes, but once you have the above procedure down, it's just a matter of developing an intuition for taste and some knowledge of how ingredients work (e.g., 2.5 cups liquid per cup rice), and most basic cooking is pretty simple.

This is just the lower district court order. Microsoft will almost inevitably appeal the case. In patent cases, the appeals court often takes an active role in scrutinizing the patent and the case, and it often disagrees with the lower courts.

So I would hold off on worrying about the verdict too much at this point. What happens on appeal is most likely more important.

This is why I generally prefer event-driven programming over multithread programming. This is the sort of programming you do, for example, when you are implementing a GUI: you write short event handler functions that respond to events (such as mouse clicks or the completion of network or disk reads), and then a master loop receives events and dispatches the handler functions.

You get the same benefits as concurrency (maximum processor usage, at least when you only have one processor), but you avoid the pitfalls of shared memory, race conditions, and unexpected state changes (because only one event handler runs at a time). It does take a bit of getting used to (it seems so easy to make function calls like time() or mkdir() that are actually blocking and thus technically should be separated into a new callback function). But I find that the benefits of processor efficiency plus the comfort of avoiding concurrency problems are worthwhile.

http://en.wikipedia.org/wiki/Event-driven_programming

Of course, a native app has advantages of its own: it is usually faster, and it can cache information and function without a network connection. Plus (iPhone developers, correct me if I'm wrong) you probably wouldn't get access to all the hardware, like the GPS and accelerometer. So I wouldn't say that an iPhone webapp is a complete workaround.

Companies will sack staff on this site? In this economy, companies will probably reward staff on this site if they move product. Heck, companies will probably just put themselves on the site!

The interesting thing about this lawsuit is that it is charging Amazon with various forms of trespass and breach of contract. One of the causes of action is for illegal hacking; one is for trespassing on the Kindle; one is for stealing the book; two are for breach of contract; and one is for deceptive trade practices.

The case has nothing really to do with copyright. It seems unlikely that Amazon can justify its actions on the grounds of protecting someone else's copyright. (If you sell illegal contraband to someone, you don't magically get a right to steal it back.)

If the case succeeds, it might have some interesting limiting effects on DRM systems.

So if this case succeeds, it might have

The illustrations are pretty good though--I'd use him for that social network webapp I'm writing that's going to take over the world.

Please keep your intellectual property straight. Creative works are COPYRIGHTED. Useful inventions are PATENTED. Names associated with goods and services are TRADEMARKED.

(Or perhaps there is a missing </sarcasm>? I didn't see it...)

A lot of HN readers appear to place the blame on the system engineers rather than the kid. Some go so far as to say that the kid did a good thing in teaching the engineers a lesson. The implicit principle seems to be that unwanted intrusions are acceptable--even applaudable--actions in the face of systems unsecured against them.

I would ask of you whether you would apply this principle in other systems. Shall we call it a "good lesson" if the kid went around shooting people in the train, as a lesson that the trains need to be bulletproofed?

Folks, the criminal law exists to punish certain undesirable actions, so that the general public can save itself the cost of self-protection. I don't walk around wearing a bulletproof vest all the time, because I believe that the law and its enforcement will sufficiently deter others from deciding to intrude upon my body with a bullet.

So should it be with technological intrusions as well as physical. Certainly it is feasible to build secure systems. So is it feasible for me to wear a bulletproof vest all the time. But secure systems, like bulletproof vests, are costly things--they require hiring good engineers, spending time to evaluate security risks, testing systems for robustness, and so on. And if these costs are sufficiently high, then it would be economically inefficient to impose them on systems engineers by allowing hacking like this to go unpunished.

I'm not saying that anyone should be lax in building secure systems. I am, however, saying that intrusive behavior like this kid's should not be applauded. It should be recognized for what it is: a societally detrimental act, for which he should be held accountable as any other societally detrimental act is held under the law.

Generally, if you have an idea and are wondering if any patents would interfere with it, you can ask a lawyer (pick one who knows about patents) to conduct a "right to practice" search. They will look through the existing patents to see what might affect your products, and they can also look into whether there is prior art to defeat those patents.

A lawyer should also be able to explain to you that a patent application hasn't been examined by the patent office yet, so its claims (the part you care about) are subject to change as the examiner reviews them. They can usually provide a watching service to you, to monitor the status of the application you're interested in, as it goes through the patent office.

You know that old saw about your friend putting running shoes on as an angry bear approaches--he doesn't have to outrun the bear, he just has to outrun you? This password hashing is kind of like that. Sure it's easy to break. But if you're running a phishing site, are you really going to go through the trouble to cryptographically attack this weird password that doesn't work on other sites, when you've already got a bunch of other people's passwords that do work?

For that matter, this solution is probably even more complicated than it needs to be. Just tack on the domain name wholesale to the end of the password, and you'll foil any automated phishing password script well enough.

A few more:

* Lectures let you see how well your audience is getting it (assuming you're lecturing to an audience). So you can tell what's making sense and what's not.

* You can talk faster than you can write. In fact, in my experience, I can talk about as fast as I can think. I can't write as fast as I think. This makes me inclined to skip over some thoughts while I'm writing, simply to keep up.

Incidentally, I don't see why the first point ("There is no post-lecture work, such as rigorous editing or re-organization of ideas") is really an advantage of lectures. Certainly there are many lectures I've seen that could have used some reorganization. And, at any rate, any decent lecturer will do preparation beforehand to organize the presentation.

The analogy I prefer is that Unicode-encoding is like network protocol layers. In a (very simplified) network, the goal is to present an interface of a pipeline for sending a continuous stream of bytes. To achieve this, you have a protocol like TCP, which consists of routines for transforming a series of packets running through a wire into a stream of bytes. To achieve a series of packets running through a wire, you have a protocol like Ethernet, which consists of routines for transforming electrical pulses into a series of data packets. You need both Ethernet and TCP to turn electrical pulses into a stream of continuous bytes.

Similarly, the goal of Unicode is to present an interface of a stream of abstract characters (the letter "A", the number 3, the nonbreaking space, etc.). To achieve this, you use Unicode, which consists of routines to convert a stream of arbitrarily-long numbers (packets) into abstract characters. To achieve a stream of arbitrarily-long numbers, you use an encoding such as UTF-8, which consists of routines to convert a series of bytes into a stream of arbitrarily-long numbers. Now, using an encoding and Unicode, you can convert a stream of bytes (i.e., an arbitrary file) into a series of abstract characters.

There is an interview where he explains what he likes about Emacs:

I have special Emacs modes to help me classify all the tens of thousands of papers and notes in my files, and special Emacs keyboard shortcuts that make bookwriting a little bit like playing an organ.

Probably one of the few rational vi/emacs arguments I've seen. And it also is a good reason why I like vi, given that I can barely hit two keys on a piano at the same time.

(Link to interview: http://www.informit.com/articles/article.aspx?p=1193856)

I would say that there are at least two reasons, in addition to those in the article, why a Googlable question is still a good question.

1. Internal memory is a pretty good predictor of sincere interest in a subject. Ever notice how baseball fans know every stat of every player? They don't spend hours rote-memorizing tables; their passion for the sport induces remembering facts about it.

2. Interview answers reveal how you problem-solve as well as what you know. Saying "I'd Google it" indicates to me at least that you go for the fastest method of solving the problem. Better would be "I don't know, but I'd look it up in a textbook on X" or something, which reveals a willingness to take the time to learn something in depth rather than just copy-paste someone else's code.