Unless you type like The Flash, even MLC SSDs from the better vendors (Intel) should be fine for anything outside of server applications. Simple math should back this up (how many GB total the drive can write over its lifetime vs how much you produce each day).
I don't know who this "The Flash" is... But this reminds me of some odd invoices I've seen here lately at Star Labs. Someone special-ordered a custom keyboard rated to one hundred times the usual keystroke impact, an 80MHz keyboard controller, and a built-in 1MiB keystroke buffer. Pretty ridiculous, huh? The usual 10ms polling rate for a USB keyboard should be enough for anybody - no need for all that fancy junk.
If you're not good enough at arithmetic to understand that this isn't an issue, should you really be developing software?
Maybe you can explain why it isn't an issue, then?
One thing about flash in general is that in order to rewrite a small amount of data, you need to (at the low level) erase and rewrite a relatively large amount of data. So depending on how extensively the filesystem is cached, where the files are located, etc., rebuilding a medium-sized project could wind up re-writing a large portion of the SSD...
To me, that model can only be made better by giving these tools a more powerful standard of communication...
there's some truth to that. but it's not clear how you can do that without increasing the complexity of the individual tools, and making them more aware of their environment.
Explain: what would make the tools more complex? What would make the tools more aware of their environment, and to what ill effect?
Take "find" for example. All it needs is a fool-proof way to tell a receiving process where one filename ends and another begins. If that were provided in a more consistent way across applications, one wouldn't need "-print0" or "xargs -0", you could just chain the one command to another without any special options. Simpler.
On the flip side, this means there's the logistical complexity of getting people to write their tools with one of the shell's preferred data formats in mind, and the technical complexity of making that happen. The latter is by far the less complicated issue, to my mind. Programs link in a library and most of the work is done for them. Just like we don't think about how the internal code for "printf" works, we wouldn't have to think about how the serialization layer works.
the tools model works as well as it does precisely because the individual tools are, well, dumb.
I think the tools model could work a lot better than it does. I believe people are solving problems in Perl or Python, etc., bypassing the whole suite of "small tools" precisely because these environments provide organizational structure that's missing from the shell.
(regarding the decision to make shell programs deal in plaintext, for the most part-) you don't have to think too hard about the design direction, or do much work to get people to use it - but it's not necessarily the best decision in terms of what you can do with it.
again, you're right in a significant way, but something else is missed. the point is that it's "easier" for every tool. it works best in an environment where you're going to have not a dozen but a hundred tools, written by different people. as the number of tools increases, the incremental cost of increased complexity requirements goes up by that multiple.
I don't totally agree with Matz's ideas about how programming languages should be designed exclusively with the programmer in mind - I feel there has to be a balance, between the needs of the user and what the machine can provide. As it applies to this case, I'd say the needs of the user to deal with every aspect of translation steps every time they do a pipeline command outweighs the more-or-less one-time cost of writing the tools.
...as a text format becomes more complex the problem of handling it (parsing, serializing, etc.) becomes more complex as well - and the advantages of it being a text format start to disappear.
i'm not entirely sure what you mean here
Ad-hoc text formats are very simple to deal with when you're working with simple data structures. When those data structures need to be able to accommodate the possibility of future change without breaking existing code, or when you start using them to represent more complex structures, the burden of dealing with that organization at the byte-by-byte level for every pipeline you run becomes unreasonable.
Also, as the complexity of the text-encoded data structure becomes more complex, the simplicity and clarity that make it advantageous to encode that data as text disappear - a raw byte-dump is no longer an effective way to view it.
i'm not sure what you mean by the shell providing automatic translation. if the tools follow the above rule (that each tool assumes its output is meant to
Python and Perl exist because some things are out of scope for a shell. What do you gain by giving a shell kitchen-sink functionality? Over complicated shell. Unix shell is successful because it is simple to understand and build command chains by checking the output before the next step.
Why should anything be out of scope for the shell? Why should the shell language not be capable of the same things we expect from Perl or Python? I think we have accepted these limitations because we are accustomed to them.
Being able to check the output while building a pipeline doesn't get you much: you still need to be able to write a parser to handle that input (which is easy for simple problems, but can get challenging) - and anywhere along the line there may appear in the data something you didn't account for, with the result that when you run your pipeline it does something you didn't want, or doesn't do something you did want. Besides which, that capability is nothing special - it exists in practically every interactive programming language ever made.
Imagine if the shell mandated just one bit of structure on the format of data going over the pipeline: how to know when one value ends and the next one begins. Just that one feature would simplify shell programming a lot.
It's not about "kitchen sink"ing the shell - the functionality in question is already a part of your system in the form of libraries and scripting language modules. It's just a matter of giving the shell a good way to use it.
PowerShell improves on the functionality offered by Unix shells in that it gives you a richer set of expressive fundamentals; the shell is smarter, knows more about the environment, and that lets it do more with what's around.
the problem is that this isn't simply an extension of the Unix shell; it's actually antithetical to it. the issue isn't the "shell" per se, but the "tools" model of environment and application building.
I'm confused here. By the "tools model of environment and application building" - do you mean the Unix tradition of "many small, simple, single-job utilities"?
To me, that model can only be made better by giving these tools a more powerful standard of communication - reducing the amount of translation steps that need to be introduced (manually, that is, by the user) into a pipeline. Deciding on standards for calling arguments, pipeline data format, etc. would make it easier to link "small, simple" tools together - the tools themselves would be simpler by virtue of greater consistency and the eliminated need for features that might have been added to simplify communicating with partners of unspecified data format.
the unix shells are all intentionally fairly ignorant of the environment: they rely on some basic conventions about how programs behave, but beyond that they just move bytes (typically text) around.
The thing about that kind of design decision is that it's easy - you don't have to think too hard about the design direction, or do much work to get people to use it - but it's not necessarily the best decision in terms of what you can do with it. It's not a design that scales well: as a text format becomes more complex the problem of handling it (parsing, serializing, etc.) becomes more complex as well - and the advantages of it being a text format start to disappear.
you can't "improve" the unix shell environment by making it have a more PowerShell-like vocabulary, because it's a vocabulary for things it simply has no knowledge of in the first place.
This is getting a bit abstract for me... You're saying the shell can't take advantage of vocabulary without knowledge of how to use it. I disagree.
For starters, there are some very generic ways a shell could take advantage of a little bit of knowledge about the structure of the data it's dealing with. Providing automatic translation to a related data type, for instance.
this is actually a really good thing within the unix- or tools-based environment. in this model, it's a lot easier to generate new bits of functionality without having to muck around with the existing stuff. adding new functionality to the environment doesn't involve changing your shell, just adding a new tool.
Why would a new bit of functionality require a new shell? What's the case where that would happen?
And what would it take, for instance, to add a field to "crontab" or "/etc/passwd"? Those formats are dead-simple and look nice printed byte-for-byte on a terminal or line printer but the tradeoff is that they're non-extensible formats. It's a lot easier for a data format to be extensible if you don't worry so much about making it look nice in ASCII view - and then you can make the format easy to work with in practice by providing tools (including the shell) that know how to view and edit it.
each tool is easy to digest and understand, and that ability to fully understand the building blocks is what leads to things getting put together in new, interesting, and unexpected ways.
A shell that can understand and process the data output of the commands it runs makes the tools easier to understand. A shell that establishes standard policies for a program to publish its valid command line switches makes the program easier to use. And a shell that reduces the amount of work the user has to do to translate the outpu
Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions.
But what if the assumptions are wrong?
You could as easily ask "what if Python's assumptions about the format of classes doesn't match the assumptions made in this compiled Python module?" It represents a failure to build the module properly for the environment in which it'll run.
In Powershell's case, a pipeline between two commandlets (Powershell-native programs) is a series of.NET objects. A pipeline in which both of the commands are non-commandlet programs would deal in text, like a Unix shell. A pipeline in which just one of the two is a commandlet - I'm not sure.
And does Powershell have assumptions about every file type? Does it grok TeX/LaTeX dvi files?
Powershell doesn't do any kind of object layer on top of regular files. Data files are treated pretty much analogously to how they'd be treated in Unix.
Also, Unix users don't want the shell to be one huge all-encompassing language.
Speak for yourself.
First off, the shell is "one huge all-encompassing language." It is a programming language, designed for interactive sessions, whose primary environment is the filesystem as a whole. In that role, I just want to make it more capable.
I am a Unix user, and I want my shell to be cleaner and more powerful than what "bash", etc. can provide. I want it to foster an environment in which programs can communicate better with one another. I want programs to be written in such a way that they can facilitate these changes. It's a lofty goal, for sure, but I think the kind of shell environment we'd achieve would be worth it.
There is no requirement for stream output to be ascii, that is up to the programmer to decide and preferable to having the architecture decision forced on you.
There's a big difference between having an architecture forced on you and having an architecture provided for you. Structure is beneficial. So why is the exact amount of structure provided by the Unix shell the right amount? Is it just tradition? Or fear of attempting to set a policy people might not like?
I think having a shell policy like "you can put whatever data format you like in your pipelines, but you have to at least agree to some standard rules about identifying what form you're using" would be a huge improvement in terms of what the shell could do with that data.
But I think you're missing the point that you can actually use Perl or Python as your shell, you have a semantic roadblock from working too closely with monolithic solutions.
Which monolithic solutions would those be, exactly? Please, do tell me all about myself.:D
Neither Perl or Python is, as a language, well suited to use as a command shell. They are languages with their own environment, in which system files and commands on the PATH are external entities, while in a command shell your environment is the filesystem.
Of course, one of these languages could be the starting point for such a shell, and the end result could provide capabilities similar to what Powershell has. The reason I don't favor something like that, however, is that I would want the shell-provided data interchange format (or formats) to be independent of any one scripting language. If the whole shell were just a Python program, and the data passed between "commandlets" just Python objects, that wouldn't get you anywhere in terms of improving the interaction between the shell and outside processes.
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
Thanks... So many people are concerned that the current way is the best - convincing them to change to something different will be tough. But a new system can't take hold unless people are willing to embrace it. That's why I argue the point every time the topic of shells comes up... I need to be better at advocating the kind of system I want to promote, recognize things I may have assumed in error, and know more about the kinds of techniques people use to work within the limits of the shell. It's practice.:) Plus maybe I'll convince a few people along the way.
The original point of perl is to address your concerns.
But it's not a shell, and frankly I don't want it to be my shell.
My point is that I see the fact that we needed a strong string processing language to help with shell pipelining as a flaw in the way pipelines are handled. I also see the fact that so much good functionality is exposed as Perl or Python modules, but not as shell utilities, as indicative of a severe limitation in what the shell is capable of as a programming language (overcoming this limitation goes beyond just adding a stronger set of data types to the shell language itself - the shell would also need to be able to use these datatypes as part of its pipelines.)
Something like Perl Shell overcomes one part of the problem - turning Perl into a shell, exposing all the Perl libraries in the process... The problem is that, while such a shell provides a richer programming environment, it doesn't do anything to extend that functionality to libraries or programs not written as Perl modules. You could think of it as a problem of adoption: if Perl Shell were the standard shell on Linux then people would write their programs to work nicely in it, and the result would be a strong shell environment. But since it's not, people don't, and so the solution only goes half-way.
so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.
Like a Unix user would be calling Perl or Python?
Not quite... The shell user can call Perl or Python to access libraries or datatypes - but these concepts are meaningless within the framework of the shell itself. In Powershell, a commandlet returning an object yields something you can work with in the shell - see what object methods or data fields it provides, run methods, pass the object to another commandlet, etc.
Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions. In Unix, the typical approach is to "roll your own format" each time - which is trivial for trivial problems, but substantially harder as you start worrying about questions like, what happens when my data fields contain the character I want to use as a delimiter?
This is further complicated by the fact that existing Unix programs, outputting text, typically format that text for human consumption. The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal. But since the shell itself also recognizes this format, it has a reasonable default behavior for displaying a command output - or if necessary you can pipe through a command whose job is to make nicely formatted output of selected columns of another program's result.
Now, what are the benefits of serializing to text format? You can look at it, printed on-screen, and know what it represents and how to parse it, right? The problem is this becomes less and less true as the data format becomes more intricate, more comprehensive - which is bound to happen as you start doing things like handling more complex problems, implementing data formats that account for future upgrades, and so on. The strength of PowerShell's approach (the same approach, basically, as you'd find in any other capable, interactive programming language) is that it knows enough about the format of data it handles that it can make that format easy to view and work with - easier, in fact, than plain text, because you see a representation of the data's meaning rather than of its underlying structure.
As another example, consider what it would take to provide any kind of higher-order programming in the shell. There's a limited degree of this available already, of course: if you want to pass a "function" to something, you form it into a shell script, put it in a directory somewhere, and provide the full pathname to that function as an argument to your higher-order program - which will then use something like "system()", "popen()" or "exec()" to invoke it.
Now, what if you want to include a set of data, representing the state of an "object" with that "function"? You can do that, too - you can write out a data file representing the current state, and pass both the script and the data file names to your higher-order program. Or you could have a program running in the background, communicating via some form of IPC - maybe over a named pipe or listening to a particular network socket or hosted by an object broker, and pass the necessary reference to the higher-order function. Or, about the nicest you can manage in the shell (though decidedly not a clean solution IMO) - start a process in the background which maintains the state you're working with, and have a second executable which communicates with the background process, passing on commands and bringing back results.
I remember when it was turned off. I thought they'd turned it back on after everybody started worrying about terrorists again - but I guess I was mistaken. At present, at least, they still have the option to turn it back on.
I know that before it was turned off there was a fair amount you could do to improve your GPS info by keeping a backlog of data, comparing it to data recorded at a known location, etc... They may have simply decided that SA was no longer effective.
Backticks? Why on earth would you use backticks to move files around? That's what File::Copy is for. And Archive::Tar handles tarballs.
Write Perl code, not shell scripts wrapped in Perl code.
All of this raises an issue that interests me, with regard to the shell and scripting languages...
The shell is supposed to be a convenient interface for accessing the functionality your system has to offer - but because of the way that functionality is offered it's hard to take advantage of it. The shell hasn't got much in the way of support for datatypes, namespaces, and so on. This makes it a lot easier (and, often, more efficient) to program in a scripting language like Perl or Python, and implement all kinds of useful functionality as libraries for that language, instead of as shell programs.
So scripting languages have the advantage of providing a much more structured and full-featured programming environment - a better foundation on which to build more complicated programs and more sophisticated tools. But the whole thing is one degree separated from the normal interaction with the shell - it's not trivial to expose all that functionality implemented for the scripting language to code outside the scripting language... The scripting language becomes a rich environment all its own, but that functionality isn't part of the shell environment, because the shell environment doesn't support the organizational concepts that make that code manageable within the framework of the scripting language.
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Meh, give Powershell some credit. It exposes a lot more functionality with a lot better organization than a Unix shell would. They took the basic paradigm of the shell and made it fit the.NET environment - so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types. I think it's significant, and I think the Unix world could learn a thing or two from it, about keeping what's good about the shell, but moving the basic technology out of the 1970s.
I think it just hit a bit too close to reality to be honest. They've done very similar things with animals, as a sibling post said(cockroaches). And in humans, similar things have been done for remote control: Remote-controlled humans.
And Spock's Brain - don't forget that!
That's why it's not actually that obvious that you were joking.
just so that those slashdotters who didn't RTFA(i.e. everyone except those who read it earlier today off BBC's news feed) don't get confused, the parent post is a lie.
It's a joke, dumbass. A failed joke, apparently, since nobody thought it was funny (that's fine, I can deal with the occasional joke failing outright...) - but I thought it was abundantly ridiculous that it would be clear that it was in no way connected with reality!
I just thought it was funny the headline was "Bionic Eye Gives Blind Man Sight" - and then it's like, actually, it lets him match socks and follow lines in the road. It just reminded me of those line-following robot kits.
What we've done here is mounted an IR emitter and a pair of IR receivers in his head. We then connected these to his motor center so that when he gets a strong return on the left receiver his body jerks him to the left - while when there's a strong return in the right sensor his body jerks him to the right. This has proven sufficient for him to follow lines painted in the road - though it seems to have been a bit counterproductive in terms of obstacle avoidance.
Agreed. Plus, GPS devices should be outlawed -- terrorists could use them to navigate in lieu of maps.
Have you heard of "Selective Availability"? You know, the thing where the precision of GPS data is intentionally downgraded to prevent people from doing anything nasty with it?
I'm just saying, they already thought of this. It's not much of a "hypothetical" point you raise - the US controls the GPS satellites, so there's no need to control GPS receivers.
The other point is it's not like they even seemed to try hard to prevent piracy. Their systems are some of the most easily hackable out there so if they don't even invest in anti-piracy measures like Sony and Microsoft do then why should they expect anyone to help them if they wont help themselves?
I think you're not familiar with the history of the Nintendo DS... Nintendo's ability to patch these systems is limited because the old ones (before the DSi) didn't have the ability to download firmware updates - and online play wasn't big enough when the system was launched to enable Nintendo to "strongly encourage" system updates, the way they (and Sony, etc.) do with their more recent systems...
But the first hacks to be able to run homebrew code worked by spoofing a DS game header, via an add-on device (and later, wi-fi), to launch code from the GBA slot instead of loading it from the DS card. And then, due to hardware limitation of how the GBA slot is memory-mapped on the DS, the bootloader code had to be crafted to avoid certain operations until the software was up and running. Admittedly, Nintendo could have protected themselves better against this with more aggressive use of cryptographic signing, etc. but what's done is done.
Anyway, they went through a few iterations of blocking specific measures like that - rejecting headers that had jump addresses in the GBA ROM region, and so on - but because they couldn't push updates to the system it was mostly limited to new hardware releases which would include the block.
Then somebody worked out how to do the whole thing via the DS card slot. (If you want to talk about Nintendo not trying hard, or how their system is super-easy to hack, think about how many years it was from the release of the DS until this was accomplished...) That made devices like the R4DS possible. Dealing with that was less straightforward, since these devices were much more similar to normal DS game cards than previous methods. They finally addressed that with the DSi - I think by specifically blacklisting the R4 and similar devices... The DSi has to remain backward-compatible, of course, which limits Nintendo's options somewhat, but since online stuff is a bigger part of the new system Nintendo can finally push firmware updates...
So I'd say they've been trying pretty hard. Bear in mind they also have to balance this effort against other concerns (for instance, making this all run within the limitations of economical hardware, etc.)...
I paid $129 for a Nintendo DS ONLY because of R4DS card. I totally agree with what Aliquis is saying. Without the said card, Nintendo wouldn't get a single penny from me and I wouldn't even think about getting the stupid system. Over the years I bought several DS's in various colors, and encouraged friends and family to get them as well, and I even bought some DS games for my friend as a gift. So, how was the R4DS card bad for their business?
The real money is in the software.
They create the hardware so they'll have a platform on which they (and others) can sell software. Nintendo gets a licensing fee from everybody who makes games for the system, and in exchange Nintendo provides a popular platform and does their best to impede piracy.
Now, all that said, I own an R4DS. I originally bought it so I could do dev and homebrew but I've also used it to play pirated games. It's great that the R4DS is so convenient, but it's kind of unfortunate that this also makes piracy so easy. I believe in my own right to do what I want with my own hardware but I also believe Nintendo is right to protect the technical means they've used to try to stop piracy. If end-users were more honest then the two interests wouldn't conflict...
It's true that not every pirated game equates to one lost sale. However, someone who got themselves a DS and an R4 and a memory card along with a couple hundred games might have instead spent the same money on a DS and two games. Even if the "lost sales" were bargain-closeouts or used games, that still represents a reduction in the overall demand for legitimately-purchased games, and thus a reduction in the value of the games.
And then on the flip side: the value of the R4 is greater because you can use it to easily play pirated games. The manufacturers and resellers of that device are profiting off of software piracy. That's not fair, really.
I think people put a lot of effort into rationalizing their own software piracy - but really it just comes down to self-gratification. Nothing is worth paying for if you're willing (and able, with low risk) to take it for free. If these people forced themselves to play by the rules, they might find that these games are worth paying for.
I know, but my actions don't result in lost sales since I don't even play the games when they are free, I would definitely not buy and play any games costing the amount of money they cost now.
That's easy for you to say now because you're playing what you want to play and not paying for it. Since you're getting what you want for free, you're assigning a corresponding value to the experience of playing the games. If you were actually forced to either pay up or stop playing - after a while you might start to think that dropping $20-$40 here and there for a game or two is worth it, after all.
Or it's possible that you'd just stop playing games... But I think the former scenario is more common.
I'm still at a loss to understand why FAT and ASCII still persist in modern society. I mean, I understand backwards compatibility and lack of support, and all that other bullshit that's the reason why we're still running substandard 32-bit bottlenecked systems, but if Apple can cut the cord, why can't the rest of the industry?
Last I checked my FAT32-formatted flash drives and memory cards still work on Macs. How has Apple "cut the cord"?
Slashdot Mirror
Current SSDs have a lifetime of somewhere around 10.000 years. I think that's enough.
10000 years or 100000 writes, whichever comes first. :D
Unless you type like The Flash, even MLC SSDs from the better vendors (Intel) should be fine for anything outside of server applications. Simple math should back this up (how many GB total the drive can write over its lifetime vs how much you produce each day).
I don't know who this "The Flash" is... But this reminds me of some odd invoices I've seen here lately at Star Labs. Someone special-ordered a custom keyboard rated to one hundred times the usual keystroke impact, an 80MHz keyboard controller, and a built-in 1MiB keystroke buffer. Pretty ridiculous, huh? The usual 10ms polling rate for a USB keyboard should be enough for anybody - no need for all that fancy junk.
If you're not good enough at arithmetic to understand that this isn't an issue, should you really be developing software?
Maybe you can explain why it isn't an issue, then?
One thing about flash in general is that in order to rewrite a small amount of data, you need to (at the low level) erase and rewrite a relatively large amount of data. So depending on how extensively the filesystem is cached, where the files are located, etc., rebuilding a medium-sized project could wind up re-writing a large portion of the SSD...
there's some truth to that. but it's not clear how you can do that without increasing the complexity of the individual tools, and making them more aware of their environment.
Explain: what would make the tools more complex?
What would make the tools more aware of their environment, and to what ill effect?
Take "find" for example. All it needs is a fool-proof way to tell a receiving process where one filename ends and another begins. If that were provided in a more consistent way across applications, one wouldn't need "-print0" or "xargs -0", you could just chain the one command to another without any special options. Simpler.
On the flip side, this means there's the logistical complexity of getting people to write their tools with one of the shell's preferred data formats in mind, and the technical complexity of making that happen. The latter is by far the less complicated issue, to my mind. Programs link in a library and most of the work is done for them. Just like we don't think about how the internal code for "printf" works, we wouldn't have to think about how the serialization layer works.
the tools model works as well as it does precisely because the individual tools are, well, dumb.
I think the tools model could work a lot better than it does. I believe people are solving problems in Perl or Python, etc., bypassing the whole suite of "small tools" precisely because these environments provide organizational structure that's missing from the shell.
again, you're right in a significant way, but something else is missed. the point is that it's "easier" for every tool. it works best in an environment where you're going to have not a dozen but a hundred tools, written by different people. as the number of tools increases, the incremental cost of increased complexity requirements goes up by that multiple.
I don't totally agree with Matz's ideas about how programming languages should be designed exclusively with the programmer in mind - I feel there has to be a balance, between the needs of the user and what the machine can provide. As it applies to this case, I'd say the needs of the user to deal with every aspect of translation steps every time they do a pipeline command outweighs the more-or-less one-time cost of writing the tools.
i'm not entirely sure what you mean here
Ad-hoc text formats are very simple to deal with when you're working with simple data structures. When those data structures need to be able to accommodate the possibility of future change without breaking existing code, or when you start using them to represent more complex structures, the burden of dealing with that organization at the byte-by-byte level for every pipeline you run becomes unreasonable.
Also, as the complexity of the text-encoded data structure becomes more complex, the simplicity and clarity that make it advantageous to encode that data as text disappear - a raw byte-dump is no longer an effective way to view it.
i'm not sure what you mean by the shell providing automatic translation. if the tools follow the above rule (that each tool assumes its output is meant to
Python and Perl exist because some things are out of scope for a shell. What do you gain by giving a shell kitchen-sink functionality? Over complicated shell. Unix shell is successful because it is simple to understand and build command chains by checking the output before the next step.
Why should anything be out of scope for the shell? Why should the shell language not be capable of the same things we expect from Perl or Python? I think we have accepted these limitations because we are accustomed to them.
Being able to check the output while building a pipeline doesn't get you much: you still need to be able to write a parser to handle that input (which is easy for simple problems, but can get challenging) - and anywhere along the line there may appear in the data something you didn't account for, with the result that when you run your pipeline it does something you didn't want, or doesn't do something you did want. Besides which, that capability is nothing special - it exists in practically every interactive programming language ever made.
Imagine if the shell mandated just one bit of structure on the format of data going over the pipeline: how to know when one value ends and the next one begins. Just that one feature would simplify shell programming a lot.
It's not about "kitchen sink"ing the shell - the functionality in question is already a part of your system in the form of libraries and scripting language modules. It's just a matter of giving the shell a good way to use it.
PowerShell improves on the functionality offered by Unix shells in that it gives you a richer set of expressive fundamentals; the shell is smarter, knows more about the environment, and that lets it do more with what's around.
the problem is that this isn't simply an extension of the Unix shell; it's actually antithetical to it. the issue isn't the "shell" per se, but the "tools" model of environment and application building.
I'm confused here. By the "tools model of environment and application building" - do you mean the Unix tradition of "many small, simple, single-job utilities"?
To me, that model can only be made better by giving these tools a more powerful standard of communication - reducing the amount of translation steps that need to be introduced (manually, that is, by the user) into a pipeline. Deciding on standards for calling arguments, pipeline data format, etc. would make it easier to link "small, simple" tools together - the tools themselves would be simpler by virtue of greater consistency and the eliminated need for features that might have been added to simplify communicating with partners of unspecified data format.
the unix shells are all intentionally fairly ignorant of the environment: they rely on some basic conventions about how programs behave, but beyond that they just move bytes (typically text) around.
The thing about that kind of design decision is that it's easy - you don't have to think too hard about the design direction, or do much work to get people to use it - but it's not necessarily the best decision in terms of what you can do with it. It's not a design that scales well: as a text format becomes more complex the problem of handling it (parsing, serializing, etc.) becomes more complex as well - and the advantages of it being a text format start to disappear.
you can't "improve" the unix shell environment by making it have a more PowerShell-like vocabulary, because it's a vocabulary for things it simply has no knowledge of in the first place.
This is getting a bit abstract for me... You're saying the shell can't take advantage of vocabulary without knowledge of how to use it. I disagree.
For starters, there are some very generic ways a shell could take advantage of a little bit of knowledge about the structure of the data it's dealing with. Providing automatic translation to a related data type, for instance.
this is actually a really good thing within the unix- or tools-based environment. in this model, it's a lot easier to generate new bits of functionality without having to muck around with the existing stuff. adding new functionality to the environment doesn't involve changing your shell, just adding a new tool.
Why would a new bit of functionality require a new shell? What's the case where that would happen?
And what would it take, for instance, to add a field to "crontab" or "/etc/passwd"? Those formats are dead-simple and look nice printed byte-for-byte on a terminal or line printer but the tradeoff is that they're non-extensible formats. It's a lot easier for a data format to be extensible if you don't worry so much about making it look nice in ASCII view - and then you can make the format easy to work with in practice by providing tools (including the shell) that know how to view and edit it.
each tool is easy to digest and understand, and that ability to fully understand the building blocks is what leads to things getting put together in new, interesting, and unexpected ways.
A shell that can understand and process the data output of the commands it runs makes the tools easier to understand. A shell that establishes standard policies for a program to publish its valid command line switches makes the program easier to use. And a shell that reduces the amount of work the user has to do to translate the outpu
Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions.
But what if the assumptions are wrong?
You could as easily ask "what if Python's assumptions about the format of classes doesn't match the assumptions made in this compiled Python module?" It represents a failure to build the module properly for the environment in which it'll run.
In Powershell's case, a pipeline between two commandlets (Powershell-native programs) is a series of .NET objects. A pipeline in which both of the commands are non-commandlet programs would deal in text, like a Unix shell. A pipeline in which just one of the two is a commandlet - I'm not sure.
And does Powershell have assumptions about every file type? Does it grok TeX/LaTeX dvi files?
Powershell doesn't do any kind of object layer on top of regular files. Data files are treated pretty much analogously to how they'd be treated in Unix.
Also, Unix users don't want the shell to be one huge all-encompassing language.
Speak for yourself.
First off, the shell is "one huge all-encompassing language." It is a programming language, designed for interactive sessions, whose primary environment is the filesystem as a whole. In that role, I just want to make it more capable.
I am a Unix user, and I want my shell to be cleaner and more powerful than what "bash", etc. can provide. I want it to foster an environment in which programs can communicate better with one another. I want programs to be written in such a way that they can facilitate these changes. It's a lofty goal, for sure, but I think the kind of shell environment we'd achieve would be worth it.
There is no requirement for stream output to be ascii, that is up to the programmer to decide and preferable to having the architecture decision forced on you.
There's a big difference between having an architecture forced on you and having an architecture provided for you. Structure is beneficial. So why is the exact amount of structure provided by the Unix shell the right amount? Is it just tradition? Or fear of attempting to set a policy people might not like?
I think having a shell policy like "you can put whatever data format you like in your pipelines, but you have to at least agree to some standard rules about identifying what form you're using" would be a huge improvement in terms of what the shell could do with that data.
But I think you're missing the point that you can actually use Perl or Python as your shell, you have a semantic roadblock from working too closely with monolithic solutions.
Which monolithic solutions would those be, exactly? Please, do tell me all about myself. :D
Neither Perl or Python is, as a language, well suited to use as a command shell. They are languages with their own environment, in which system files and commands on the PATH are external entities, while in a command shell your environment is the filesystem.
Of course, one of these languages could be the starting point for such a shell, and the end result could provide capabilities similar to what Powershell has. The reason I don't favor something like that, however, is that I would want the shell-provided data interchange format (or formats) to be independent of any one scripting language. If the whole shell were just a Python program, and the data passed between "commandlets" just Python objects, that wouldn't get you anywhere in terms of improving the interaction between the shell and outside processes.
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
Thanks... So many people are concerned that the current way is the best - convincing them to change to something different will be tough. But a new system can't take hold unless people are willing to embrace it. That's why I argue the point every time the topic of shells comes up... I need to be better at advocating the kind of system I want to promote, recognize things I may have assumed in error, and know more about the kinds of techniques people use to work within the limits of the shell. It's practice. :) Plus maybe I'll convince a few people along the way.
The original point of perl is to address your concerns.
But it's not a shell, and frankly I don't want it to be my shell.
My point is that I see the fact that we needed a strong string processing language to help with shell pipelining as a flaw in the way pipelines are handled. I also see the fact that so much good functionality is exposed as Perl or Python modules, but not as shell utilities, as indicative of a severe limitation in what the shell is capable of as a programming language (overcoming this limitation goes beyond just adding a stronger set of data types to the shell language itself - the shell would also need to be able to use these datatypes as part of its pipelines.)
Something like Perl Shell overcomes one part of the problem - turning Perl into a shell, exposing all the Perl libraries in the process... The problem is that, while such a shell provides a richer programming environment, it doesn't do anything to extend that functionality to libraries or programs not written as Perl modules. You could think of it as a problem of adoption: if Perl Shell were the standard shell on Linux then people would write their programs to work nicely in it, and the result would be a strong shell environment. But since it's not, people don't, and so the solution only goes half-way.
so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types.
Like a Unix user would be calling Perl or Python?
Not quite... The shell user can call Perl or Python to access libraries or datatypes - but these concepts are meaningless within the framework of the shell itself. In Powershell, a commandlet returning an object yields something you can work with in the shell - see what object methods or data fields it provides, run methods, pass the object to another commandlet, etc.
Powershell provides a powerful set of baseline assumptions for the format of data over the pipe - and so both the shell itself and commandlets running in the shell can take advantage of these assumptions. In Unix, the typical approach is to "roll your own format" each time - which is trivial for trivial problems, but substantially harder as you start worrying about questions like, what happens when my data fields contain the character I want to use as a delimiter?
This is further complicated by the fact that existing Unix programs, outputting text, typically format that text for human consumption. The exact format of a program's input or output may change from release to release with no coherent strategy for establishing any kind of compatibility. In comparison, in Powershell a piece of data passed from one process to another has a predictable underlying structure - it's formatted for consumption by another process rather than for display at the terminal. But since the shell itself also recognizes this format, it has a reasonable default behavior for displaying a command output - or if necessary you can pipe through a command whose job is to make nicely formatted output of selected columns of another program's result.
Now, what are the benefits of serializing to text format? You can look at it, printed on-screen, and know what it represents and how to parse it, right? The problem is this becomes less and less true as the data format becomes more intricate, more comprehensive - which is bound to happen as you start doing things like handling more complex problems, implementing data formats that account for future upgrades, and so on. The strength of PowerShell's approach (the same approach, basically, as you'd find in any other capable, interactive programming language) is that it knows enough about the format of data it handles that it can make that format easy to view and work with - easier, in fact, than plain text, because you see a representation of the data's meaning rather than of its underlying structure.
As another example, consider what it would take to provide any kind of higher-order programming in the shell. There's a limited degree of this available already, of course: if you want to pass a "function" to something, you form it into a shell script, put it in a directory somewhere, and provide the full pathname to that function as an argument to your higher-order program - which will then use something like "system()", "popen()" or "exec()" to invoke it.
Now, what if you want to include a set of data, representing the state of an "object" with that "function"? You can do that, too - you can write out a data file representing the current state, and pass both the script and the data file names to your higher-order program. Or you could have a program running in the background, communicating via some form of IPC - maybe over a named pipe or listening to a particular network socket or hosted by an object broker, and pass the necessary reference to the higher-order function. Or, about the nicest you can manage in the shell (though decidedly not a clean solution IMO) - start a process in the background which maintains the state you're working with, and have a second executable which communicates with the background process, passing on commands and bringing back results.
The problem is, none of those me
Which has been switched off since 2000 (apparently)...http://www.ngs.noaa.gov/FGCS/info/sans_SA/docs/statement.html
I remember when it was turned off. I thought they'd turned it back on after everybody started worrying about terrorists again - but I guess I was mistaken. At present, at least, they still have the option to turn it back on.
I know that before it was turned off there was a fair amount you could do to improve your GPS info by keeping a backlog of data, comparing it to data recorded at a known location, etc... They may have simply decided that SA was no longer effective.
Backticks? Why on earth would you use backticks to move files around? That's what File::Copy is for. And Archive::Tar handles tarballs.
Write Perl code, not shell scripts wrapped in Perl code.
All of this raises an issue that interests me, with regard to the shell and scripting languages...
The shell is supposed to be a convenient interface for accessing the functionality your system has to offer - but because of the way that functionality is offered it's hard to take advantage of it. The shell hasn't got much in the way of support for datatypes, namespaces, and so on. This makes it a lot easier (and, often, more efficient) to program in a scripting language like Perl or Python, and implement all kinds of useful functionality as libraries for that language, instead of as shell programs.
So scripting languages have the advantage of providing a much more structured and full-featured programming environment - a better foundation on which to build more complicated programs and more sophisticated tools. But the whole thing is one degree separated from the normal interaction with the shell - it's not trivial to expose all that functionality implemented for the scripting language to code outside the scripting language... The scripting language becomes a rich environment all its own, but that functionality isn't part of the shell environment, because the shell environment doesn't support the organizational concepts that make that code manageable within the framework of the scripting language.
I feel like this situation is a problem - I believe in what some people call "The Unix Way" - chaining together small tools to do bigger jobs, but the shell doesn't have the organizational constructs to make this work for complex problems - and as a result people are doing this great work on adding functionality to the system, but it's getting packaged up as scripting language modules since the shell can't handle it. It's something I'd really like to correct.
Welcome to 1975, Microsoft.
Meh, give Powershell some credit. It exposes a lot more functionality with a lot better organization than a Unix shell would. They took the basic paradigm of the shell and made it fit the .NET environment - so users can express themselves using the same basic style as they'd use in a Unix shell, but working with a more powerful set of libraries and data types. I think it's significant, and I think the Unix world could learn a thing or two from it, about keeping what's good about the shell, but moving the basic technology out of the 1970s.
The history of "Sh" started when the first kid was born, and it has continued to this day. Later forked versions include "Shh!" and "STFU".
:D
You know, I was gonna write a shell and give it a name with "sh" at the end, but maybe I should call it "STFU" instead. :D
I think it just hit a bit too close to reality to be honest. They've done very similar things with animals, as a sibling post said(cockroaches). And in humans, similar things have been done for remote control: Remote-controlled humans.
And Spock's Brain - don't forget that!
That's why it's not actually that obvious that you were joking.
From this press release this appears to have only 60 electrodes (and I assume only grayscale).
So they wired a PXL2000 to his head. Awesome!
Really, though, it is pretty cool.
just so that those slashdotters who didn't RTFA(i.e. everyone except those who read it earlier today off BBC's news feed) don't get confused, the parent post is a lie.
It's a joke, dumbass. A failed joke, apparently, since nobody thought it was funny (that's fine, I can deal with the occasional joke failing outright...) - but I thought it was abundantly ridiculous that it would be clear that it was in no way connected with reality!
I just thought it was funny the headline was "Bionic Eye Gives Blind Man Sight" - and then it's like, actually, it lets him match socks and follow lines in the road. It just reminded me of those line-following robot kits.
What we've done here is mounted an IR emitter and a pair of IR receivers in his head. We then connected these to his motor center so that when he gets a strong return on the left receiver his body jerks him to the left - while when there's a strong return in the right sensor his body jerks him to the right. This has proven sufficient for him to follow lines painted in the road - though it seems to have been a bit counterproductive in terms of obstacle avoidance.
Agreed. Plus, GPS devices should be outlawed -- terrorists could use them to navigate in lieu of maps.
Have you heard of "Selective Availability"? You know, the thing where the precision of GPS data is intentionally downgraded to prevent people from doing anything nasty with it?
I'm just saying, they already thought of this. It's not much of a "hypothetical" point you raise - the US controls the GPS satellites, so there's no need to control GPS receivers.
The other point is it's not like they even seemed to try hard to prevent piracy. Their systems are some of the most easily hackable out there so if they don't even invest in anti-piracy measures like Sony and Microsoft do then why should they expect anyone to help them if they wont help themselves?
I think you're not familiar with the history of the Nintendo DS... Nintendo's ability to patch these systems is limited because the old ones (before the DSi) didn't have the ability to download firmware updates - and online play wasn't big enough when the system was launched to enable Nintendo to "strongly encourage" system updates, the way they (and Sony, etc.) do with their more recent systems...
But the first hacks to be able to run homebrew code worked by spoofing a DS game header, via an add-on device (and later, wi-fi), to launch code from the GBA slot instead of loading it from the DS card. And then, due to hardware limitation of how the GBA slot is memory-mapped on the DS, the bootloader code had to be crafted to avoid certain operations until the software was up and running. Admittedly, Nintendo could have protected themselves better against this with more aggressive use of cryptographic signing, etc. but what's done is done.
Anyway, they went through a few iterations of blocking specific measures like that - rejecting headers that had jump addresses in the GBA ROM region, and so on - but because they couldn't push updates to the system it was mostly limited to new hardware releases which would include the block.
Then somebody worked out how to do the whole thing via the DS card slot. (If you want to talk about Nintendo not trying hard, or how their system is super-easy to hack, think about how many years it was from the release of the DS until this was accomplished...) That made devices like the R4DS possible. Dealing with that was less straightforward, since these devices were much more similar to normal DS game cards than previous methods. They finally addressed that with the DSi - I think by specifically blacklisting the R4 and similar devices... The DSi has to remain backward-compatible, of course, which limits Nintendo's options somewhat, but since online stuff is a bigger part of the new system Nintendo can finally push firmware updates...
So I'd say they've been trying pretty hard. Bear in mind they also have to balance this effort against other concerns (for instance, making this all run within the limitations of economical hardware, etc.)...
I paid $129 for a Nintendo DS ONLY because of R4DS card. I totally agree with what Aliquis is saying. Without the said card, Nintendo wouldn't get a single penny from me and I wouldn't even think about getting the stupid system. Over the years I bought several DS's in various colors, and encouraged friends and family to get them as well, and I even bought some DS games for my friend as a gift. So, how was the R4DS card bad for their business?
The real money is in the software.
They create the hardware so they'll have a platform on which they (and others) can sell software. Nintendo gets a licensing fee from everybody who makes games for the system, and in exchange Nintendo provides a popular platform and does their best to impede piracy.
Now, all that said, I own an R4DS. I originally bought it so I could do dev and homebrew but I've also used it to play pirated games. It's great that the R4DS is so convenient, but it's kind of unfortunate that this also makes piracy so easy. I believe in my own right to do what I want with my own hardware but I also believe Nintendo is right to protect the technical means they've used to try to stop piracy. If end-users were more honest then the two interests wouldn't conflict...
It's true that not every pirated game equates to one lost sale. However, someone who got themselves a DS and an R4 and a memory card along with a couple hundred games might have instead spent the same money on a DS and two games. Even if the "lost sales" were bargain-closeouts or used games, that still represents a reduction in the overall demand for legitimately-purchased games, and thus a reduction in the value of the games.
And then on the flip side: the value of the R4 is greater because you can use it to easily play pirated games. The manufacturers and resellers of that device are profiting off of software piracy. That's not fair, really.
I think people put a lot of effort into rationalizing their own software piracy - but really it just comes down to self-gratification. Nothing is worth paying for if you're willing (and able, with low risk) to take it for free. If these people forced themselves to play by the rules, they might find that these games are worth paying for.
I know, but my actions don't result in lost sales since I don't even play the games when they are free, I would definitely not buy and play any games costing the amount of money they cost now.
That's easy for you to say now because you're playing what you want to play and not paying for it. Since you're getting what you want for free, you're assigning a corresponding value to the experience of playing the games. If you were actually forced to either pay up or stop playing - after a while you might start to think that dropping $20-$40 here and there for a game or two is worth it, after all.
Or it's possible that you'd just stop playing games... But I think the former scenario is more common.
There still seems to be a serious lack of Blackberry love from Android.
Android hasn't gotten its emotion chip yet.
Now, why it would need an old CPU from a Playstation 2 to understand love is beyond me, but I guess that's just how it works...
I'm still at a loss to understand why FAT and ASCII still persist in modern society. I mean, I understand backwards compatibility and lack of support, and all that other bullshit that's the reason why we're still running substandard 32-bit bottlenecked systems, but if Apple can cut the cord, why can't the rest of the industry?
Last I checked my FAT32-formatted flash drives and memory cards still work on Macs. How has Apple "cut the cord"?