You clearly have no idea what "natural selection" means.
No, I think the OP is broadly correct in his use of the term. Being jailed and presumably being put on some German equivalent of the sex offenders list does not improve one's reproductive chances.
It was summed up nicely a few years ago in a criticism of open-source software someone on the internet -- someone was complaining that the developers of GNUcash were dealing with memory leaks. I think they were using c or c++, and the complainer was saying they should migrate to java or python or something. If you're trying to make a computer program to solve problems, it's a waste of time to be solving computer problems. You should be solving the pre-existing human problem.
Ignoring problems won't make them go away. At some point you have to deal with memory management, either manually, as in plain C, or automatically, as in Java. It's not a waste of time solving 'computer' problems, because if you do not solve them, your program won't work. How do you think your ontological system will manage memory - by magic?
Currently with computers we are trying to abstract problems such as banking and business into simple logic puzzles. I think that's too much of a simplification. I think we need to create a virtual world full of basic human-percieved concepts, such as time, weather, humans, animals, etc. and create programs by manipulating those basic ideas and objects.
Easier said than done. Researchers have been experimenting with strong AI for decades, and have yet to produce any system that can operate in the same way you describe. Sure, you can string together simple logical concepts, but that's not how people think (apart from programmers). Natural language is littered with complex inferences, and designed to be processed by a great number of parallel analogue processors. Computers in 2006 lack the processing power, memory and architecture to operate an effective general interface with such a system.
The flow of control in the latter example is substantially easier to understand, but it is impossible to structure your code like this in the javascript environment, because there's no "wait for event/dispatch event" API available (which is how the 'execute' method in the latter example would work). Your javascript code was far more verbose than it needed to be. You could have written it like this instead:
new mydialogbox().execute({
success: function() {/* do stuff */ },
failure: function() {/* clean up without doing stuff */ } });
Or even like this:
new mydialogbox().execute(function(success) {
if (success) {// do stuff
}
else {// clean up without doing stuff
} );
And it seems to me that the latter example isn't so different to your hypothetical blocking function. It just has an extra layer of indentation.
Yes, I am. However in the context we're talking about (AJAX programming) you're stuck with the libraries you're given, so they become (at some level) one and the same thing. Yes, I'm aware of what javascript can do in different environments; I'm even considering using it as an extension language in my own apps. But that doesn't change the fact that writing advanced user interfaces using javascript in web browsers is more difficult than it should be. Fair enough. I tend to distinguish between languages and their libraries, because frequently one can have a problem with one, and not the other. Javascript's main weakness is its libraries, whilst for, say, Java, the main weakness is the syntax and grammar of the language.
Why do people keep this meme that C/C++ is so insecure? Remember, deep down inside the other languages, there often is a compiler, library, interpreter, etc written in C/C++.
C and C++ have a larger domain that can suffer from buffer overflows than languages with automatic memory management. In C, a buffer overflow can potentially occur at any point in your source code. In a language which automatically manages memory and checks bounds, the possible points at which buffer overflows can occur are reduced. This does not necessarily make the application more secure, but it does mean that there are less points at which it can be compromised.
When you are an expert programmer there are places where you need more efficiency than the super-safe string routines can give you. It's the job of the expert to determine exactly how to balance efficiency against security, and only C/C++ can give you this balance.
I'm not sure that the efficiency increase from dropping boundary checks is often necessary, except possibly in high-end 3D games. Also, many languages allow for binary libraries written in C, so it would be possible to write an application in C#, Python, Ruby or whatever, and farm out any efficiency-critical routines to a library.
The problem is that it encourages people to write substantially more complex front-end code in javascript than was ever attempted prior to the development of AJAX. And front-end javascript is notoriously difficult to do right: there are a lot of browser incompatibilities that need workarounds
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces.
Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript. It seems to me that the source of any problems with Javascript would be inadequate (and incompatible) libraries, rather than the language itself.
The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement.
A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
Its handling of common user interface elements is basic and often difficult to work with.
Again, it would appear you're more criticising the libraries, rather than the language.
very time I have to get down and dirty with it I think of that. Its Ok, and somethings are nice from a shorthand perspective if youre used to other lll, but for GODS Sake , Revise the spec and put some effort into it,
Are you complaining about the language itself, or the libraries?
The Haskell version may well be shorter but it generally takes a much longer time to write
So long as I'm not experimenting with unfamiliar territory, I find the opposite true. In Haskell, you can write functions that are very generic, and so I can reuse functionality much more often than in C#. Perhaps per line it takes longer, but overall I find myself considerably more productive in Haskell.
when somebody comes along to maintain the code, it is very difficult to understand the deeply nested recursion.
Again, this hasn't been my experience. I mostly use functions like map or fold, and in the rare case that I do need to explicitly define a recursive function, it's usually something simple. For example:
chunks n [] = [] chunks n xs = [take n xs] ++ (chunks n $ drop n xs)
It probably also runs 50x slower!
Actually, it ran around 15% faster than the C# version. This isn't too surprising; Haskell is compiled to machine code and is usually pretty good with recursive algorithms like mergesort, whilst.NET code runs in a VM and perhaps isn't so suited for this sort of algorithm.
I actually did a fair amount of Haskell 98 programming a few years back and while functional languages are certainly interesting Haskell has very few real applications.
The advantage of using C# over Haskell is largely due to the.NET standard library. Haskell, for all its neatness as a language, suffers from a lack of functions and frameworks, making it impractical for a large proportion of "real world" programming tasks. The other problem is that it's a very difficult language to use effectively.
However, that doesn't prevent me from wishing that the languages I do use for real world coding were just a little more expressive:)
Unfortunately I have to develop software in the real world. This (for the most part anyway) completely rules out every language you suggested. It sounds like you lack experience programming in the real world.
It's true that many companies standardize on mainstream languages like C# and Java, but its a mistake to think that these are the only languages used commercially. The company I work for primarily uses C#, but I've also done a lot of work with Ruby. Before I took this job, I also had an interview with a company that developed in Python. Whilst companies that use these languages are relatively uncommon, so are experienced developers with the necessary skill set, so it tends to balance out.
The problem with knowing a large number of programming languages is that the disadvantages of of each language become so much more clear. Recently, I was devising a class in C# and.NET 1.1 that would sort a large text file. My approach was standard enough; divide the file into chunks, sort each one in memory, and then progressively mergesort each file pair until only one output file remained. In C#, the class took well over 60 lines of code. In Haskell, it would have been barely over 6 (lazy evaluation is extremely useful for these sorts of problems).
Unfortunately, if you know this, programming in a language like C# can sometimes seem like pulling teeth. Programmers typically try to reduce the amount of repetitive work they do, and if you know that the majority of the code you're writing is redundant, it gets a bit wearing.
I'm not so sure about the quality of the documentation for.NET. I think there's sometimes a lack of useful examples, and the web version of the MSDN library is really slow.
The main disadvantage of C# is that it doesn't support the sort of advanced abstraction functionality that other languages do. That said, each version of C# shows impressive improvement, and with the upcoming 3.0 version, C# is looking not quite so bad anymore. However, even with lambda functions and the new LINQ system, it's still limited by inflexible typing and an incomplete object system, as well as some syntax cruft left over from C++.
That seems a little rich coming from a person who can't spell "Linux", and doesn't know what the phrase "Security by obscurity" means. Or perhaps you could explain how an OS can hold a large market share, be open source, and rely on security by obscurity.
It's a sad state of affairs, when an operating system has to be compared to high-tech, circa 1990.
I wouldn't be so hard on Vista. It's circa 2000, at the very least.
Okay, so it still lags behind OS X and Linux in terms of graphical capability, in virtualization, in its filesystem, its terminal, its file manager, its software installations, its desktop environment...
But with Vista, it's not so behind as it once was. It has that neat blurry transparency now (well, for high end machines anyway), and desktop widgets (well, almost), and a usable calendar integrated with the desktop. I believe it also has integrated desktop search as well, like Spotlight or Beagle, though I could be wrong. It's menu has been changed, so it's a little like that SLED menu Linux had a year or so ago. No multiple desktops yet, which is a pity, and the file manager barely competes with nautilus, let alone konqueror. The default browser isn't that good either, but luckily you can install Firefox pretty easily.
Perhaps, instead of writing inane replies, you should be trying to get Lunix to automatically detect hardware properly...
Ah, a genuine complaint! If you're going to troll, you need more of these. A troll that's mostly truth will catch more bait than a troll that's mostly clueless. Linux certainly has problems with some bits of hardware. I mean, sure, it doesn't have much trouble with motherboards, processors, monitors, graphics cards, memory, hard drives or DVD drives, but you should see the problems you can have with the wrong type of wireless card or webcam!
a neat little piece of work MS was doing back with Windows 95
You mean I could stick my wireless card and webcam into Windows 95 and they'd automatically work without having to mess around with CDs full of drivers? Huh, Windows XP has really gone downhill since then. Funny that I don't remember Windows 95 being able to do that...
Or, if that isn't to your liking, you could help get Lunix to install applications without manual assistance.
An interesting idea. I could even design a system that downloads and installs entire applications with just a single click of a button. I could call the system "apt", and... oh wait, that's already been done.
The problem with your troll is that you're dealing with old issues. Firstly, bring your complaints up to date. Incompatibility with wireless cards is a pretty modern problem. And of course the lack of popular software on Linux is a timeless classic - why can't it run Adobe Photoshop? Why can't it run this computer game?
You could also point out the incompatibilities between Linux distributions. Why isn't there a common installation process? Why are GTK themes incompatible with Qt themes? Why can't applications have a common file-chooser interface?
Those are the sorts of things you should be trolling about; not ancient problems that were only relevant last century. Linux has tonnes of problems with it; you shouldn't have any difficulty finding problems with modern Linux distros, and it's it'll make your troll a lot more tempting.
What a terribly dull and uninteresting troll. The misspelling of "Linux" is a mildly original touch, but everything else is depressingly old hat. And at least get a little more up to date; Linux servers may have been rare a decade ago, but its one of the most common server operating systems in widespread use. BeOS is another blast from the past, another indication that this troll is distinctly long in the tooth.
And no, mentioning Vista isn't fooling anyone, not when you then follow up with a paragraph talking about Windows 95, Windows 3.0 and INI files. At least find some trolling material that would be relevant this century. It sounds as if you just substituted "Vista" for "XP" and hoped no-one would notice.
But what happens if the user clicked exit by mistake? Perhaps you should have three buttons. Something like:
Close without savingCancelSave
Which funnily enough, is how GNOME handles it.
It's part of a growing community of some 40,000 independent developers, all building products using eBay's own application programming interfaces, or APIs--the connection points that let a program share data and respond to requests from other software. These applications are tailor-made to work seamlessly with eBay's core computing platform. eBay provides its APIs to the developers for free; its cost is limited to maintaining the code and providing some support resources for the developers.
This would appear to suggest that these are developers independent of eBay and not employed by them. On the other hand:
The result: eBay is able to publish a new version of its site every two weeks, adding 100,000 lines of code, all while in use. The system is never taken off-line for upgrades or maintenance.
It doesn't sound as if the 100,000 lines of code are from the 40,000 independent developers. Creating an application to interface with the eBay API doesn't seem to equate to publishing "a new version of its site". Of course, it's possible that the article has made a mistake.
The most competitive and successful beings on Earth are bacteria and insects. "It has yet to be proven that intelligence has any survival value,", as some wag once put it.
Perhaps a better choice of words would be "processor speed" rather than "intelligence", although one would also have to factor in algorithm efficiency. Bacteria, for instance, use what we would term as a P2P distributed genetic algorithm. Humans use the biological equivalent of large parallel supercomputers running advanced weighted neural network.
It's difficult to estimate processing ability, but since we're dealing with parallel systems, the processing speed is likely proportional to the storage size. Each human being has around 1e12 synapses. They're analogue, but lets assume that their effects can be approximated by a 1 kilobyte number. That would give us a memory size of 1e15 bytes, or 1 petabyte. There are around 6 billion humans, so that's a collective memory storage capability of 6e24 bytes.
On the other hand, there's around 5e30 bacteria (according to Google), and whilst they lack large processing systems like our brains, they will swap DNA the same way programmers pass around code (there's a fascinating article by Bruce Sterling on the subject of bacteria and how robust they are). So in terms of computational ability, it seems as if bacteria have more collective CPU power than humanity does.
I haven't looked into insect adaptation much, but it wouldn't surprise me if their collective CPU power exceeds humanity's as well.
It's so good to see that the delegation of priorities regarding Human Rights has now moved Robot one notch above Dark Skinned Human. We need a -1 Cynical moderation.
It's not insightful if the parent is obviously incorrect.
As an engineer, its easy for me to realize that no matter how sophisticated the software to mimic the emotions of humans, a robot is still a bunch of bolts and transistors at the base level. Basically, a very complicated game of mouse trap with transistors merely responding to stimuli. I imagine that people without an electrical background or interest in the subject can be duped more easily into believing a tool has rights, but I believe logic will win out in this one and robotic rights won't be a major issue. As a biologist, its easy for me to realize that no matter how sophisticated a neural network is, or how cleverly it mimics emotions, a human is still a bunch of cells and fluids at the base level. Basically, a very complicated game of mouse trap with neurons merely responding to stimuli. I imagine that people without an biological background or interest in the subject can be duped more easily into believing a biological creature has rights, but I believe logic will win out in this one and human rights won't be a major issue.
(Note: I am not actually a biologist, but for the sake of intellectual symmetry, just pretend that I am)
The OP made assumptions, but anthropomorphism was not one of them. If humanity met another intelligent species, I don't think our first thought would be "I wonder how quickly we can turn their planet into a CPU." Instead, the OP made the assumption that aliens would be primarily interested in increasing their intelligence. This is not an unreasonable assumption to make, as a greater intellect would likely make an creature more competitive and successful, and the more successful a creature is, the more numerous they are likely to become, and thus the more likely we are to run into them.
That said, larger brains have their downsides. They require more energy to sustain, and occupy a larger space. Human beings pay for this by having to eat relatively more food, and by having difficult and dangerous child births (due to the large size of our infant's heads). It may be that the disadvantages of intelligence create a peak efficiency, with those having too large a brain being less competitive than those with less intelligence. Incidentally, Accelerando, the novel the OP mentioned, deals with this issue in the latter half of the story.
I agree with you in general. A lot of languages have complexity that they don't necessarily need. One of the pieces of syntax that really annoys me is the 'new' operator in Java and C#, but I digress.
Whilst simplifying the formal structure of language is a good goal in general, I think that sometimes simplification can reduce ease of use. For instance, most languages use a combination of prefix and infix forms, whilst it would arguably make for a simpler grammar by just sticking to prefix notation. Similarly, some languages mark whitespace as significant (notably Python, but also languages like Haskell), which adds to readability (or at least, doesn't detract from it), whilst possibly being more difficult for a machine to parse.
Or, to put it another way, simplify a language too far and you get Lisp, which can be rather homogeneous and difficult for a human to read. So some complexity in a language's grammar would seem to be beneficial. Too much complexity, though, and you get the problems you illustrate.
What's easy for a computer to parse isn't necessarily easy for a human to parse. Languages that have a very simple syntax, such as Lisp, can be difficult for people to read because of their homogeneity.
Now, this doesn't apply in all cases, of course. A lot of languages have syntactical cruft they've picked up from their ancestors (those that can trace their lineage back to C tend to be the worst offenders). However, I think there's an advantage to some complexity, if used correctly, and if this makes it a little difficult to create syntax highlighting, then perhaps that's a reasonable trade off.
Think of the tables used by the nodes for routing as one gigantic divided secret. It is possible to prove that for a divided secret, you need only know one part more than 1/3 of all the parts before the secret is weak enough to be considered compromised. The question, then, is purely one of how to gain access to these tables. I don't think that's quite right. If there are 3 pieces of data encrypted with three different keys, then knowing what one of those pieces of information is doesn't necessarily help figure out what the other two pieces are.
Tor is pleasingly clever in the way it goes about ensuring anonymity. Each router in the Tor network publishes its IP address and public key on a directory server. The client picks a random sequence of router addresses, R1 to RN, and corresponding public keys, P1 to PN. It then encrypts each router address with the public key from the previous one in the sequence. You can think of this like an onion; each router decrypts its own layer with its private key, finds out what the next router in the sequence is, then discards that layer. This means that each router only knows the previous and next address, so unless all the routers are in collaboration, the complete sequence of routers is a secret distributed across N different routers.
Hidden services work by publishing a series of routes that lead to the hidden server. Because the routes are encrypted with the public keys of each router, one cannot tell where they lead just by looking at them. Communication between the hidden server and the client is also encrypted. Here's where my scant knowledge of Tor starts to break down, however I can make a series of educated guesses. Presumably the hidden server must be indistinguishable from a router, otherwise the routers on the end of the sequence could query the hidden server and get an idea of its content. If the hidden server cannot be distinguished from a router, then the routers at the end of the sequence have no way of telling whether they are at the end, or whether they're just another link in the chain. This would also mean that the published routes would have to be padded with random data to prevent the end server from gathering information from the size of the encrypted route.
Of course, this implies that either hidden services are published routers, or not all Tor routers are published publicly. I'm not sure how this works, or whether my reasoning leading up to this conclusion is incorrect. I'll endeavour to find out more, if only to sate my own curiousity.
There will be exactly one minimal fit for these conditions and this will be the topology of the network.
This won't work on Tor, for three reasons. First, there is no overall network topology. The routers merely act on routing instructions passed onto them via the client; they don't make connections autonomously, like, for instance, the nodes in a Gnutella network would do. Second, the hidden servers are not actually part of the Tor network; the routers merely act as middle men, stopping direct communication between the server and the client. Thirdly, I'm not aware of any caching that goes on between router nodes, nor can I see anything that would actually need caching.
One could try all possible routing permutations, but this would mean trying out R'!/(R'-R)! different routing paths, which would be difficult to conceal and would be infeasible for large values of R'. Also, if the ratio between R' and R is sufficiently large, then there will likely be a great number of permutations that generate similar latencies. One could take each permutation and perform timing attacks on the routers, but this would require access to the network traffic of the routers, and since the Tor routers are numerous and spread across many different countries, this would likely prove very difficult even for large government agencies. In short, this isn't a feasible attack.
Slashdot Mirror
No, I think the OP is broadly correct in his use of the term. Being jailed and presumably being put on some German equivalent of the sex offenders list does not improve one's reproductive chances.
Ignoring problems won't make them go away. At some point you have to deal with memory management, either manually, as in plain C, or automatically, as in Java. It's not a waste of time solving 'computer' problems, because if you do not solve them, your program won't work. How do you think your ontological system will manage memory - by magic?
Currently with computers we are trying to abstract problems such as banking and business into simple logic puzzles. I think that's too much of a simplification. I think we need to create a virtual world full of basic human-percieved concepts, such as time, weather, humans, animals, etc. and create programs by manipulating those basic ideas and objects.Easier said than done. Researchers have been experimenting with strong AI for decades, and have yet to produce any system that can operate in the same way you describe. Sure, you can string together simple logical concepts, but that's not how people think (apart from programmers). Natural language is littered with complex inferences, and designed to be processed by a great number of parallel analogue processors. Computers in 2006 lack the processing power, memory and architecture to operate an effective general interface with such a system.
C and C++ have a larger domain that can suffer from buffer overflows than languages with automatic memory management. In C, a buffer overflow can potentially occur at any point in your source code. In a language which automatically manages memory and checks bounds, the possible points at which buffer overflows can occur are reduced. This does not necessarily make the application more secure, but it does mean that there are less points at which it can be compromised.
When you are an expert programmer there are places where you need more efficiency than the super-safe string routines can give you. It's the job of the expert to determine exactly how to balance efficiency against security, and only C/C++ can give you this balance.I'm not sure that the efficiency increase from dropping boundary checks is often necessary, except possibly in high-end 3D games. Also, many languages allow for binary libraries written in C, so it would be possible to write an application in C#, Python, Ruby or whatever, and farm out any efficiency-critical routines to a library.
And how would you tell?
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces.Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript. It seems to me that the source of any problems with Javascript would be inadequate (and incompatible) libraries, rather than the language itself.
The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement.A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
Its handling of common user interface elements is basic and often difficult to work with.Again, it would appear you're more criticising the libraries, rather than the language.
Are you complaining about the language itself, or the libraries?
This sounds as if you believe there is no benefit to AJAX whatsoever. Perhaps you should have put a qualifier on the front, like "Most AJAX sucks"?
So long as I'm not experimenting with unfamiliar territory, I find the opposite true. In Haskell, you can write functions that are very generic, and so I can reuse functionality much more often than in C#. Perhaps per line it takes longer, but overall I find myself considerably more productive in Haskell.
when somebody comes along to maintain the code, it is very difficult to understand the deeply nested recursion.Again, this hasn't been my experience. I mostly use functions like map or fold, and in the rare case that I do need to explicitly define a recursive function, it's usually something simple. For example:
It probably also runs 50x slower!Actually, it ran around 15% faster than the C# version. This isn't too surprising; Haskell is compiled to machine code and is usually pretty good with recursive algorithms like mergesort, whilst .NET code runs in a VM and perhaps isn't so suited for this sort of algorithm.
I actually did a fair amount of Haskell 98 programming a few years back and while functional languages are certainly interesting Haskell has very few real applications.The advantage of using C# over Haskell is largely due to the .NET standard library. Haskell, for all its neatness as a language, suffers from a lack of functions and frameworks, making it impractical for a large proportion of "real world" programming tasks. The other problem is that it's a very difficult language to use effectively.
However, that doesn't prevent me from wishing that the languages I do use for real world coding were just a little more expressive :)
It's true that many companies standardize on mainstream languages like C# and Java, but its a mistake to think that these are the only languages used commercially. The company I work for primarily uses C#, but I've also done a lot of work with Ruby. Before I took this job, I also had an interview with a company that developed in Python. Whilst companies that use these languages are relatively uncommon, so are experienced developers with the necessary skill set, so it tends to balance out.
The problem with knowing a large number of programming languages is that the disadvantages of of each language become so much more clear. Recently, I was devising a class in C# and .NET 1.1 that would sort a large text file. My approach was standard enough; divide the file into chunks, sort each one in memory, and then progressively mergesort each file pair until only one output file remained. In C#, the class took well over 60 lines of code. In Haskell, it would have been barely over 6 (lazy evaluation is extremely useful for these sorts of problems).
Unfortunately, if you know this, programming in a language like C# can sometimes seem like pulling teeth. Programmers typically try to reduce the amount of repetitive work they do, and if you know that the majority of the code you're writing is redundant, it gets a bit wearing.
I'm not so sure about the quality of the documentation for .NET. I think there's sometimes a lack of useful examples, and the web version of the MSDN library is really slow.
The main disadvantage of C# is that it doesn't support the sort of advanced abstraction functionality that other languages do. That said, each version of C# shows impressive improvement, and with the upcoming 3.0 version, C# is looking not quite so bad anymore. However, even with lambda functions and the new LINQ system, it's still limited by inflexible typing and an incomplete object system, as well as some syntax cruft left over from C++.
That seems a little rich coming from a person who can't spell "Linux", and doesn't know what the phrase "Security by obscurity" means. Or perhaps you could explain how an OS can hold a large market share, be open source, and rely on security by obscurity.
It's a sad state of affairs, when an operating system has to be compared to high-tech, circa 1990.I wouldn't be so hard on Vista. It's circa 2000, at the very least.
Okay, so it still lags behind OS X and Linux in terms of graphical capability, in virtualization, in its filesystem, its terminal, its file manager, its software installations, its desktop environment...
But with Vista, it's not so behind as it once was. It has that neat blurry transparency now (well, for high end machines anyway), and desktop widgets (well, almost), and a usable calendar integrated with the desktop. I believe it also has integrated desktop search as well, like Spotlight or Beagle, though I could be wrong. It's menu has been changed, so it's a little like that SLED menu Linux had a year or so ago. No multiple desktops yet, which is a pity, and the file manager barely competes with nautilus, let alone konqueror. The default browser isn't that good either, but luckily you can install Firefox pretty easily.
Perhaps, instead of writing inane replies, you should be trying to get Lunix to automatically detect hardware properly...Ah, a genuine complaint! If you're going to troll, you need more of these. A troll that's mostly truth will catch more bait than a troll that's mostly clueless. Linux certainly has problems with some bits of hardware. I mean, sure, it doesn't have much trouble with motherboards, processors, monitors, graphics cards, memory, hard drives or DVD drives, but you should see the problems you can have with the wrong type of wireless card or webcam!
a neat little piece of work MS was doing back with Windows 95You mean I could stick my wireless card and webcam into Windows 95 and they'd automatically work without having to mess around with CDs full of drivers? Huh, Windows XP has really gone downhill since then. Funny that I don't remember Windows 95 being able to do that...
Or, if that isn't to your liking, you could help get Lunix to install applications without manual assistance.An interesting idea. I could even design a system that downloads and installs entire applications with just a single click of a button. I could call the system "apt", and... oh wait, that's already been done.
The problem with your troll is that you're dealing with old issues. Firstly, bring your complaints up to date. Incompatibility with wireless cards is a pretty modern problem. And of course the lack of popular software on Linux is a timeless classic - why can't it run Adobe Photoshop? Why can't it run this computer game?
You could also point out the incompatibilities between Linux distributions. Why isn't there a common installation process? Why are GTK themes incompatible with Qt themes? Why can't applications have a common file-chooser interface?
Those are the sorts of things you should be trolling about; not ancient problems that were only relevant last century. Linux has tonnes of problems with it; you shouldn't have any difficulty finding problems with modern Linux distros, and it's it'll make your troll a lot more tempting.
What a terribly dull and uninteresting troll. The misspelling of "Linux" is a mildly original touch, but everything else is depressingly old hat. And at least get a little more up to date; Linux servers may have been rare a decade ago, but its one of the most common server operating systems in widespread use. BeOS is another blast from the past, another indication that this troll is distinctly long in the tooth.
And no, mentioning Vista isn't fooling anyone, not when you then follow up with a paragraph talking about Windows 95, Windows 3.0 and INI files. At least find some trolling material that would be relevant this century. It sounds as if you just substituted "Vista" for "XP" and hoped no-one would notice.
Please do better next time.
But what happens if the user clicked exit by mistake? Perhaps you should have three buttons. Something like: Close without saving Cancel Save Which funnily enough, is how GNOME handles it.
You've said why it isn't like science; because it's not an open process. But why isn't it like engineering?
This would appear to suggest that these are developers independent of eBay and not employed by them. On the other hand:
The result: eBay is able to publish a new version of its site every two weeks, adding 100,000 lines of code, all while in use. The system is never taken off-line for upgrades or maintenance.It doesn't sound as if the 100,000 lines of code are from the 40,000 independent developers. Creating an application to interface with the eBay API doesn't seem to equate to publishing "a new version of its site". Of course, it's possible that the article has made a mistake.
Why would eBay need to add that quantity of code every fortnight? It doesn't strike me as an indicator of very efficient programming.
Perhaps a better choice of words would be "processor speed" rather than "intelligence", although one would also have to factor in algorithm efficiency. Bacteria, for instance, use what we would term as a P2P distributed genetic algorithm. Humans use the biological equivalent of large parallel supercomputers running advanced weighted neural network.
It's difficult to estimate processing ability, but since we're dealing with parallel systems, the processing speed is likely proportional to the storage size. Each human being has around 1e12 synapses. They're analogue, but lets assume that their effects can be approximated by a 1 kilobyte number. That would give us a memory size of 1e15 bytes, or 1 petabyte. There are around 6 billion humans, so that's a collective memory storage capability of 6e24 bytes.
On the other hand, there's around 5e30 bacteria (according to Google), and whilst they lack large processing systems like our brains, they will swap DNA the same way programmers pass around code (there's a fascinating article by Bruce Sterling on the subject of bacteria and how robust they are). So in terms of computational ability, it seems as if bacteria have more collective CPU power than humanity does.
I haven't looked into insect adaptation much, but it wouldn't surprise me if their collective CPU power exceeds humanity's as well.
It's not insightful if the parent is obviously incorrect.
(Note: I am not actually a biologist, but for the sake of intellectual symmetry, just pretend that I am)
The OP made assumptions, but anthropomorphism was not one of them. If humanity met another intelligent species, I don't think our first thought would be "I wonder how quickly we can turn their planet into a CPU." Instead, the OP made the assumption that aliens would be primarily interested in increasing their intelligence. This is not an unreasonable assumption to make, as a greater intellect would likely make an creature more competitive and successful, and the more successful a creature is, the more numerous they are likely to become, and thus the more likely we are to run into them.
That said, larger brains have their downsides. They require more energy to sustain, and occupy a larger space. Human beings pay for this by having to eat relatively more food, and by having difficult and dangerous child births (due to the large size of our infant's heads). It may be that the disadvantages of intelligence create a peak efficiency, with those having too large a brain being less competitive than those with less intelligence. Incidentally, Accelerando, the novel the OP mentioned, deals with this issue in the latter half of the story.
I agree with you in general. A lot of languages have complexity that they don't necessarily need. One of the pieces of syntax that really annoys me is the 'new' operator in Java and C#, but I digress.
Whilst simplifying the formal structure of language is a good goal in general, I think that sometimes simplification can reduce ease of use. For instance, most languages use a combination of prefix and infix forms, whilst it would arguably make for a simpler grammar by just sticking to prefix notation. Similarly, some languages mark whitespace as significant (notably Python, but also languages like Haskell), which adds to readability (or at least, doesn't detract from it), whilst possibly being more difficult for a machine to parse.
Or, to put it another way, simplify a language too far and you get Lisp, which can be rather homogeneous and difficult for a human to read. So some complexity in a language's grammar would seem to be beneficial. Too much complexity, though, and you get the problems you illustrate.
What's easy for a computer to parse isn't necessarily easy for a human to parse. Languages that have a very simple syntax, such as Lisp, can be difficult for people to read because of their homogeneity.
Now, this doesn't apply in all cases, of course. A lot of languages have syntactical cruft they've picked up from their ancestors (those that can trace their lineage back to C tend to be the worst offenders). However, I think there's an advantage to some complexity, if used correctly, and if this makes it a little difficult to create syntax highlighting, then perhaps that's a reasonable trade off.
Tor is pleasingly clever in the way it goes about ensuring anonymity. Each router in the Tor network publishes its IP address and public key on a directory server. The client picks a random sequence of router addresses, R1 to RN, and corresponding public keys, P1 to PN. It then encrypts each router address with the public key from the previous one in the sequence. You can think of this like an onion; each router decrypts its own layer with its private key, finds out what the next router in the sequence is, then discards that layer. This means that each router only knows the previous and next address, so unless all the routers are in collaboration, the complete sequence of routers is a secret distributed across N different routers.
Hidden services work by publishing a series of routes that lead to the hidden server. Because the routes are encrypted with the public keys of each router, one cannot tell where they lead just by looking at them. Communication between the hidden server and the client is also encrypted. Here's where my scant knowledge of Tor starts to break down, however I can make a series of educated guesses. Presumably the hidden server must be indistinguishable from a router, otherwise the routers on the end of the sequence could query the hidden server and get an idea of its content. If the hidden server cannot be distinguished from a router, then the routers at the end of the sequence have no way of telling whether they are at the end, or whether they're just another link in the chain. This would also mean that the published routes would have to be padded with random data to prevent the end server from gathering information from the size of the encrypted route.
Of course, this implies that either hidden services are published routers, or not all Tor routers are published publicly. I'm not sure how this works, or whether my reasoning leading up to this conclusion is incorrect. I'll endeavour to find out more, if only to sate my own curiousity.
This won't work on Tor, for three reasons. First, there is no overall network topology. The routers merely act on routing instructions passed onto them via the client; they don't make connections autonomously, like, for instance, the nodes in a Gnutella network would do. Second, the hidden servers are not actually part of the Tor network; the routers merely act as middle men, stopping direct communication between the server and the client. Thirdly, I'm not aware of any caching that goes on between router nodes, nor can I see anything that would actually need caching.
One could try all possible routing permutations, but this would mean trying out R'!/(R'-R)! different routing paths, which would be difficult to conceal and would be infeasible for large values of R'. Also, if the ratio between R' and R is sufficiently large, then there will likely be a great number of permutations that generate similar latencies. One could take each permutation and perform timing attacks on the routers, but this would require access to the network traffic of the routers, and since the Tor routers are numerous and spread across many different countries, this would likely prove very difficult even for large government agencies. In short, this isn't a feasible attack.