Star Wars had a lot of fantasy elements like magic, knights, trolls, princesses, etc, and had a lot less scientific jargon than something like Star Trek. I would still consider Star Wars a blend of sci fi and fantasy, but definitely more in the future fantasy camp.
No matter how advanced a civilization is, their space fighter's engines won't make noise in vacuum nor will move like an atmospheric plane.
You know, very few sci-fi TV shows get this right. Firefly did. Stargate SG-1 occasionally tried (they didn't have that many space battles, but although I remember a few times when they tried to get it right, they often didn't). Babylon 5 made a deliberate choice to have sounds for dramatic effect, but they were VERY good at paying attention to physics otherwise.
Seems like that only ever applied to the Earth craft - and then only for the first couple seasons. Even at the beginning where they had that battle with the raiders, showing off the inertial flight of the Starfuries - the Raiders weren't following the same physical laws, they were zooming around like they were in an atmosphere.
Eh, no sweat - I was snippy in return so we are thus karmically balanced.:D
I suppose a good first step to the whole tab-completion thing would be to get a distro to run with the idea, using the bash tab completion system as a base. That would mostly just be a problem of establishing and implementing policy, as opposed to a technical problem of implementation. (Actually I wouldn't be too surprised if there are distros out there that do this - though on the other hand the GUI is more emphasized these days than the shell, so possibly not) The author of the "fish" shell observed that, while it's nice that various shells support the use of this kind of tab-completion information, the support is useless if it's not turned on, and it's off by default...
From there, even if the information wasn't stored in a way that's optimal for other shells, still the information would at least be there, and package maintainers for other shells would be able to access it...
I tend to approach a lot of these things with the perspective of "If I were starting over from scratch, how would I do it?" It's a nice way to look at things when your goal is to make something new - but it's not always a practical way to look at solving a problem and getting people to embrace the solution. Sometimes it's important to make good use of what you already have before trying to make something new that's better...
I am designing a shell that nobody will use because I don't understand enough of shell design not to hardcode version-specific arguments of unrelated executables into it.
FYP.
Hi, congratulations on your first post here on Slashdot! And, man, what a burn! You really got me there... Except you really ought to read what I post before you try to "fix" it.
I do have to say, though, you may be entirely correct that nobody will use the shell I'm designing. The way I figure it, the people who still want to use a command-shell are mostly die-hards who don't want to see it change - and I want to change it in ways that go beyond new mechanisms for supporting tab-completion... So I know what I'm getting into. My project may never go anywhere beyond my own systems.
But as I was saying, you misunderstood the feature we're discussing. The problem with the current approach to shell tab-completion (of programs' command-line arguments) is that these programs (neither the binaries themselves nor the distro packages in which they're provided) don't publish information about their own command-line arguments in a way that an automated tool, like a shell, can extract that data. So the information is usually maintained in a separate database - like the "bash-completion" package - not part of the shell package, not part of the tool's package, but something separate which must be kept in sync with the packages one has installed.
The feature we're discussing is a way for the tool itself to publish information, to the shell, about what kinds of command-line options it uses. There's all kinds of ways this could be done... For instance, the existing bash-completion mechanism could be used - but packaged differently so that each time you install a package containing a tool, it would add the necessary "complete" invocations to a startup script run when bash is invoked. This sort of approach is possible without any revolutionary changes to the shell - all you need is the right infrastructure and policies as part of your Linux distribution to make each individual package responsible for maintaining its own "bash completion" entries.
Now, what we grown-ups were discussing when you stuck your nose in was another method by which these "unrelated executables" could themselves publish information about the arguments they accept - by encoding that information into the structure of the executable ELF file or via another metadata mechanism. The shell, then, when confronted by "tar ^I", would go find "tar" on the path and see if it provides any information about the arguments it accepts. Maybe the shell would pull some data out of a field in the ELF file, or from an xattr attached to the binary, or from another file with a related name - you know, whatever works... In a proper programming language this sort of feature would be called "reflection" - the ability of calling code (in this case, the shell) to get some information about the module it's calling (in this case, tar or any other program run from within the shell) programmatically.
The key idea here is to decentralize the management of these completion lists. Tab-completion information for "tar" should be provided by "tar", not by "bash-completion", not by "fish" - it should either be either a part of the "tar" binary, a part of the "tar" package, or part of a package recommended by the "tar" package. And whoever maintains the "tar" package should maintain the tab-completion data as well, to keep it in sync with new versions.
Both VLC and mplayer are so insanely good, so much better than any alternatives, that it's kind of like arguing about whether you should drink belgian beer or german beer compared to drinking raw sewage.
I suppose - but one thing I've found with VLC is that it's quite a bit slower than mplayer. Some of my less-powerful hardware can handle H.264-encoded files a lot better in mplayer than in vlc.
No matter what shell you're using, someone has to write the tab completion scripts. Maybe it's easier done in ZSH, I don't know... but ZSH alone doesn't do magic.
Which is a shame... someone should look over the completion scripts that are out there, figure out what sorts of things they need to do, and standardize a way of storing that sort of completion information in a section of the binary itself. That way the shell could just read an ELF section of whatever program it's going to run instead of having to write completion scripts for each program out there.
You could even imagine designing a program that would display a GUI representation of the command line options for a program by reading this information automatically.
I am designing a shell and this is a feature I want to include... I like the tab-completion feature Bash, etc. can offer on command arguments, but the feature has to be organized in such a way that the programs themselves will supply the completion data...
OK, this one is a point I bring up from time to time, because it's something I want to address. I feel like Linux has outgrown the Unix shell. This is a bit tricky because the people who like the shell generally like it how it is - and for the most part, those who don't just go with a GUI instead. So I honestly don't know if a redesigned shell could seriously catch on. But personally I want a shell that's designed along the same basic lines as the traditional Unix shells, but is better suited to acting as an interface to the software running on my computer.
One of the most basic problems is that the shell has no notion of any data types when it comes to communicating with other programs. This is a tough problem because the shell can't have any notion of abstraction layers over the data exchanges unless the programs in question play along - at least to the extent of telling the shell what type of data they will emit or consume. But it's a problem that contributes to every limitation of the shell, as every moderately complicated problem of linking "small tools" together to do a bigger job turns into a parsing/serialization problem to translate one ad-hoc format to another.
Lack of support for objects is another limitation, though less severe. "Object Oriented" is a buzzword which sometimes adds no value to a program - but it also represents some real functionality which could be an asset to the shell. Being able to deal with a piece of data as an "object" means that some of the key operations which would be performed on that data can be performed with the specific context of that data in mind. Being able to deal with a running process as an "object" means that you can start the process and issue commands to it as it runs. It is possible to design a program which, once invocated, forks a copy of itself, and successive invocations issue instructions to this copy running in the background - but even then there is no means for the shell to track a reference to that "object" (for instance, in an environment variable) and provide notification when the reference is no longer needed - due to the various limitations and complications few utilities are written to operate in this way.
What I want is for the shell to have a good method for accessing the wealth of libraries available in Perl or Python - I want to have access to wi-fi maangement in the shell that equals what I get in the GUI - and I want the two interfaces to cooperate. Instead of all this new functionality being built up in ways that does an end-run around the shell (which ought to be the core of the whole OS interface) I want it to be integrated and accessible.
Being serious for a moment, a large part of the problem with Linux - at least in the "getting more people to adopt it" sense (chicken and egg) - is the fact that Linux developers/proponents tend to be unable to understand that while something is "not their fault", it is still their problem.
Here's the thing about that:
Personally, to some extent, yeah, I'd like it if Linux just plain worked with every new hardware device that comes along, and so on. However, that's not my goal.
My goal, when it comes to Linux, is to make the system more powerful, more interesting, and more fun for my own use. I'm content to keep my choice of OS in mind when I buy hardware, and I'm content to stick to my choice even if that means sub-optimal performance in some cases.
If you bought some hardware that doesn't work with Linux - that's too bad but there may be nothing I can do about that. The hardware vendor controls the hardware, and if they won't release the specs, then no matter whose "problem" you think that is, there's nothing anybody but the hardware manufacturer can do about it.
I mean, I can sympathize with problems you might face in trying to use Linux. And I'm willing to help you with them. But your problems are not my problems. The fact that I like Linux and want to contribute to its development does not lay that responsibility on me.
Back in the 90s I read the Linux Advocacy FAQ - back then I was in college and very enthusiastic about Linux, and very anti-Microsoft. The Advocacy FAQ was a good read - above all it urged the reader to be realistic about the limitations of Linux when advocating it. Very good advice.
Contributing to Free Soft is also a social thing
on
Linux Needs Critics
·
· Score: 1
Yeah, this is an important point. Contributing to free software isn't just a technical thing - it's an interpersonal thing, too. To contribute to an existing free software project, you have to convince the project managers to adopt the change. Creating a new project or a fork is not much good unless you get people to use it, and distributions to include it - otherwise that effort is wasted. And unless you intend to support that project forever, the project dead-ends when you leave it, unless you form a team of people who will take up the slack if you take a break.
Communication, leadership, and effective collaboration are all very important if you want to create change in the free software world.
On the positive side, there are more Linux critics than Mac critics.
If you are critical of Linux, you are just berated.
If you are critical of Mac, you are mobbed, beaten, lynched and never allowed to buy a cappuccino again.
Well, their enforcement squads aren't too far-reaching on that last point. For instance, McDonalds McCafe, for some reason they don't stop infidels from buying those.
...Linux is above criticism. What we actually need is a: "-1, Microsoft fanboy" mod... or how about "-1, Dissing Linux"... or even better "-1, Heresy"...
Don't be silly. Why would we need any of these things? When someone posts such a heretical message, the Group-Think Hive Mind simply recognizes that fact and routes their traffic elsewhere. No further action need be taken against these infidels.
Well, you know, apart from assassination by our crack team of brain-washed ninja assassins. But that's pretty much standard.
Anyone who passively-aggressively manipulates the moderation system should be modded down - even if in someone's imagination that "proves" some kind of point or makes the mods look bad.
'bringing the (ahem) "skills" of a literature graduate to the world of Linux has been interesting.'
See, he's being hip here, showing how he's integrated himself into hacker culture. "Skills" is hacker slang used to refer to one's learned abilities...
Yeah, by a whole third of the ENTIRE 4 digit club.
I prefer to think of it as "3% of the entire 5 digit club". Doesn't make a lot of sense to talk about how far off I was from the 5 digit club in terms of the size of the 4 digit club...
Though, yeah, 3000 is still pretty far. The joke would have been funnier if I'd been UID #100002 or something. But, you know, any excuse to roll out a classic Max Smart line...
The second edition of "Mastering Cat" will include in-depth coverage of the use of "cat" in the new generation of object-oriented Unix shells. Key topics will include:
"cat" type safety
Using "cat" in traditional mode vs. object-oriented
"cat" pitfalls: attempting to run "cat" on non-serializable live objects, "cat" on lists vs. "cat" on text files, using "cat" to capture user input (and dealing with the untyped data stream that results...)
You think I'm joking? Watch me. Hopefully what I come up with won't be quite the nightmare I'm trying to describe above.:D
...Schroeder's cat. If it works, you don't know it, but if it doesn't you have to try again until you get it to work (if you can tell that it worked anyway). Then the pipe comes out to stop my mind frying.
That's "Schrodinger's cat". Your license to make quantum mechanics jokes is hereby revoked. To make sure you don't try to take your license back, we're going to keep you updated on its current velocity.
Slashdot Mirror
It's an engineering term for a remote controlled robotic arm, derived from a Heinlein story.
http://en.wikipedia.org/wiki/Waldo_(device)
Didn't Optimus Prime have one of those?
Star Wars had a lot of fantasy elements like magic, knights, trolls, princesses, etc, and had a lot less scientific jargon than something like Star Trek. I would still consider Star Wars a blend of sci fi and fantasy, but definitely more in the future fantasy camp.
But it takes place "A long time ago"...
Turn in... your card...
No matter how advanced a civilization is, their space fighter's engines won't make noise in vacuum nor will move like an atmospheric plane.
You know, very few sci-fi TV shows get this right. Firefly did. Stargate SG-1 occasionally tried (they didn't have that many space battles, but although I remember a few times when they tried to get it right, they often didn't). Babylon 5 made a deliberate choice to have sounds for dramatic effect, but they were VERY good at paying attention to physics otherwise.
Seems like that only ever applied to the Earth craft - and then only for the first couple seasons. Even at the beginning where they had that battle with the raiders, showing off the inertial flight of the Starfuries - the Raiders weren't following the same physical laws, they were zooming around like they were in an atmosphere.
Eh, no sweat - I was snippy in return so we are thus karmically balanced. :D
I suppose a good first step to the whole tab-completion thing would be to get a distro to run with the idea, using the bash tab completion system as a base. That would mostly just be a problem of establishing and implementing policy, as opposed to a technical problem of implementation. (Actually I wouldn't be too surprised if there are distros out there that do this - though on the other hand the GUI is more emphasized these days than the shell, so possibly not) The author of the "fish" shell observed that, while it's nice that various shells support the use of this kind of tab-completion information, the support is useless if it's not turned on, and it's off by default...
From there, even if the information wasn't stored in a way that's optimal for other shells, still the information would at least be there, and package maintainers for other shells would be able to access it...
I tend to approach a lot of these things with the perspective of "If I were starting over from scratch, how would I do it?" It's a nice way to look at things when your goal is to make something new - but it's not always a practical way to look at solving a problem and getting people to embrace the solution. Sometimes it's important to make good use of what you already have before trying to make something new that's better...
FYP.
Hi, congratulations on your first post here on Slashdot! And, man, what a burn! You really got me there... Except you really ought to read what I post before you try to "fix" it.
I do have to say, though, you may be entirely correct that nobody will use the shell I'm designing. The way I figure it, the people who still want to use a command-shell are mostly die-hards who don't want to see it change - and I want to change it in ways that go beyond new mechanisms for supporting tab-completion... So I know what I'm getting into. My project may never go anywhere beyond my own systems.
But as I was saying, you misunderstood the feature we're discussing. The problem with the current approach to shell tab-completion (of programs' command-line arguments) is that these programs (neither the binaries themselves nor the distro packages in which they're provided) don't publish information about their own command-line arguments in a way that an automated tool, like a shell, can extract that data. So the information is usually maintained in a separate database - like the "bash-completion" package - not part of the shell package, not part of the tool's package, but something separate which must be kept in sync with the packages one has installed.
The feature we're discussing is a way for the tool itself to publish information, to the shell, about what kinds of command-line options it uses. There's all kinds of ways this could be done... For instance, the existing bash-completion mechanism could be used - but packaged differently so that each time you install a package containing a tool, it would add the necessary "complete" invocations to a startup script run when bash is invoked. This sort of approach is possible without any revolutionary changes to the shell - all you need is the right infrastructure and policies as part of your Linux distribution to make each individual package responsible for maintaining its own "bash completion" entries.
Now, what we grown-ups were discussing when you stuck your nose in was another method by which these "unrelated executables" could themselves publish information about the arguments they accept - by encoding that information into the structure of the executable ELF file or via another metadata mechanism. The shell, then, when confronted by "tar ^I", would go find "tar" on the path and see if it provides any information about the arguments it accepts. Maybe the shell would pull some data out of a field in the ELF file, or from an xattr attached to the binary, or from another file with a related name - you know, whatever works... In a proper programming language this sort of feature would be called "reflection" - the ability of calling code (in this case, the shell) to get some information about the module it's calling (in this case, tar or any other program run from within the shell) programmatically.
The key idea here is to decentralize the management of these completion lists. Tab-completion information for "tar" should be provided by "tar", not by "bash-completion", not by "fish" - it should either be either a part of the "tar" binary, a part of the "tar" package, or part of a package recommended by the "tar" package. And whoever maintains the "tar" package should maintain the tab-completion data as well, to keep it in sync with new versions.
I'm sort of surprised at the arguments.
Both VLC and mplayer are so insanely good, so much better than any alternatives, that it's kind of like arguing about whether you should drink belgian beer or german beer compared to drinking raw sewage.
I suppose - but one thing I've found with VLC is that it's quite a bit slower than mplayer. Some of my less-powerful hardware can handle H.264-encoded files a lot better in mplayer than in vlc.
[offtopic]
No matter what shell you're using, someone has to write the tab completion scripts. Maybe it's easier done in ZSH, I don't know... but ZSH alone doesn't do magic.
Which is a shame... someone should look over the completion scripts that are out there, figure out what sorts of things they need to do, and standardize a way of storing that sort of completion information in a section of the binary itself. That way the shell could just read an ELF section of whatever program it's going to run instead of having to write completion scripts for each program out there.
You could even imagine designing a program that would display a GUI representation of the command line options for a program by reading this information automatically.
I am designing a shell and this is a feature I want to include... I like the tab-completion feature Bash, etc. can offer on command arguments, but the feature has to be organized in such a way that the programs themselves will supply the completion data...
You'll probably be eaten by a grue.
Defy this cruel fate! "Frotz" a Grue today!
OK, this one is a point I bring up from time to time, because it's something I want to address. I feel like Linux has outgrown the Unix shell. This is a bit tricky because the people who like the shell generally like it how it is - and for the most part, those who don't just go with a GUI instead. So I honestly don't know if a redesigned shell could seriously catch on. But personally I want a shell that's designed along the same basic lines as the traditional Unix shells, but is better suited to acting as an interface to the software running on my computer.
One of the most basic problems is that the shell has no notion of any data types when it comes to communicating with other programs. This is a tough problem because the shell can't have any notion of abstraction layers over the data exchanges unless the programs in question play along - at least to the extent of telling the shell what type of data they will emit or consume. But it's a problem that contributes to every limitation of the shell, as every moderately complicated problem of linking "small tools" together to do a bigger job turns into a parsing/serialization problem to translate one ad-hoc format to another.
Lack of support for objects is another limitation, though less severe. "Object Oriented" is a buzzword which sometimes adds no value to a program - but it also represents some real functionality which could be an asset to the shell. Being able to deal with a piece of data as an "object" means that some of the key operations which would be performed on that data can be performed with the specific context of that data in mind. Being able to deal with a running process as an "object" means that you can start the process and issue commands to it as it runs. It is possible to design a program which, once invocated, forks a copy of itself, and successive invocations issue instructions to this copy running in the background - but even then there is no means for the shell to track a reference to that "object" (for instance, in an environment variable) and provide notification when the reference is no longer needed - due to the various limitations and complications few utilities are written to operate in this way.
What I want is for the shell to have a good method for accessing the wealth of libraries available in Perl or Python - I want to have access to wi-fi maangement in the shell that equals what I get in the GUI - and I want the two interfaces to cooperate. Instead of all this new functionality being built up in ways that does an end-run around the shell (which ought to be the core of the whole OS interface) I want it to be integrated and accessible.
Uh oh. Did I just criticise linux?
GET HIM!
Being serious for a moment, a large part of the problem with Linux - at least in the "getting more people to adopt it" sense (chicken and egg) - is the fact that Linux developers/proponents tend to be unable to understand that while something is "not their fault", it is still their problem.
Here's the thing about that:
Personally, to some extent, yeah, I'd like it if Linux just plain worked with every new hardware device that comes along, and so on. However, that's not my goal.
My goal, when it comes to Linux, is to make the system more powerful, more interesting, and more fun for my own use. I'm content to keep my choice of OS in mind when I buy hardware, and I'm content to stick to my choice even if that means sub-optimal performance in some cases.
If you bought some hardware that doesn't work with Linux - that's too bad but there may be nothing I can do about that. The hardware vendor controls the hardware, and if they won't release the specs, then no matter whose "problem" you think that is, there's nothing anybody but the hardware manufacturer can do about it.
I mean, I can sympathize with problems you might face in trying to use Linux. And I'm willing to help you with them. But your problems are not my problems. The fact that I like Linux and want to contribute to its development does not lay that responsibility on me.
Back in the 90s I read the Linux Advocacy FAQ - back then I was in college and very enthusiastic about Linux, and very anti-Microsoft. The Advocacy FAQ was a good read - above all it urged the reader to be realistic about the limitations of Linux when advocating it. Very good advice.
Yeah, this is an important point. Contributing to free software isn't just a technical thing - it's an interpersonal thing, too. To contribute to an existing free software project, you have to convince the project managers to adopt the change. Creating a new project or a fork is not much good unless you get people to use it, and distributions to include it - otherwise that effort is wasted. And unless you intend to support that project forever, the project dead-ends when you leave it, unless you form a team of people who will take up the slack if you take a break.
Communication, leadership, and effective collaboration are all very important if you want to create change in the free software world.
On the positive side, there are more Linux critics than Mac critics.
If you are critical of Linux, you are just berated.
If you are critical of Mac, you are mobbed, beaten, lynched and never allowed to buy a cappuccino again.
Well, their enforcement squads aren't too far-reaching on that last point. For instance, McDonalds McCafe, for some reason they don't stop infidels from buying those.
...Linux is above criticism. What we actually need is a: "-1, Microsoft fanboy" mod... or how about "-1, Dissing Linux"... or even better "-1, Heresy"...
Don't be silly. Why would we need any of these things? When someone posts such a heretical message, the Group-Think Hive Mind simply recognizes that fact and routes their traffic elsewhere. No further action need be taken against these infidels.
Well, you know, apart from assassination by our crack team of brain-washed ninja assassins. But that's pretty much standard.
To prove my point, I will be modded down.
Anyone who passively-aggressively manipulates the moderation system should be modded down - even if in someone's imagination that "proves" some kind of point or makes the mods look bad.
'bringing the (ahem) "skills" of a literature graduate to the world of Linux has been interesting.'
See, he's being hip here, showing how he's integrated himself into hacker culture. "Skills" is hacker slang used to refer to one's learned abilities...
"The new CloudLeft Public License (CPL) is based on the ideas that data wants to be Free(TM) and all your Cloud(TM) are belong to us."
Sorry, this is where I stop reading this one. Author has exceeded his lameness allowance.
...or Sitar Hero ...or Bagpipe Hero ...or...http://gadgets.boingboing.net/gimages/bandheros.jpg
True. But IIRC Accordion Hero was actually a joke that originated at Harmonix.
Sitar Hero was definitely one of the more clever ones IMO...
That's "Schrodinger's cat". Your license to make quantum mechanics jokes is hereby revoked.
That's Schrödinger's cat. Your licence to use Latin characters outside the 7-bit ASCII range is hereby revoked.
Well, I don't have a license to use Latin characters outside the 7-bit ASCII range - which accounts for why I didn't. :D
But, still, touche. (D'oh! I did it again!)
Missed it by that much...
Yeah, by a whole third of the ENTIRE 4 digit club.
I prefer to think of it as "3% of the entire 5 digit club". Doesn't make a lot of sense to talk about how far off I was from the 5 digit club in terms of the size of the 4 digit club...
Though, yeah, 3000 is still pretty far. The joke would have been funnier if I'd been UID #100002 or something. But, you know, any excuse to roll out a classic Max Smart line...
fp?
Achievement Unlocked: First Post Failure
Could be Accordion Master.
Or "Accordion Hero"?
That's a joke that dates back to the early days of Guitar Hero...
The second edition of "Mastering Cat" will include in-depth coverage of the use of "cat" in the new generation of object-oriented Unix shells. Key topics will include:
You think I'm joking? Watch me. Hopefully what I come up with won't be quite the nightmare I'm trying to describe above. :D
...Schroeder's cat. If it works, you don't know it, but if it doesn't you have to try again until you get it to work (if you can tell that it worked anyway). Then the pipe comes out to stop my mind frying.
That's "Schrodinger's cat". Your license to make quantum mechanics jokes is hereby revoked. To make sure you don't try to take your license back, we're going to keep you updated on its current velocity.