More digital effects does generally mean more scenes involving anonymous hordes. The problem I had with the third movie, and more with the second movie as originally editted, was that it had a substantial portion devoted to battles, which don't really have interesting character interaction.
I think Peter Jackson's mistake was in not cutting any of the battles for the theatrical releases. I found the second one tedious in the theater once Helm's Deep started, but it didn't feel as long, ironically, in the extended version. I think the fact that he kept effects and cut live action worsened the movies, but that, if he had kept them in balance, the effects would have been as important as he claims.
On the other hand, Smeagol was great, despite being a digital effect, and must have contributed significantly to the effect count in the last two movies. So not all digital effects are lacking in depth.
I think the right way to install debian is to tell the installer you don't want anything at all that's not absolutely required, and then install what you want with apt-get.
oggenc supports encoding from raw PCM with an arbitrary number of channels. Of course, you may have to interleave the data yourself, and I have no idea what players will do with the extra channels.
Actually, this doesn't work for anything other than key distribution anyway, because half of your bits will be lost due to guessing the mode wrong (let alone noise, interference, etc). If you were actually trying to send a message, you would have to contend with a whole lot of errors. However, it's possible to determine after the fact exactly which bits were lost due to quantum, so the ends can determine the secret that they share, even though it's impossible to say when you're picking the bits which ones will get through.
The important thing about this scheme is that, after the transfer, the ends can determine where the deletions (bits that got randomized) were, but they can't determine this until after the bits have been transferred. If the receiver could find errors without assistance (due to use of error correction), then the scheme would not have any security, because an active adversary could repair the message to cover the intrusion. Of course, without error correction, transferring your data isn't going to work.
Of course, you have to verify that you actually agree on the key by sending random bits from it to check. Otherwise, an attacker could have intercepted the whole thing and sent on junk, such that the attacker has half the key and the receiver has random data, and the attacker will get half the message and the receiver will get nothing.
There's definitely a market for having separate channels for the lead vocals and the rest of the music, particularly when they get around to having Ogg support for synchronized text.
The really interesting advance would be to be able to reduce the amount of modelling that the designers have to do. If they could just make a single model of each character, and have the system apply facial expressions and movement based on dialog, they could save a lot of time and effort.
Currently, game designers are limited by the need to actually do all of the artwork. If they could start with an articulated model of a generic human, tweak some parameters to get the character they want, and then write scripts for what should happen, they'd really be free to focus on the story. Of course, this is more a question of the tools used beforehand, not the game system. But if the game system does it, then each scene could play out with the characters wherever the previous activity left them.
Try running it through valgrind. This has the advantage that you'll get errors on many kinds of bad accesses when they occur, rather than just when the program relies on something that got messed up. Note, however, that OpenSSL as distributed xors uninitialized memory into the random pool, which means that valgrind (not knowing that the outcome is intended to be unpredictable) complains about every use of a random number. You can stop this by defining "PURIFY" when you build OpenSSL, or removing the line that's under this define.
I think debuggers work very well as a hint mechanism. If you have a large program, and it sometimes suddenly breaks, it's useful to know exactly where it's breaking, and give you the stack trace. Sure, that's probably not where the bug is (although it might be, if you've got a typo involving negation), but it gives you a lot more information about the nature of the issue than "It doesn't work."
Debuggers like valgrind can also be valuable for situations where something always works on your system, but may not work elsewhere, or may not work in situations you haven't tried. For example, if you're writing a library and testing it, chances are that some functions will be run only when the stack have never been deeper than it is when the function is run, which means that uninitialized variables will all be 0. If your code depends on this, you won't know until you start getting frustrated email from users.
If I think "Vampire Slayer", I am actually thinking of one of five characters of that sort. I doubt I'd recognize any of the actors if they bit me while out of character. I recognize Michael Dorn's name, but I doubt more people would recognize him as (playing) a Klingon than would recognize some Klingon extra as a Klingon. If I saw him on the street without the makeup, I'd have no clue who he was. (Unlike Leonard Nimoy Bunker Hill, who grew up a few blocks from here)
"Recognized" when dealing with fiction is no different than otherwise; it's a matter of public perception, and reality is irrelevant.
It's important to have a set of stable releases and a set of development releases. That way the user can decide whether they want to use the software or whether they want to participate in the development process. In the Open Source process, anyone can pick either, so the choice has to be made explicit and not easy to overlook. In the closed source process, only special users get to see the development releases, and they know from how they got the software what they have.
As for support, the people who make IBM mainframes also produce and support complete Linux-based solutions. I think that it's kind of silly for corporate customers to talk to Red Hat when they want to get a system which will remain supported forever, and to think that Linux is insufficient to the task, when IBM is available to provide that sort of thing. Sure, Red Hat will be actually providing the version of the software you get initially and doing the support for the beginning, but IBM is the company that will make sure that the problems you have in ten years get solved, either by managing Red Hat for you or by doing the work themselves.
They can just drop claims from the IBM lawsuit without consequences in it. However, they'll have to answer for it in the Red Hat lawsuit. I bet Red Hat will jump on this as a reason to restart that lawsuit, since SCO made a claim that damaged Red Hat's business and that they no longer intend to support. The judge had put the case on hold because SCO was going to try to prove their claims in the IBM case; now they don't seem interested in doing so, so they've essentially lost the bit of the IBM case relevant to the Red Hat case.
For that matter, that was supposed to be an affirmative defense against IBM's copyright infringement countersuit. If they can't come up with some other justification for their massive piracy of IBM's work, IBM is in the position to demand the SCO either GPL its putative IP or pay all of its assets in damages.
Actually, IBM is responsible for a certain amount of writing Linux; they do the work of adding support for their hardware, and this includes some pretty core code, since they make machines that are really odd for the time and require some fundamental changes that then become more common (e.g., NUMA, which they did a lot of work on, and is now useful on multi-processor Opterons).
The lack of a central body is actually an advantage for both IBM and their customers, of course, because it means that no central body needs to be convinced to add support for the new hardware. If IBM wants to make a weird new thing, they can get Linux to run on it and they don't have to convince anybody else of anything in order to ship a machine that works.
Actually, the operation of back-formation, where a singular noun is used as if it were plural and then a final 's' is removed to form an "even more singular" noun is a common part of language change. While you're complaining about "Strut", you should also complain about "cherry" and "asset" (from "cherries"/"cherise" and "assets"/"asetz"). English nouns ending in 's' just don't survive unless there's no way to think of them as a group, especially if there's no good term for what it would mean if resingularized.
They don't have to credit GNU or Linux at all; however, they do have to inform the recipient of their (Sun's) obligation to offer source under the GPL. So, while you might not know you're using anything GNU/Linuxy, you should know you're using something Free Software. At that point you can make the unfounded but accurate assumption that the organization whose copyright notice is on the license is somehow related to the licensed software, and you can find the copyright notices in the source if you bother to get it.
Were RMS not so eager for personal recognition, he would probably consider it more important that the user see the GPL Preamble than that the user know that the GNU project was involved in the software. I have this image of a slick ad during the install process for the Freedoms offered by Free Software. ("Remember, if you don't like something about Sun's Java Desktop System, you can hire an independant programmer to improve it! There's no need to endure uncustomized software!")
Actually, the module doesn't require access to any GPL-only operations or structures. As far as anyone can tell, they just don't want the kernel to report that a non-GPL module has been loaded, because this situation makes kernel developers rightly unwilling to help people with problems (because they have no idea what the non-GPL modules are doing). If they were actually using restricted interfaces, it would be a clear case of copyright infringement, as those interfaces are identified as the ones which make using code a derived work of the kernel. As it is, it is a much less clearly defined issue.
No, you're misunderstanding. You *only* go to the cygwin site and download it. You don't download *more* software. You only download *one thing*. If the user does not download this thing, the user is doing nothing.
Sure, it gets simpler. But it only gets simpler if we get Microsoft to ship cygwin with Windows.
A piece of middleware isn't an OS, but a piece of middleware plus the OS it runs on can be an OS. The middleware API divides applications from OS, but that means that the OS is the total of the middleware and everything closer to the hardware.
There are Java VMs which are, by themselves, OSes, because they run as kernels on the hardware (or, at least, there is no accessible API underneath them); this is how some cell phones are designed. Since you can't tell if the VM you're running on is actually not one of these, any Java VM in combination with everything else it needs to run is an OS, since it's equivalent.
What's the big idea about email? Why not just save HTTP POST form responses in the equivalent of an outbox? The ability to save things is unrelated to the protocol used to send them (and HTTP is a much better protocol for this application than SMTP).
I think that the ability to save forms and form responses would be a major advantage, however.
You don't think "runs/sbin/init (whatever that happens to be) and handles system calls" is an interface to the user? This is the only default interface that you really get, since the user's shell is specified by/etc/passwd and has no default.
For the actual default interface, there's really only the API, sysrq-commands, and device drivers (including the virtual console stuff). Everything else, no matter how fundamental, is an application and is therefore not between applications.
On the other hand, the combination of a POSIX-compliant userspace and the kernel is also an operating system, because it also performs those functions (more extensively in some ways and more conveniently in other ways). There's no reason something can't be an operating system, if it fits the definition, just because a subpart of it also fits the definition. Any point where there is a complete API layer, such that you can divide everything into system and applications, has a side that's an OS.
Cygwin has an installer. You go to www.cygwin.com, click on the icon, run it, go through the wizard, and you have cygwin installed, with most of the GNU tools. If you had some particular tool in mind to get, you make sure to select it in the installer. It doesn't really get any simpler than that; the user obviously has to do something to get software. And users are no more likely to know they want GNU software than to know they want cygwin. For that matter, they'll probably need cygwin in order to install most GNU software on windows.
On the other hand, OSRM is now offering insurance against this sort of thing; for $250 you can get enough legal representation to fend off a suit by a company that doesn't really have an applicable patent, and leave it up to them to recover damages for the frivolous suit.
I don't think it's something that's actually worth worrying about, but peace of mind is available for a reasonable price.
You're not vulnerable, because this only affects TCP connections with easily guessed source ports and known hosts that last for a significant amount of time and where things can't be restarted efficiently. This matters primarily for BGP which you don't use unless you're running a backbone (which is why they contacted the backbone providers first). The main other possibility is that if you have an SSH connection going for a long time, another user on either of the machines (who can get netstat info) who has root on some other machine which can reach one of them can break your connection. So, if you are constantly monitoring logs on a machine by sending them offsite, someone could break your connection before using a local root exploit that would appear in those logs, thus preventing you from knowing what happened.
Unfortunately, paper doesn't last as well with holes in it, and it tends to develop holes as it degrades. If, on the other hand, you print out 2D bar codes, you could probably get it to last thousands of years. You might want to be sure to include documentation of the file format in a couple of languages, though.
"Hey, if you make 8-dot chunks of the dots on these pages, there is a 256-element field such that every 255 chunks, when considered as a polynomial and evaluated at a particular set of elements, gives zero for all of them, on every page." "Eh, it's probably just an incredible coincidence."
Slashdot Mirror
More digital effects does generally mean more scenes involving anonymous hordes. The problem I had with the third movie, and more with the second movie as originally editted, was that it had a substantial portion devoted to battles, which don't really have interesting character interaction.
I think Peter Jackson's mistake was in not cutting any of the battles for the theatrical releases. I found the second one tedious in the theater once Helm's Deep started, but it didn't feel as long, ironically, in the extended version. I think the fact that he kept effects and cut live action worsened the movies, but that, if he had kept them in balance, the effects would have been as important as he claims.
On the other hand, Smeagol was great, despite being a digital effect, and must have contributed significantly to the effect count in the last two movies. So not all digital effects are lacking in depth.
I think the right way to install debian is to tell the installer you don't want anything at all that's not absolutely required, and then install what you want with apt-get.
oggenc supports encoding from raw PCM with an arbitrary number of channels. Of course, you may have to interleave the data yourself, and I have no idea what players will do with the extra channels.
Actually, this doesn't work for anything other than key distribution anyway, because half of your bits will be lost due to guessing the mode wrong (let alone noise, interference, etc). If you were actually trying to send a message, you would have to contend with a whole lot of errors. However, it's possible to determine after the fact exactly which bits were lost due to quantum, so the ends can determine the secret that they share, even though it's impossible to say when you're picking the bits which ones will get through.
The important thing about this scheme is that, after the transfer, the ends can determine where the deletions (bits that got randomized) were, but they can't determine this until after the bits have been transferred. If the receiver could find errors without assistance (due to use of error correction), then the scheme would not have any security, because an active adversary could repair the message to cover the intrusion. Of course, without error correction, transferring your data isn't going to work.
Of course, you have to verify that you actually agree on the key by sending random bits from it to check. Otherwise, an attacker could have intercepted the whole thing and sent on junk, such that the attacker has half the key and the receiver has random data, and the attacker will get half the message and the receiver will get nothing.
There's definitely a market for having separate channels for the lead vocals and the rest of the music, particularly when they get around to having Ogg support for synchronized text.
The really interesting advance would be to be able to reduce the amount of modelling that the designers have to do. If they could just make a single model of each character, and have the system apply facial expressions and movement based on dialog, they could save a lot of time and effort.
Currently, game designers are limited by the need to actually do all of the artwork. If they could start with an articulated model of a generic human, tweak some parameters to get the character they want, and then write scripts for what should happen, they'd really be free to focus on the story. Of course, this is more a question of the tools used beforehand, not the game system. But if the game system does it, then each scene could play out with the characters wherever the previous activity left them.
Try running it through valgrind. This has the advantage that you'll get errors on many kinds of bad accesses when they occur, rather than just when the program relies on something that got messed up. Note, however, that OpenSSL as distributed xors uninitialized memory into the random pool, which means that valgrind (not knowing that the outcome is intended to be unpredictable) complains about every use of a random number. You can stop this by defining "PURIFY" when you build OpenSSL, or removing the line that's under this define.
I think debuggers work very well as a hint mechanism. If you have a large program, and it sometimes suddenly breaks, it's useful to know exactly where it's breaking, and give you the stack trace. Sure, that's probably not where the bug is (although it might be, if you've got a typo involving negation), but it gives you a lot more information about the nature of the issue than "It doesn't work."
Debuggers like valgrind can also be valuable for situations where something always works on your system, but may not work elsewhere, or may not work in situations you haven't tried. For example, if you're writing a library and testing it, chances are that some functions will be run only when the stack have never been deeper than it is when the function is run, which means that uninitialized variables will all be 0. If your code depends on this, you won't know until you start getting frustrated email from users.
What's so offensive about plastic lacing?
If I think "Vampire Slayer", I am actually thinking of one of five characters of that sort. I doubt I'd recognize any of the actors if they bit me while out of character. I recognize Michael Dorn's name, but I doubt more people would recognize him as (playing) a Klingon than would recognize some Klingon extra as a Klingon. If I saw him on the street without the makeup, I'd have no clue who he was. (Unlike Leonard Nimoy Bunker Hill, who grew up a few blocks from here)
"Recognized" when dealing with fiction is no different than otherwise; it's a matter of public perception, and reality is irrelevant.
It's important to have a set of stable releases and a set of development releases. That way the user can decide whether they want to use the software or whether they want to participate in the development process. In the Open Source process, anyone can pick either, so the choice has to be made explicit and not easy to overlook. In the closed source process, only special users get to see the development releases, and they know from how they got the software what they have.
As for support, the people who make IBM mainframes also produce and support complete Linux-based solutions. I think that it's kind of silly for corporate customers to talk to Red Hat when they want to get a system which will remain supported forever, and to think that Linux is insufficient to the task, when IBM is available to provide that sort of thing. Sure, Red Hat will be actually providing the version of the software you get initially and doing the support for the beginning, but IBM is the company that will make sure that the problems you have in ten years get solved, either by managing Red Hat for you or by doing the work themselves.
They can just drop claims from the IBM lawsuit without consequences in it. However, they'll have to answer for it in the Red Hat lawsuit. I bet Red Hat will jump on this as a reason to restart that lawsuit, since SCO made a claim that damaged Red Hat's business and that they no longer intend to support. The judge had put the case on hold because SCO was going to try to prove their claims in the IBM case; now they don't seem interested in doing so, so they've essentially lost the bit of the IBM case relevant to the Red Hat case.
For that matter, that was supposed to be an affirmative defense against IBM's copyright infringement countersuit. If they can't come up with some other justification for their massive piracy of IBM's work, IBM is in the position to demand the SCO either GPL its putative IP or pay all of its assets in damages.
Actually, IBM is responsible for a certain amount of writing Linux; they do the work of adding support for their hardware, and this includes some pretty core code, since they make machines that are really odd for the time and require some fundamental changes that then become more common (e.g., NUMA, which they did a lot of work on, and is now useful on multi-processor Opterons).
The lack of a central body is actually an advantage for both IBM and their customers, of course, because it means that no central body needs to be convinced to add support for the new hardware. If IBM wants to make a weird new thing, they can get Linux to run on it and they don't have to convince anybody else of anything in order to ship a machine that works.
Actually, the operation of back-formation, where a singular noun is used as if it were plural and then a final 's' is removed to form an "even more singular" noun is a common part of language change. While you're complaining about "Strut", you should also complain about "cherry" and "asset" (from "cherries"/"cherise" and "assets"/"asetz"). English nouns ending in 's' just don't survive unless there's no way to think of them as a group, especially if there's no good term for what it would mean if resingularized.
They don't have to credit GNU or Linux at all; however, they do have to inform the recipient of their (Sun's) obligation to offer source under the GPL. So, while you might not know you're using anything GNU/Linuxy, you should know you're using something Free Software. At that point you can make the unfounded but accurate assumption that the organization whose copyright notice is on the license is somehow related to the licensed software, and you can find the copyright notices in the source if you bother to get it.
Were RMS not so eager for personal recognition, he would probably consider it more important that the user see the GPL Preamble than that the user know that the GNU project was involved in the software. I have this image of a slick ad during the install process for the Freedoms offered by Free Software. ("Remember, if you don't like something about Sun's Java Desktop System, you can hire an independant programmer to improve it! There's no need to endure uncustomized software!")
Actually, the module doesn't require access to any GPL-only operations or structures. As far as anyone can tell, they just don't want the kernel to report that a non-GPL module has been loaded, because this situation makes kernel developers rightly unwilling to help people with problems (because they have no idea what the non-GPL modules are doing). If they were actually using restricted interfaces, it would be a clear case of copyright infringement, as those interfaces are identified as the ones which make using code a derived work of the kernel. As it is, it is a much less clearly defined issue.
No, you're misunderstanding. You *only* go to the cygwin site and download it. You don't download *more* software. You only download *one thing*. If the user does not download this thing, the user is doing nothing.
Sure, it gets simpler. But it only gets simpler if we get Microsoft to ship cygwin with Windows.
A piece of middleware isn't an OS, but a piece of middleware plus the OS it runs on can be an OS. The middleware API divides applications from OS, but that means that the OS is the total of the middleware and everything closer to the hardware.
There are Java VMs which are, by themselves, OSes, because they run as kernels on the hardware (or, at least, there is no accessible API underneath them); this is how some cell phones are designed. Since you can't tell if the VM you're running on is actually not one of these, any Java VM in combination with everything else it needs to run is an OS, since it's equivalent.
What's the big idea about email? Why not just save HTTP POST form responses in the equivalent of an outbox? The ability to save things is unrelated to the protocol used to send them (and HTTP is a much better protocol for this application than SMTP).
I think that the ability to save forms and form responses would be a major advantage, however.
Um... KDE is the wrong suggestion. The browser (konqueror) has always been integrated into KDE.
You don't think "runs /sbin/init (whatever that happens to be) and handles system calls" is an interface to the user? This is the only default interface that you really get, since the user's shell is specified by /etc/passwd and has no default.
For the actual default interface, there's really only the API, sysrq-commands, and device drivers (including the virtual console stuff). Everything else, no matter how fundamental, is an application and is therefore not between applications.
On the other hand, the combination of a POSIX-compliant userspace and the kernel is also an operating system, because it also performs those functions (more extensively in some ways and more conveniently in other ways). There's no reason something can't be an operating system, if it fits the definition, just because a subpart of it also fits the definition. Any point where there is a complete API layer, such that you can divide everything into system and applications, has a side that's an OS.
Cygwin has an installer. You go to www.cygwin.com, click on the icon, run it, go through the wizard, and you have cygwin installed, with most of the GNU tools. If you had some particular tool in mind to get, you make sure to select it in the installer. It doesn't really get any simpler than that; the user obviously has to do something to get software. And users are no more likely to know they want GNU software than to know they want cygwin. For that matter, they'll probably need cygwin in order to install most GNU software on windows.
On the other hand, OSRM is now offering insurance against this sort of thing; for $250 you can get enough legal representation to fend off a suit by a company that doesn't really have an applicable patent, and leave it up to them to recover damages for the frivolous suit.
I don't think it's something that's actually worth worrying about, but peace of mind is available for a reasonable price.
You're not vulnerable, because this only affects TCP connections with easily guessed source ports and known hosts that last for a significant amount of time and where things can't be restarted efficiently. This matters primarily for BGP which you don't use unless you're running a backbone (which is why they contacted the backbone providers first). The main other possibility is that if you have an SSH connection going for a long time, another user on either of the machines (who can get netstat info) who has root on some other machine which can reach one of them can break your connection. So, if you are constantly monitoring logs on a machine by sending them offsite, someone could break your connection before using a local root exploit that would appear in those logs, thus preventing you from knowing what happened.
Unfortunately, paper doesn't last as well with holes in it, and it tends to develop holes as it degrades. If, on the other hand, you print out 2D bar codes, you could probably get it to last thousands of years. You might want to be sure to include documentation of the file format in a couple of languages, though.
"Hey, if you make 8-dot chunks of the dots on these pages, there is a 256-element field such that every 255 chunks, when considered as a polynomial and evaluated at a particular set of elements, gives zero for all of them, on every page." "Eh, it's probably just an incredible coincidence."