That'd be "elections", not "inventions", of course. :-)

Just a thought. Could the reason for valve making a native linux client be a low-profile way to gradually enter the android platform? How much linux is android from a game standpoint? Either that, or they are contemplating a linux console.

Or perhaps just that given that people with linux hasn't paid $300 for their operating system, perhaps they instead can put some money on a game?

Anyway. It is a kind of interesting process: http://blogs.valvesoftware.com/linux/

Huh?? WTF?! As a non-US citizen I take offence to that!

1. What free-speech rights would that would be that are lacking in basically all western countries? I am Swedish, and I can write/say whatever the fuck I want as long it is not libel/slander. And yeah, we can say *fuck* on TV too without being bleeped too. You have ridiculous levels of censorship and then you walk around saying stuff like this. I am not saying we are perfect. But we are certainly not worse than the US.
Free speech is also not some US invention(http://en.wikipedia.org/wiki/Freedom_of_speech) as it sometimes sounds as it is:
"England’s Bill of Rights 1689 granted 'freedom of speech in Parliament' and the Declaration of the Rights of Man and of the Citizen, adopted during the French Revolution in 1789, specifically affirmed freedom of speech as an inalienable right." Yeah, eat that. The french!
And BTW, democracy is a greek invention from about 500 BC or whatever. And yeah, we've got that too. Only difference is we don't allow corporations a huge influence on inventions. For example, if IKEA would have been able to form superpacs we would all be dead.

2. No. Not ALL customs operations work like that. Would our customs treat a foreign public figure like that there would be a national outcry, and the opinion would be that behaviour like this would be beneath us. One thing is to ask about terrorist activities if they are actually suspected, but to ask about views on the countries' policies is low stuff. And also quite pointless. What is being described is stuff you'll normally only have to tolerate when entering obscure military dictatorships. And I would expect this to be uncommon even there.
To be able to detain and to actually detain is not the same thing.

http://en.wikipedia.org/wiki/Competitive_exclusion_principle

And it has been used medically in treatments for ages, I actually fail to see what is really that new with this(especially since the mouse microbiota is so fundamentally diffent from the human's), albeit it interesting.
In this context it means that introducing a new bacteria to the gut microbiota that consumes a certain resource, starves other bacteria that lives on that resource.
It is very useful, as literally hundreds of studies show.

- begin rant

However, as the research and pharmaceutical world works now, studies has, for no actual reason beyond prestige, politics and money, to be huge and expensive to matter.
Even when outcomes are clear and many others repeat the results, all the credit goes to the first huge one.
Credit aside, this means that it is very difficult to develop new treatment regimens. Especially for smaller companies and for uncommon illnesses where the number of study participants simply cannot be that high, or with treatments that you just can't not give, as when patients are severily ill. In the last case, it is unethical to have a non-treated group to compare with.
Yet it is extremely uncommon that treatments are approved generally no matter ho obvious the outcomes are. I has to be blinded, randomized and so on regardless, completely disregarding patient health or simply...math.
Double-blinded randomized trials add no actual statistical certainty over repeated non-blinded multicenter studies if outcomes are very obvious.
RTs value are when outcomes are less clear, there is a large potential placebo effekt and there the financier of the study is a pharmaceutical company and one of the few researching a specific substances.

Simply put, sufferers of severe illnesses have a really har time getting their research going anywhere.

- end rant

IANAMPBIAATR/W(I am not a medical professional, but I am able to read/write).

I suppose it must have been about 50,000 years ago when the Neanderthals really started to let themselves go, remember?

They simulate it like the military simulates casualties I suppose. "That guy's dead, now carry him".
You don't actually have to DDoS, the problem is the infrastructure around the systems, that people don't know what to do.
The systems are supposedly down, so there is not much to do about it but trying to get them up again and that is a different exercise I'd think..

Well, I have been around a while too, when I did my CS-stint nobody spoke about frameworks, and I started with assembly language demoing on the C 64 before that.
But you know, things has changed, and as things has gotten more abstract, the bottom-up knowledge I have of how a computer works has become less and less usable.
Also, software development has become easier, and so people with less technical profiles become developers which means more of them monkeys.
On the other hand, I am not sure how great I'd be if I suddenly got thrown into a large framework at age 19, it is a different set of problems.

I also think that many of the problems out there is because employers think that they don't have to educate the new arrivals.

Eh..no I am not arguing that one should not know the definitions. I am not sure, but I think your example is at the wrong abstraction level.
If I didn't know the grammar, the application would not compile and you wouldn't understand me.
But I suppose that you mean that knowledge of algorithms supply the definition of how one should write programs?

Actually I do not agree there either, as that is more in the realms of coding convention rather than algorithm design.
Now that is if I have understood that sentence correctly. Anyway, I really have no idea of how you came to that conclusion.

And I don't understand what thesis you are referring to? I am just observing the current state of affairs, not much thesis there.

And to quote myself: "One should know algorithms. I am not saying one shouldn't."

By the way, it might taste a bit funny, it is wrapped in a $100 bill since it was all that I had laying around. I have earned so many of them from my evil work.

Wow.
You can really imply lots of stuff about me, impressive.
But I am really glad I got someone like you to allow to respond, there are so many of you anti-framework-types out there:

* performance issues:
No, most performance issues, to my experience, has absolutely nothing to do with bad algorithms. Most, even crappy, algorithms finish very quickly, so users will never notice. And yes, that is what is important.
Rather, it has almost always to do with databases unmanaged indexes, bad SQL queries, loading unnecessary data.
Also, badly configured servers are no fund.
Strange proprietary wrappings of old functionality is also a dear old friend that needs mentioning here.

* security issues
- Is usually when people DON'T use frameworks, and make their own crappy solution that no one else understand and forgets to sanitize data.
- When in frameworks, is not usually about about bad algorithms, but unchecked buffers and stuff like that.

* Mixing OO with....hibernate?
Actually, I have before, but do not use Java at all. Or C#. And I actually don't work on building a dog ass slow monstrosity.
I mix whatever I think mixes well. There is nothing wrong in combining different tools into a tool chain.

If no one realize there is a problem. Is there a problem?

And...relax, dude. You are making all of us feel like we all are doing something wrong, and that's not cool, man...here, take a puff.

Yep, in those workplaces there are many positions where algorithm design and optimization takes up much time.

But you are still wrong. Most programming jobs even in those places are exactly as I described. We should not kid ourselves here. Even if you work at Wolfram, you will find that most work is made within existing frameworks and that a large number of its employees work as I described. Mathematica has a huge amount of non-algorithmic stuff.

So rather it is the framework that is the programmers toolbox. Because therein lies the algorithms. If you don't know it, you will use the welder for everything, cut the wheel nuts and eventually not be able to put the wheel back on.

One should know algorithms. I am not saying one shouldn't. But on the job making a common business application, it may actually take YEARS between the algorithms you have to make because you haven't found a solution in the libraries and the framework.
Most of the common algorithm writing, which usually concerned data juggling, have been replaced by SQL and collection member functions.
There are just very few places where any advanced knowledge of algorithms are needed nowadays.
Advanced structuring, however, is a different story.

They are most certainly not just big algorithms since they are pretty far off from meeting the requirements of an algorithm.
So read up, Fool : http://en.wikipedia.org/wiki/Algorithm

They are frameworks(of algorithms). Or libraries. Or whatever. Just not algorithms fer Gods sakes.

Rather, my attitude is one of realism. And it is, which might surprise you, based on actual knowledge.

Unreliability is choice, just as crappines and hugeness is. I have found that people very seldom are unaware of the fact that they are making crap. Actually, some of the most ugly and sickening solutions I have seen have come from brilliant programmers that perfectly knowingly wrote them. Just because the had very little time and knew this super-fast way to deliver something that worked. Ugliness is not always bad, it can also be a creative way of thinking out-of-the box to use a strange behavior to save a situation from imminent disaster.

Anyway, reliability, performance and elegance costs. And elegant, reliable and high-performing system is usually *FAR* too expensive to make from scratch.
This is why we have frameworks, because in them, stuff has been sufficiently elegantly solved, creating a platform from where the customers demands can be met.

But yes, inherently frameworks, as they are not one big algoritm, but masses of likely unused algorithms, makes systems bigger.

But they sure as hell don't make systems using them unreliable, quite the opposite. That makes me suspect that you haven't really thought that position through.
I'd say that rather, unreliability usually comes when programmers do not know how to use the framework or go outside its beaten path.

This is true. Saying they are not important made me feel better.
What a minute, I didn't say that!
I probably only felt better because I looked a bit beyond the algorithms...

The thing is, I know quite a lot about algorithms, and still I say these..these heretic things.

I also know many programmers that many times have come to me, bursting with pride over a fantastic algorithm that solved a problem with never before seen elegance, only to be brutally let down when I show them that this problem has already been solved, O(n), somewhere in the framework, or some utility library.

Rather, it is my experience that most people that say that algorithms are very important don't understand frameworks or how to apply them. Since they aren't good at it. Those of us that has been around since algorithms basically was the only thing there was and sorting meant implementing it yourself have actually had to learn this the hard way.
There are extremely few difficult algorithmical problems in day-to-day programming that haven't already been generically solved by the frameworks.
Of course, it depends on what you do for a living. It isn't black or white. Or Black or Scholes, as shown. :-)

After the outright slackers, the worst thing there is are the overthinkers and do-it-yourselfers. The waste vast amount of resources that could have been put to better use elsewhere than on stuff that is just another way to enable them to show off to themselves. They tend to create unnecessarily generalized and deep object structures that, while they can be tested completely and are academical perfection are simply too smart, meaning that they are very expensive to use.

When in doubt #1:
Keep it simple.

When in doubt #2:
Do you really have to do it your own way, are you f#"ing SURE the solution in the framework doesn't work for you? Remember, you have to maintain your crappy solution forever for the likely reward of later realising that you just didn't understand the framework.

I agree, and that is, as evidenced by my post, near the definition of "top coder" for me as well.
However, the "top coders" as described above are the not that way, the "top"-iness is quite obviously measured by algorithmic ability and knowledge alone.

Except that so very little of programming these days is about algorithms.
Rather, it is about elegantly solving businesses problems and to know one's way around huge frameworks.
Being a "top coder" is in it self a very good thing of course, but there are very few companies that actually work with technical details like implementing a better hash algorithm and so forth.

Rather, in most developers jobs, it is very valuable to;
* be good at being able to understand, handle and especially change large systems.
* be good at producing solutions that at a reasonable rate balances cost and customer demands versus simplicity, performance, structure and other technical values.
* being able to foresee the usages of the solutions in different time frames, and through this make systems cheaper and easier to evolve. Sometime, a super quick and butt-ugly solution is a really good thing to get the customer going while it figures out what it really wants. As long as all parties are aware of the situation and knows that a complete rewrite will have to be paid for next.
* not act like a stubborn child when ones pet solution or technology gets scrapped or unaccepted or that the rest of the company think it is risky to invest time in going down that road. But to just keep pushing.
* to be professional and keep on working even though the current thing is really boring.