Your argument is that since a feature might not be available in all situations, it is a bad idea to implement it at all. Along your line of reasoning, all GUIs are evil, since you sometimes only have terminal access. Hell, if I'm stranded on a tiny island in the middle of the ocean, I don't even have a computer, so any software is evil by your logic.
Of course, any feature that a shell implements should fail gracefully. In fish (my shell), if there is no X server connected, fish simply takes care of it's own copy and paste buffer. But it does not make sense to have one such buffer for each shell that is running.
30 years? MS-DOS is a little over 20 years old, but definitely not 30. And at it's time it was an ok shell. Not good, definitley not as good as the Unix shells of that time, but not horrible either.
Why should not a commandline interface use syntax highlighting to improve readibility and highlight errors? And yes bash does have programmable completions, but there are a lot of possible improvements, like descriptions of each completion (when completing a maunal page, show the whatis information for the manual page, etc), a better pager for completions, etc.
I really think bash lacks a large number of useful features. But then again, I am biased, since I have written a shell my own shell. But before you say that bash is 'good enough', I think you shouuld read this article for a description of some of these features my shell has.
I agree with you. But seeing how bash has built in support for mathematical calculations, regular expressions and a host of other complex features, not all people do...
This is not a shell feature, but a feature of the widget library. I think KDE allows you to do something similar through dcop, but you don't use the filesystem. But I'm not really a KDE export, so I can't give you the complete rundown.
I think there are a lot of room for innovation in the CLI market. How about syntax highlighting? Or better integration with the GUI? A better completion mechanism? A visual shell, with a visual tree representation of the filesystem for quick directory selection?
A few of these ideas can bew found in fish, which you can read up on here.
Truth be told, Linux does a pretty lousy job of integrating the shell into the GUI as well. Shell programs should support the mouse, should respect theme color preferences and should use the X clipboard for copy and paste. There are many other ways in which the CLI could benefit from a closer integration with the GUI.
I have written a shell that uses the X clipboard for copy and paste, available here, but the other features are still missing. I hope to support using the mouse to select completions from the tab completion list in the future as well.
I've written a Unix shell that aims to have a lower learning curve than traditional shells. It does this by having a smaller and simpler syntax, and integrated help features.
There is an article about the shell here, and the shells homepage is here.
It is economically unsound to invest into a project that does not have a well defined budget, it will end up costing more than it has to, since no one will keep track of how well the money is spent. This is one of the major reasons why the private sector ends up doing things cheaper.
When I read the article, I thought they meant the opposite. Since I belive the bug was reintroduced because large parts of the old Netscape codebase was ripped out and replaced with shiny, new and unsecure code, this arguments seems to fall flat on it's face.
It is not impossible, Testing new releases against old bugs is called regression testing, and everybody pretends to do it. But the problem is that it is so boring and hard that very few people write working regression tests against the more complex bugs.
Saying the bug resurfaced is not completely true. This bug was removed from the old Netscape rendering engine, and reintroduced when replacing it with the new and fancy Gecko rendering engine. Apache also reintroduced a number of bugs when switching from 1.3 to 2.0, I belive. That is one of the many prices you pay when rewriting old code from scratch.
I think that only a very, very small percentage of all potential Apple users know or care about the KHTML issue. How many non-nerd articles have been written about KHTML and Safari?
We do not have the computing power or the bandwidth to simulate human thought. Not to mention the fact that we don't really understand how the neutrons of our brain connect and interact to form intelligent thought. The article is somewhat sensationalistic.
The future is looking pretty bright for space travel right now. Nasa is finally facing some competition again, both from the European space agancy, the russians and private enterprises. I think the cost of sending junk to space will decrease by an order of magnitude in the next decade.
I saw this story on OSnews today, but they made it out to be about the Hyperthreading issue. But that didn't make any sense since that is not ans OS bug at all, but a hardware issue. (If it is evan an issue)
Slashdot Mirror
*sigh*
Your argument is that since a feature might not be available in all situations, it is a bad idea to implement it at all. Along your line of reasoning, all GUIs are evil, since you sometimes only have terminal access. Hell, if I'm stranded on a tiny island in the middle of the ocean, I don't even have a computer, so any software is evil by your logic.
Of course, any feature that a shell implements should fail gracefully. In fish (my shell), if there is no X server connected, fish simply takes care of it's own copy and paste buffer. But it does not make sense to have one such buffer for each shell that is running.
30 years? MS-DOS is a little over 20 years old, but definitely not 30. And at it's time it was an ok shell. Not good, definitley not as good as the Unix shells of that time, but not horrible either.
Why should not a commandline interface use syntax highlighting to improve readibility and highlight errors? And yes bash does have programmable completions, but there are a lot of possible improvements, like descriptions of each completion (when completing a maunal page, show the whatis information for the manual page, etc), a better pager for completions, etc.
I really think bash lacks a large number of useful features. But then again, I am biased, since I have written a shell my own shell. But before you say that bash is 'good enough', I think you shouuld read this article for a description of some of these features my shell has.
Whell, Posix shell is a pretty bad language, for one thing. Read the second half of this article for my opinions on why Posix is bad.
I agree with you. But seeing how bash has built in support for mathematical calculations, regular expressions and a host of other complex features, not all people do...
Bash has something like 70 builtins.
This is not a shell feature, but a feature of the widget library. I think KDE allows you to do something similar through dcop, but you don't use the filesystem. But I'm not really a KDE export, so I can't give you the complete rundown.
I think there are a lot of room for innovation in the CLI market. How about syntax highlighting? Or better integration with the GUI? A better completion mechanism? A visual shell, with a visual tree representation of the filesystem for quick directory selection?
A few of these ideas can bew found in fish, which you can read up on here.
Truth be told, Linux does a pretty lousy job of integrating the shell into the GUI as well. Shell programs should support the mouse, should respect theme color preferences and should use the X clipboard for copy and paste. There are many other ways in which the CLI could benefit from a closer integration with the GUI.
I have written a shell that uses the X clipboard for copy and paste, available here, but the other features are still missing. I hope to support using the mouse to select completions from the tab completion list in the future as well.
I've written a Unix shell that aims to have a lower learning curve than traditional shells. It does this by having a smaller and simpler syntax, and integrated help features.
There is an article about the shell here, and the shells homepage is here.
It is economically unsound to invest into a project that does not have a well defined budget, it will end up costing more than it has to, since no one will keep track of how well the money is spent. This is one of the major reasons why the private sector ends up doing things cheaper.
Got any links to sites describing real, live firefox exploits and the problems they've caused?
When I read the article, I thought they meant the opposite. Since I belive the bug was reintroduced because large parts of the old Netscape codebase was ripped out and replaced with shiny, new and unsecure code, this arguments seems to fall flat on it's face.
It is not impossible, Testing new releases against old bugs is called regression testing, and everybody pretends to do it. But the problem is that it is so boring and hard that very few people write working regression tests against the more complex bugs.
Saying the bug resurfaced is not completely true. This bug was removed from the old Netscape rendering engine, and reintroduced when replacing it with the new and fancy Gecko rendering engine. Apache also reintroduced a number of bugs when switching from 1.3 to 2.0, I belive. That is one of the many prices you pay when rewriting old code from scratch.
Avoid using Windex on flat screens. It may damage the anti-glare coating. If possible, use only a damp cloth to wipe away any tape residue.
The number of Firefox vulnerabilities that have been exposed is frightening. But I wonder when the first actual exploit will be found...
I think that only a very, very small percentage of all potential Apple users know or care about the KHTML issue. How many non-nerd articles have been written about KHTML and Safari?
Simulating any biological process, including the fireing of neurons, is mostly floating point math.
We do not have the computing power or the bandwidth to simulate human thought. Not to mention the fact that we don't really understand how the neutrons of our brain connect and interact to form intelligent thought. The article is somewhat sensationalistic.
Debian? Ubuntu?
No nono... Intel are planning on putting the computer in the mouse.
The future is looking pretty bright for space travel right now. Nasa is finally facing some competition again, both from the European space agancy, the russians and private enterprises. I think the cost of sending junk to space will decrease by an order of magnitude in the next decade.
Thank you captain obvious
I saw this story on OSnews today, but they made it out to be about the Hyperthreading issue. But that didn't make any sense since that is not ans OS bug at all, but a hardware issue. (If it is evan an issue)
Yes, because if refactoring does change behaviour, you must have introduced a bug. And code should not contain bugs.