An old saying: "Jack of all trades, master of none."
This is true for programming as well. You can aquire a deep understanding of a few languages, or basic survival skills in dozens. Aquiring a deep understanding in dozens of languages is a truly exceptional feat. I agree that it's difficult to acquire a deep understanding of most languages. One can study Java and all its related libraries and frameworks for years and still not learn it all. Indeed, my last job was as a Java programmer, and whilst I'm pretty familiar with several web frameworks, libraries and GUI toolkits, I have little knowledge about, say, the SecurityManager class, or J2ME, or JMS.
But on the other hand, I disagree that a deep understanding of a single language is more useful than a working knowledge of a dozen (as you seem to imply). A good programmer needs to know the limitations of the environment that he or she is working in, and the only way to do this is via comparison. Furthermore, learning different languages exposes you to different ways of thinking about a problem; if you don't learn a good spread of languages, your perspective is severely limited, and this naturally affects your ability to solve problems efficiently. To use a metaphor, I believe stepping back and seeing the whole wood is more important than gaining detailed information about a single tree.
Finally, I'm not sure I'd say that the only alternative to a deep understanding is "basic survival skills". Perhaps instead:
You can aquire a deep understanding of a few languages, or a good working knowledge in dozens.
But all Real Programmers know all languages! At least that's what Slashdot keeps telling me... Whilst it's obviously an exaggeration to state that any experienced programmer is familiar with all computer languages, I feel I should point out than any programmer worth his salt should have a wide enough knowledge as to make learning a good proportion (if not the majority) of programming languages a fairly trivial task. Haskell is one of the exceptions, as it has a lot of features that are not found in many other languages. But most programming languages have a great deal of syntactical overlap, especially more 'mainstream' languages.
Just out of curiosity, why not? And what would you suggest instead? A Wiki is essentially just an editable website. It must be manually ordered; tables of contents put in, pages linked to other pages, and so forth. This is find for data that has a very general structure, such as an encyclopaedia or a manual of some kind. But the Rosetta Stone concept is highly structured, cross-referencing programming languages with programming problems, and it seems to me as if this cross-referencing would be better done automatically, rather than making several Wiki pages and maintaining them manually. The site concept would be better suited to some sort of customised CMS, or perhaps something designed from scratch.
But as a seasoned programmer I also know that some tasks can't be ported. A more efficient method is to actually resolve the problems at link time since most object files doesn't really care about which language you use. If you look at the programming tasks the website attempts to translate, you'll notice that they are extremely basic and generic. I don't think the aim of the website is to translate some complex library into another language; rather to provide a learning resource where programmers can see how to map simple tasks from one language to another, which presumably will help them better understand a new language. Remember that the original Rosetta stone was used for a similar purpose.
This site could be useful, but MediaWiki doesn't seem the best tool to use, and the content so far is rather sparse. I'm uncertain whether this will prove a success; it's an interesting concept, but many interesting concepts have fallen by the wayside.
I took a look at the Google Cache of the article, and it would appear this is old news. This is the collision attack first found back in February 2005, which requires fewer than 2^69 operations, rather than the 2^80 operations a brute force approach would need (see Wikipedia and Bruce Schneider's Blog). According to Wikipedia, this was later improved so that fewer than 2^63 operations were needed.
In other words, this attack is 2^17, or 131,072 times faster than brute forcing the hash, and from what I've read, this is considered pretty impressive stuff. That said, crypto researchers have known for a while that SHA-1 is on its last legs. From Schneider's blog in February, 2005:
Jon Callas, PGP's CTO, put it best: "It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off." That's basically what I said last August. So there's nothing much to see here, except a sensationalist newspaper article. This has almost certainly been reported before on Slashdot two years ago, so this story probably counts as a dupe.
The "moron" noted that highly-rated comments in other threads express views that are possibly inconsistent with the highly-rated comments in this thread./. isn't a hive mind, but in aggregate, the moderation reflects a collective opinion. It would reflect a collective opinion if posts were moderated up and down in equal measure, or if there were no limit on how high a post could be moderated. This is not the case, as posts tend to be moderated up rather more often than they are moderated down, and the score of each post is limited to the range -1 to 5. Thus, your argument that Slashdot moderation reflects a collective opinion may not be valid.
To illustrate this, consider two ideologically opposed groups, A and B, where A has a two-thirds majority. In a system where posts are moderated up and down in equal measure, then posts appealing to group A would be modded up by two thirds of the mods, and modded down by one third, giving an overall score of 50% above the average. Likewise, posts appealing to group B would be modded up by one third, and modded down by two thirds, giving a score of 50% below average. The same effect can be seen on a moderation system with no upper limit.
However, on Slashdot, where posts are generally modded up far more often than modded down, and there is a maximum score of 5, then these effects are not seen. A post appealing to group A will be modded up to 4 or 5, but so will a post appealing to group B. One could make the argument that from this, one would expect to see 2/3rds more posts agreeing with A than B. However, the number of posts moderated highly is relatively small, and not all moderators have a strong viewpoint on a particular issue. Conclusions generated from the patterns of Slashdot moderation are, therefore, rather tenuous.
I was talking about multiplying the 8264.46 figure by 8. I probably should have been more specific, but I'd have thought it would have been obvious from the context.
$1,000,000 divided by 121 people = 8264.46 per person. I'm convinced taking people's money through legitimate avenues is easier than through crime.
Whilst this may be true in a country like the USA, it's worth noting that the difference between average incomes between western Europe and Russia make it more profitable than it might seem at first glance. The average yearly salary in Russia is around $4800, whilst the average salary in countries like the US and Sweden is about 8 times that.
Multiplying by 8 gives $66,116, and whilst I suspect such a figure would still not be worth the risk of being caught (and with 121 people involved, there's got to be an increased chance of someone slipping up), it's probably a lot more attractive than the figure of $8264.46 would suggest.
I agree with you in general that AJAX is only going to become more common, and done right, AJAX has many benefits. However, stop saying things like this:
the net and browser really are becoming the operating system
Because it's akin to suggesting that we replace the engine of a car with a GPS receiver or an iPod.
I'd hesitate to imply that PHP frameworks like CakePHP are better than Ruby on Rails. PHP's syntax is extremely limited compared to Ruby's, and these limitations are visible in any PHP web framework.
Compared to Django, Rails has more functionality directed toward maintaining AJAX sites (such as RJS templates). Ruby also has a few advantages over Python in terms of the flexibility of the language. On the other hand, Ruby lacks Unicode support and is significantly slower than Python.
I haven't really played around with Zope, so I can't comment on that.
You have a great command of the language, but since you offered that caveat, I thought I'd try to clarify this metaphor for you.
The phrase "looking through rose-colored glasses" is usually used perjoratively, and directed at an optimist by a realist. I suspect that the majority of native English speakers wouldn't know what the word "perjoratively" means, and since you have an extra "r" in there, looking up a definition for the word might be difficult (the correct spelling is "pejoratively").
We can't see quarks directly, not even with instruments. We can see particular phenomena that are well explained by a model involving these hypothetical constructs called quarks. But our model predicts that we will never ever ever see quarks directly, not even only as well as we can see atoms with an STM. So are they real? Well, the theory works quite well, so maybe it makes sense to say that they are real.
Yes, that touches on the point I was (perhaps unsuccessfully) trying to make. It may be that quarks are just a convenient fiction that allows us to model a fundamentally more complex universe. Whether they are 'real' or not is unknowable, as there may be an experiment we have yet to perform that would contradict our current models, and hence is largely immaterial. As you say, the theory works quite well, so it makes sense to at least pretend they exist, as we can then use the theory to make pretty accurate predictions.
String theory, as I understand it, works at the Planck Length. Unfortunately, the energies needed to experiment with individual particles or strings of that size are enormous, and is are unlikely to be possible to achieve at any time in the foreseeable future. So in order to test string theory, we'd need to come up with certain predictions that we can observer on the mere subatomic level, which would provide evidence toward string theory's correctness. As I understand it, no-one's come up with any testable predictions string theory makes that the standard model doesn't.
What do you mean real? Call me back when you see a real electron. Or better yet, when you see a real quark. Superstrings are just as real as either of these. In fact, unless I misunderstand, electrons and quarks would merely be a special case of strings, that is, strings carrying particular vibrational modes.
I was under the impression that superstrings are undetectable by current scientific instruments, which is why some physicists really don't like them. You might not be able to see an individual electron, but one can quite easily trace its path, or at least what appears to be its path, and the paths of quarks can be inferred from observational evidence also. I'm not aware of any experiment that has been carried out to test the validity of string theory in the same way.
Of course, doing so completely misses the original poster's point, as you have done.
Still, Fortran is not particularly famous for its expressiveness, and to claim its conciseness as a major strength is somewhat incorrect. 57 lines is a lot to create a calendar in, even with a banner font; I'd imagine you could do it in less lines even in C.
Unfortunately, it's not a very good benchmark, as the appearance and size of the banner font was not specified. Also, the original poster was probably not aiming for byte-crushing compact as an experienced Perl programmer could get it.
When I call my bank, they never ask me for say, my full telephone pin. They ask for 2 random digits.
I cannot abide this. It makes logging in a extremely painful procedure, as the human mind remembers words in sequence. Ask a person to type out the word 'impossible' and any reasonably proficient computer user will have it typed out in a second; but ask a person to give you the 7th letter and suddenly it takes a lot more time, especially when you don't have it written down. It's even worse when dealing with passwords of random letters and numbers, as they're so much less familiar. Asking for random letters is a huge pain in the backside for users.
Secondly, this security measure only actually makes any difference if the user's computer has been compromised, and is only effective against the most basic of keyloggers. It may prevent a script kiddie from accidentally coming across your password, but it's not going to stop anyone who actually wants to break into your account, and has access to your computer. Further, a computer user who's system is compromised likely has a somewhat lax approach to security; given the relatively tiresome task of remembering the nth digit from their password, wouldn't this just encourage them to write down their password? Or perhaps the user just chooses a really simple password.
The random-letters security scheme does not strike me as one that's particularly effective in preventing fraud.
Patents work like land title. Your analogy is tenuous. Land titles last indefinitely; patents last only a limited period. Land is a limited physical resource; a patented idea is information that can be used an unlimited number of times. Whilst there are similarities between the concepts, the differences are far more numerous.
Would it be possible to build a house without title? Sure, the same way it's possible to build a tech business without patents. Presumably, a software developer counts as a "tech business", in which case it's worth noting that there are many tech businesses in the EU and elsewhere that are not protected by patents.
The title system takes the risk out of land development, much like the patent system takes the risk out of technological development. Does software count as "technological development", or are you limiting your argument to hardware? If you do count software as a technological development, could you provide some evidence that US software companies are, (a) investing proportionally more on average in software development than software companies in the EU, and (b) that this is the direct result of software patents.
What all of the "PHP is insecure" claims refuse to recognise is that virtually all of the vulnerabilities reported would be no different had the application been written in some other language.
Most complaints seem to revolve around PHP's SQL handling and PHP.ini inconsistencies. Can you name another programming language where the language semantics can be altered via a global ini file? How many other languages advocate using insecure functions in the official manual? To quote the PHP manual on addslashes:
Returns a string with backslashes before characters that need to be quoted in database queries etc.
And:
An example use of addslashes() is when you're entering data into a database.
This would rather suggest to those unfamiliar with the language that addslashes should be used to database input, rather than using the quoting function provided by the database libraries themselves. A better way of doing it would be to do the same thing as every other web language in common use and pass user input in as arguments, e.g.:
sql.execute("SELECT * FROM users WHERE name LIKE ?", username)
This way, the database object would automatically quote the input in a secure and database-dependant fashion. Of course, one could easily use a library or write a function that does the same thing, but why doesn't PHP have something like that by default?
I was talking about general autorun mechanisms such as Windows' start menu or KDE's equivalent feature, or shell rc files.
Are you talking about start-up scripts? I guess you could write a program that put a fork bomb in the users' startup folder when executed, just as you could write a program that deleted everything in the user's home directory. On most modern operating systems, you should be very careful when executing an unknown file.
It doesn't necessarily have to be that way, though. There are a number of tools available for OSes like Linux and BSD that give very fine grained control over the permissions of executed files. You could set up a policy using something like Systrace that would limit a process to a single directory and a small slice of processing time and memory. Indeed, you could be even more clever, and make it virtually impossible for even the most insidious of executables from doing any damage when run.
However, most Linux and BSD systems are designed to work entirely from signed and validated software packages provided by the distributor, so little benefit would be gained from such a system. Windows would benefit the most from this sort of thing, but I can't see Microsoft implementing it any time soon.
fork bomb + autorun = bad experience on ANY platform You can limit the amount of child processes a process can spawn on most Unix-like operating systems. Presumably, security conscious Linux or BSD distributions will limit this by default. Also, I believe it's only Windows that automatically executes applications on CDs and DVDs without first prompting the user.
Real modularity, based on Unix pipes, could completely decouple the GUI from the code. This would be a Very Good Thing.
Based on Unix pipes? Seriously?
Right now, the biggest obstacle to any sort of Unix/Linux on the desktop is the inconsistency in GUIs.... If we had our UIs decoupled from our apps, it would take very little time to gather all sorts of old code and put together a consistent GUI from X widget libraries.
Decoupling the UI and application layer would not automatically result in compatibility between UIs. You'd first have to get everyone to agree on a common interface (which in itself is a whole can of worms, and made even more difficult due to different layout engines, different widgets etc.). But a common interface can be achieved whether you're using pipes or binary libraries, the only difference between the two being that pipes would be considerably less efficient, with little appreciable advantages.
Of course, almost all free software and desktop efforts and development remain unquestioningly oriented around Linux.
No, no they aren't. No critical functionality in KDE or GNOME relies on the Linux kernel, and both desktops will run happily in the various BSDs. So maybe a more accurate question for Ask Slashdot would be, "Why are Free-Desktop developers wedded to the X Window System?"
I'm not particularly knowledgeable about the merits of X, but there are a number of advantages to using it that I can think of off the top of my head:
It's based on an open standard.
The most often used open source implementation of it, X.Org, supports a large number of graphics cards.
X.Org 7.1 and up support hardware acceleration via AIGLX, allowing for window distortions, particle effects, alpha blending, etc.
It's already used by a lot of other projects and is in active development.
It's network transparent.
An often cited reason for using a non-Microsoft OS is to avoid a monoculture, but free-desktop efforts have created a total monoculture around developing and promoting Linux, despite a decade of failure in supplanting Microsoft's proprietorial OSes with it.
I'll mentally sustitute "Linux" with "X" here. What exactly makes the equivalent GUI layer on Windows significantly better than X.org? I can't think of anything; so it would seem that we cannot blame X.org for Linux failing to achieve a large market share.
Indeed, it's debatable whether the desktop is to blame at all. I'd have thought it was more to do with lack of compatibility with Windows applications, and that again would seem to be a problem that's largely independant of the kernel or the desktop. You can run Wine or Mono applications on KDE, GNOME, Linux or BSD; the problems with Wine or Mono aren't anything to do with the systems on which they run.
Which means that we should as soon as possible, start entangling particles inside of a quantum observed/not-observed telegraph machine. Then send them out in every direction. This would, given time, create a galactic telegraph system that would work outside the laws of physics that limit the transmission of information to the speed of light.
There are a two problems with that idea:
The telegraph machines would only have a finite number of entangled particles, and once observed, they resolve themselves to a fixed state and cannot be used again.
When an entangled particle is observed, it randomly collapses into one state or the other, so no information is actually transferred at the speed of light. Perhaps if it were possible to influence the state of the particle by observing it in a certain way, but we have yet to discover any effect like that, and it may even be quite impossible.
No one has yet to succeed in sending information faster than light. Quantum entanglement is an alluring possibility that suggests it may be possible, but it could also be a red herring.
How does Java's or Python's garbage collection work -- magic? No, what happened was that people solved the problem once already, in a re-useable way, so that we don't have keep solving them every time we write a program. The idea is to make progress, to make things easier. If you're writing an accounting program, you should be worrying about accounting problems, not memory management. Or do you think all programs should be written in assembly? I agree with you in general, you just gave the impression that it didn't matter whether GNUcash was programmed in C or whether in Python or Java. It sounded as if you dismissed such issues as irrelevant, when I'd have thought that programming GNUcash in, say, Python, sounds a reasonable idea.
Basically all I'm saying is that for most programming jobs, we are still working at too low of a level. We seem to think that real programmers need to work at the memory-manipulating level, and if you're not doing that, you're not doing real programming. Well, not every smart, talented person working in programming needs to be doing memory management. Again, I agree with you that low level programming is unnecessary for many tasks. However, it's a mistake to think that programming in a high level language is necessarily easier than programming in a low level language, any more than a 3D artist working for Pixar has an easier time than the programmer who is developing the animation package the artist will use. Whilst high level languages allow you to achieve simple things with less effort than in a low level language, they also pave the way for added complexities.
For instance, contrast assembly to a language like Java. You can create a dynamically sized list of numbers easily in Java, whilst doing the same thing in assembly would be a lot of work. On the other hand, the problems that a Java programmer has to deal with are usually more complex than those an assembly programmer would need to face, and Java is also a relatively more complex language. It seems to me as if programming won't get any easier in future; the problems will just get harder.
Furthermore, just because a language is higher level, doesn't make it easier to understand or comprehend. Compare these two code snippets:
In Java:
void main(string[] args) {
int a = 1;
int b = 1;
System.out.println(a);
System.out.println(b);
for (int i = 2; i < 10; i++)
{
int x = b;
b = a + b;
a = b;
System.out.println(b);
} }
Whilst Haskell is clearly the more powerful and expressive language, it also relies on concepts that aren't immediately obvious. It seems to me that there's no guarantee that programming in the future will be any simpler than it is now.
I've never understood this part of quantum mechanics. The papers in your example didn't magically change color because they weren't being observed. One was always black and one was always white. The uncertainty only comes into play as to which person gets which color slip of paper.
Particles frequently behave contrary to what common sense would suggest. Experiments tend to show that when a particle is unobserved, it exists in all possible states, whilst when it is observed, it collapses back into one.
Particles can also be entangled with one another, such that, for example, one particle is always the opposite of another. Perhaps it's not unreasonable to consider observation as merely a form of entanglement.
By this logic, my dog can recite the complete works of shakespeare in esparanto.... unless somebody is in listening distance.
More accurately, the dog would be in all possible states, until observed, much like a famous cat.
Slashdot Mirror
This is true for programming as well. You can aquire a deep understanding of a few languages, or basic survival skills in dozens. Aquiring a deep understanding in dozens of languages is a truly exceptional feat. I agree that it's difficult to acquire a deep understanding of most languages. One can study Java and all its related libraries and frameworks for years and still not learn it all. Indeed, my last job was as a Java programmer, and whilst I'm pretty familiar with several web frameworks, libraries and GUI toolkits, I have little knowledge about, say, the SecurityManager class, or J2ME, or JMS.
But on the other hand, I disagree that a deep understanding of a single language is more useful than a working knowledge of a dozen (as you seem to imply). A good programmer needs to know the limitations of the environment that he or she is working in, and the only way to do this is via comparison. Furthermore, learning different languages exposes you to different ways of thinking about a problem; if you don't learn a good spread of languages, your perspective is severely limited, and this naturally affects your ability to solve problems efficiently. To use a metaphor, I believe stepping back and seeing the whole wood is more important than gaining detailed information about a single tree.
Finally, I'm not sure I'd say that the only alternative to a deep understanding is "basic survival skills". Perhaps instead: You can aquire a deep understanding of a few languages, or a good working knowledge in dozens.
This site could be useful, but MediaWiki doesn't seem the best tool to use, and the content so far is rather sparse. I'm uncertain whether this will prove a success; it's an interesting concept, but many interesting concepts have fallen by the wayside.
In other words, this attack is 2^17, or 131,072 times faster than brute forcing the hash, and from what I've read, this is considered pretty impressive stuff. That said, crypto researchers have known for a while that SHA-1 is on its last legs. From Schneider's blog in February, 2005: Jon Callas, PGP's CTO, put it best: "It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off." That's basically what I said last August. So there's nothing much to see here, except a sensationalist newspaper article. This has almost certainly been reported before on Slashdot two years ago, so this story probably counts as a dupe.
To illustrate this, consider two ideologically opposed groups, A and B, where A has a two-thirds majority. In a system where posts are moderated up and down in equal measure, then posts appealing to group A would be modded up by two thirds of the mods, and modded down by one third, giving an overall score of 50% above the average. Likewise, posts appealing to group B would be modded up by one third, and modded down by two thirds, giving a score of 50% below average. The same effect can be seen on a moderation system with no upper limit.
However, on Slashdot, where posts are generally modded up far more often than modded down, and there is a maximum score of 5, then these effects are not seen. A post appealing to group A will be modded up to 4 or 5, but so will a post appealing to group B. One could make the argument that from this, one would expect to see 2/3rds more posts agreeing with A than B. However, the number of posts moderated highly is relatively small, and not all moderators have a strong viewpoint on a particular issue. Conclusions generated from the patterns of Slashdot moderation are, therefore, rather tenuous.
I was talking about multiplying the 8264.46 figure by 8. I probably should have been more specific, but I'd have thought it would have been obvious from the context.
Whilst this may be true in a country like the USA, it's worth noting that the difference between average incomes between western Europe and Russia make it more profitable than it might seem at first glance. The average yearly salary in Russia is around $4800, whilst the average salary in countries like the US and Sweden is about 8 times that.
Multiplying by 8 gives $66,116, and whilst I suspect such a figure would still not be worth the risk of being caught (and with 121 people involved, there's got to be an increased chance of someone slipping up), it's probably a lot more attractive than the figure of $8264.46 would suggest.
I agree with you in general that AJAX is only going to become more common, and done right, AJAX has many benefits. However, stop saying things like this:
the net and browser really are becoming the operating systemBecause it's akin to suggesting that we replace the engine of a car with a GPS receiver or an iPod.
I'd hesitate to imply that PHP frameworks like CakePHP are better than Ruby on Rails. PHP's syntax is extremely limited compared to Ruby's, and these limitations are visible in any PHP web framework.
Compared to Django, Rails has more functionality directed toward maintaining AJAX sites (such as RJS templates). Ruby also has a few advantages over Python in terms of the flexibility of the language. On the other hand, Ruby lacks Unicode support and is significantly slower than Python.
I haven't really played around with Zope, so I can't comment on that.
The phrase "looking through rose-colored glasses" is usually used perjoratively, and directed at an optimist by a realist. I suspect that the majority of native English speakers wouldn't know what the word "perjoratively" means, and since you have an extra "r" in there, looking up a definition for the word might be difficult (the correct spelling is "pejoratively").
Yes, that touches on the point I was (perhaps unsuccessfully) trying to make. It may be that quarks are just a convenient fiction that allows us to model a fundamentally more complex universe. Whether they are 'real' or not is unknowable, as there may be an experiment we have yet to perform that would contradict our current models, and hence is largely immaterial. As you say, the theory works quite well, so it makes sense to at least pretend they exist, as we can then use the theory to make pretty accurate predictions.
String theory, as I understand it, works at the Planck Length. Unfortunately, the energies needed to experiment with individual particles or strings of that size are enormous, and is are unlikely to be possible to achieve at any time in the foreseeable future. So in order to test string theory, we'd need to come up with certain predictions that we can observer on the mere subatomic level, which would provide evidence toward string theory's correctness. As I understand it, no-one's come up with any testable predictions string theory makes that the standard model doesn't.
I was under the impression that superstrings are undetectable by current scientific instruments, which is why some physicists really don't like them. You might not be able to see an individual electron, but one can quite easily trace its path, or at least what appears to be its path, and the paths of quarks can be inferred from observational evidence also. I'm not aware of any experiment that has been carried out to test the validity of string theory in the same way.
Still, Fortran is not particularly famous for its expressiveness, and to claim its conciseness as a major strength is somewhat incorrect. 57 lines is a lot to create a calendar in, even with a banner font; I'd imagine you could do it in less lines even in C.
Unfortunately, it's not a very good benchmark, as the appearance and size of the banner font was not specified. Also, the original poster was probably not aiming for byte-crushing compact as an experienced Perl programmer could get it.
I cannot abide this. It makes logging in a extremely painful procedure, as the human mind remembers words in sequence. Ask a person to type out the word 'impossible' and any reasonably proficient computer user will have it typed out in a second; but ask a person to give you the 7th letter and suddenly it takes a lot more time, especially when you don't have it written down. It's even worse when dealing with passwords of random letters and numbers, as they're so much less familiar. Asking for random letters is a huge pain in the backside for users.
Secondly, this security measure only actually makes any difference if the user's computer has been compromised, and is only effective against the most basic of keyloggers. It may prevent a script kiddie from accidentally coming across your password, but it's not going to stop anyone who actually wants to break into your account, and has access to your computer. Further, a computer user who's system is compromised likely has a somewhat lax approach to security; given the relatively tiresome task of remembering the nth digit from their password, wouldn't this just encourage them to write down their password? Or perhaps the user just chooses a really simple password.
The random-letters security scheme does not strike me as one that's particularly effective in preventing fraud.
Most complaints seem to revolve around PHP's SQL handling and PHP.ini inconsistencies. Can you name another programming language where the language semantics can be altered via a global ini file? How many other languages advocate using insecure functions in the official manual? To quote the PHP manual on addslashes:
Returns a string with backslashes before characters that need to be quoted in database queries etc.And:
An example use of addslashes() is when you're entering data into a database.This would rather suggest to those unfamiliar with the language that addslashes should be used to database input, rather than using the quoting function provided by the database libraries themselves. A better way of doing it would be to do the same thing as every other web language in common use and pass user input in as arguments, e.g.:
This way, the database object would automatically quote the input in a secure and database-dependant fashion. Of course, one could easily use a library or write a function that does the same thing, but why doesn't PHP have something like that by default?
Language bashing is funAnd sometimes legitimate.
Are you talking about start-up scripts? I guess you could write a program that put a fork bomb in the users' startup folder when executed, just as you could write a program that deleted everything in the user's home directory. On most modern operating systems, you should be very careful when executing an unknown file.
It doesn't necessarily have to be that way, though. There are a number of tools available for OSes like Linux and BSD that give very fine grained control over the permissions of executed files. You could set up a policy using something like Systrace that would limit a process to a single directory and a small slice of processing time and memory. Indeed, you could be even more clever, and make it virtually impossible for even the most insidious of executables from doing any damage when run.
However, most Linux and BSD systems are designed to work entirely from signed and validated software packages provided by the distributor, so little benefit would be gained from such a system. Windows would benefit the most from this sort of thing, but I can't see Microsoft implementing it any time soon.
Based on Unix pipes? Seriously?
Right now, the biggest obstacle to any sort of Unix/Linux on the desktop is the inconsistency in GUIs.... If we had our UIs decoupled from our apps, it would take very little time to gather all sorts of old code and put together a consistent GUI from X widget libraries.Decoupling the UI and application layer would not automatically result in compatibility between UIs. You'd first have to get everyone to agree on a common interface (which in itself is a whole can of worms, and made even more difficult due to different layout engines, different widgets etc.). But a common interface can be achieved whether you're using pipes or binary libraries, the only difference between the two being that pipes would be considerably less efficient, with little appreciable advantages.
Could you give some specific examples with what is wrong with X11, or is this merely an opinion piece?
No, no they aren't. No critical functionality in KDE or GNOME relies on the Linux kernel, and both desktops will run happily in the various BSDs. So maybe a more accurate question for Ask Slashdot would be, "Why are Free-Desktop developers wedded to the X Window System?"
I'm not particularly knowledgeable about the merits of X, but there are a number of advantages to using it that I can think of off the top of my head:
- It's based on an open standard.
- The most often used open source implementation of it, X.Org, supports a large number of graphics cards.
- X.Org 7.1 and up support hardware acceleration via AIGLX, allowing for window distortions, particle effects, alpha blending, etc.
- It's already used by a lot of other projects and is in active development.
- It's network transparent.
An often cited reason for using a non-Microsoft OS is to avoid a monoculture, but free-desktop efforts have created a total monoculture around developing and promoting Linux, despite a decade of failure in supplanting Microsoft's proprietorial OSes with it.I'll mentally sustitute "Linux" with "X" here. What exactly makes the equivalent GUI layer on Windows significantly better than X.org? I can't think of anything; so it would seem that we cannot blame X.org for Linux failing to achieve a large market share.
Indeed, it's debatable whether the desktop is to blame at all. I'd have thought it was more to do with lack of compatibility with Windows applications, and that again would seem to be a problem that's largely independant of the kernel or the desktop. You can run Wine or Mono applications on KDE, GNOME, Linux or BSD; the problems with Wine or Mono aren't anything to do with the systems on which they run.
There are a two problems with that idea:
No one has yet to succeed in sending information faster than light. Quantum entanglement is an alluring possibility that suggests it may be possible, but it could also be a red herring.
For instance, contrast assembly to a language like Java. You can create a dynamically sized list of numbers easily in Java, whilst doing the same thing in assembly would be a lot of work. On the other hand, the problems that a Java programmer has to deal with are usually more complex than those an assembly programmer would need to face, and Java is also a relatively more complex language. It seems to me as if programming won't get any easier in future; the problems will just get harder.
Furthermore, just because a language is higher level, doesn't make it easier to understand or comprehend. Compare these two code snippets:
In Java: In Haskell: Whilst Haskell is clearly the more powerful and expressive language, it also relies on concepts that aren't immediately obvious. It seems to me that there's no guarantee that programming in the future will be any simpler than it is now.
Particles frequently behave contrary to what common sense would suggest. Experiments tend to show that when a particle is unobserved, it exists in all possible states, whilst when it is observed, it collapses back into one.
Particles can also be entangled with one another, such that, for example, one particle is always the opposite of another. Perhaps it's not unreasonable to consider observation as merely a form of entanglement.
By this logic, my dog can recite the complete works of shakespeare in esparanto.... unless somebody is in listening distance.More accurately, the dog would be in all possible states, until observed, much like a famous cat.