scscsc

Cheap, fast, tasty, healthy. Choose the last or any combination of the first three.

I think googling someone's name is fair game. You get to see what projects they work on, what communities (i.e. job related) they are part of etc. By yes, there is a line to draw. And definitely facebook and myspace are on the other side.

Triple negation in the last sentence really helps with understanding. That being said, you should probably keep embarrassing personal details to yourself (and maybe your friends). Why would you want the company to know the embarrassing thing (since it doesn't affect work performance significantly)?

The hiring process is a negotiation between two sides. The more information you have, the better you'll do.

It's not fair for an employer to look in your private life; any more than it is fair for the potential employee to look at confidential company data. How would you like that? The company is hiding information, thereby cheating you into a job.

Google publishes techtalks. They always save "delicate details" for the question break, which is not recorded.

The damage has already been done. It is not reversible. Apologies do not mean much usually. They probably mean less than nothing coming from a government.

Can anyone confirm this article by Atwood is worth looking at?

You should use old style "dating^H^H^H^H^H^Hmatrimonial".

Basically, after everyone on Earth buys all available books, the only way to make extra money on books is:

a) to create new books b) to create new people

Option b) would not work very well for a number of reasons and option a), well, it's too difficult. Therefore go ahead and invent very smart option

c) make everyone repay for the same content over and over

Highly unlikely to happen, since the upper bound corresponds to a well-known lower bound.

>> Dirt can absorb a LOT of heat. If you had to put out a fire, and you didn't have any water, you'd throw some dirt on it, right? We are all standing on a big ball of fire, anyway. <<

The fire is extinguished by throwing dirt because of lack of oxygen, not because the dirt "absorbs" heat.

Get it? Lower your expectations! Do not want to get rich! Want to work for the same amount as people from undeveloped economies! Then maybe you can find a place in the organization of this top CEO, if you're lucky enough.

I see two issues here:

* the policy of the appstore obviously sucks for both developers and end-users

* developers miscalculate the risk that their application will be rejected and therefore engage mindlessly into the implementation phase

There is not much to do about the first (except of course give Apple the bad PR it deserves by e.g. posting this stuff to HN). But developers can/should calculate their profit expectations more thoroughly.

Are you saying my definition of 'good' isn't?

That is obvious. What is less obvious is how much memory you can waste for the internal representation. I would expect that the memory footprint of a well-designed browser should be dominated roughly by the download size (w/out taking into account the javascript code, which could keep a lot of state around).

Negative. It is intuitive (and wrong). It is not mathematically sound. He does understand statistics. The point he's making is that the author of the article chose the metrics after the act. There are tons of such metrics to use; if you are not honest, you can search for the ones that prove your point.

I don't get why you are modded down. Mathematically, the article is a piece of junk (which doesn't mean the elections were fair -- I don't think there's anyone in the democratic parts of Earth who thinks they were fair).

You are of course right, why choose exactly those two metrics? Also, the two metrics are probably not independent, so taking their product is bogus.

The article was written by a 'PhD candidate' in political sciences. I think he should get his degree. He learned how to convincingly misuse statistics.

For what it's worth, we've already got wikipedia which does math pretty well. Even though it doesn't have the fancy-sounding zoomable user interface (which imho suck w.r.t. usability), it does offer plain old, get this, hypertext, which allows you to perform further exploration.

As for your idea, I don't want to minimalize it [because well, with ideas, you never know for sure which ones are good and which ones are bad (w.r.t. how successful they are) until after they are deployed], but it seems to me it would be a lot of work, with an end-result that might be totally crap usability-wise, and of limited interest to a large part of the population. Plus it would (for the moment) require a computer to read it. And computers suck as devices to read books on.

I doubt the beta comes with debug information (not your beta, theirs). I don't use Windows -- it should be easily checkable by someone who does.

Do you have any strong data stating that the final release of some software is in general more memory friendly as opposed to the beta version? I don't have data for the counterpoint either, but I'm willing to bet the developers have other priorities (i.e. bug fixes as opposed to optimization). Once you've maldesigned your software w.r.t. performance, you can't do much except to wait for hardware to catch up.

I also want my browser to be fast and responsive, but the current trend goes in the other direction. How on Earth can you occupy GBs of memory? How much time does it even take to download a gigabyte of data?

Probably the ratio is to stay, since the other platforms are treated with the same indifference by the developers.

You get to choose which details to ignore. Making the wrong choice will of course lead to invalid results.

No model is perfect, but some models are useful.

How is it any better?

Having called support in my life very few times, and having received the answers I did, I have come to the conclusion that it is a waste of time to even consider calling. I have a hard time imagining what people see in tech support and how they help.

I think the percentage should be bigger. Besides the obvious powerusers, most companies do their IT in-house...

For a long time now, people have complained about Big Oh notation. The problem is not the notation, it's the people. The notation is absolutely brilliant. People do not understand how to use it and complain that "in practice" it breaks.

Big Oh is simply a mathematical tool that is helpful to abstract away uninteresting details. But what people do not realize is that by using this tool, they perform some abstraction of their own -- it can be used to count anything, and the most important thing to establish is what you count. Most importantly, you want to count time & space used by an algorithm. But you don't always want to count the time used by an algorithm as the number of instruction performed. For example, we may compare comparison-based sorting procedures by the number of comparisons they perform. Why? Because we are smart and realize that this (# of comparisons) is a good way to compare such algorithms.

For some algorithms, you might want to count the number of memory accesses you make. Or the number of level-i memory accesses in a memory hierarchy. Or the number of network packets. Get it?

I think you ought to be able to write your own resume. People hiring you would expect at least that much. Why in the world would you want to work for another company if you already have your own (and it's running well)?

:D I figured out as much. Which ones?

I think most people would not bother to give feedback when something goes wrong. I know that I certainly do not. I have tried in the past and you always run into some sort of problem with the feedback mechanism or they simply do not care about your problem.