DEC systematically avoided extending their systems into the personal computer world, and overcharged when they did, so that despite the fact that virtually all the personal computer platforms in use today have descended from DEC systems[1] or were developed on DEC hardware[2], DEC was swallowed up whole by a personal computer company and virtually lost as the corpse of Compaq was digested by HP.
Linden Labs has to either adapt to an open virtual world environment someone else comes up with, or drive the development of the open environment themselves. They seem to be making the choice of leading the charge instead of waiting to be run over.
[1] CP/M is much like an RSX-11/RT-11 lookalike, and MS-DOS and Windows inherit that. NT was designed by the principle architect of VMS and RSX. [2] UNIX of course grew to maturity on the PDP-11 and the VAX.
The first story that had a real "virtual world" feel - Vinge's True Names - has proven awfully visionary too. Including the newbies with the giant badly-rendered motorcycles.:)
When I met him at Usenix he looked more like a guy wearing dark glasses and an unusually thick sweater for the season... his wearable computer was built into a vest and the display was hidden in the glasses frame. The new model Eyetap is no more obtrusive than the borg-style bluetooth headsets you see people wearing.
He's done stuff like having his reality completely mediated, with advertising around him bluescreened out by an image recogniser back in his office. The possibilities are endless.
Unless the iPhone hardware itself is capable of transmitting outside of its assigned telephony frequency range
That is one specific claim that I have seen, that the iPhone does use a "software defined radio" except that (quoting that section) the software isn't "expected to be modified by a party other than the manufacturer".
Declaring that the iPhone is not supposed to run native third-party software and then backing that claim up by vigorously acting to prevent it from being used that way is completely consistent with Apple's handling of attempts to break Fairplay. They do not make it particularly hard to bypass the DRM in iTunes by converting the music to uncompressed digital data, because that was explicitly allowed for burning CDs, but they respond very quickly when someone comes up with a way of removing the DRM from the compressed file without converting it.
Whether specific control and access to the telephony components of the iPhone are via an OS X driver on the one hand, or via a PalmOS or Windows CE driver would appear to have no specific bearing.
The second claim that I have seen is that the iPhone CPU has that applications are running on the same CPU that directly controls the software radio, whereas the Palm and Windows CE devices have a second processor handling the telephony functions.
Palm OS is unlikely to be an issue because the published PalmOS API is not that of the underlying OS (AMX in the 68000 based devices, I don't know about the ARMs), and in the ARM-based palms I was investigating before I washed my hands of them for cellphones most software still ran under a 68000 emulator and even native code didn't have direct access to the hardware. In addition, of course, the early Palm phones using the 68000 processor did not have the CPU power to spare for D/A and A/D conversion in software in realtime.
Windows CE started out from the start with native code support, so any phone using Windows CE would have to have additional technical barriers in place (such as a separate telephony CPU) to keep the software from having direct access to a software defined radio if any specific Windows CE device used one. Windows CE devices are made by a number of manufacturers, and each gets their own certification.
I'm not trying to suggest that you're bringing up the possibility deliberately as fodder for FUD, just that it has some of the hallmarks: a general concern that sounds potentially problematic, whether it actually is or not, and not much in the way of detail other than that.
I'm not particularly a fan of the iPhone and I am DEFINITELY not one to let Apple off the hook when they do something stupid (check my webpage under "IO Port"), and I'm kind of confused as to what I would be seeding uncertainty about here... whether Apple has a good reason for restricting access or not, most iPhone customers simply won't care, so even if everyone believes everything I say here as gospel it'll make no difference to Apple one way or the other. Meanwhile, folks willing to mod their iPhone at this point are not risk-averse individuals nor can I see why they'd care whether Apple has a "good" reason or not, courts are not speedy, so the only impact that'll have will be years down the road long after their warranties would have expired anyway.
2. Downgrade to v1.0.2
1. Hold down the Sleep/Wake and Home buttons at the same time for about 10 seconds. The phone should shut down.
2. When the phone shuts down, release the Sleep/Wake button but continue holding Home
3. Wait until iTunes recognizes the iPhone. The screen will appear to be off, but iTunes will eventually recognize the iPhone. When it does, let go.
4. A message will appear telling you to restore. Click OK
5. Using your favorite browser, download the v1.0.2 software from this location.
This implies that you have to downgrade to get a version with the hole in it.
Well, if it's an exploit in Firefox it'll be fixed within 24 hours, and/. will just make that an update to the article.
If it's in IE it'll take 2-6 weeks and effect Windows Media Player, Real Player, and seven Windows-specific Firefox extensions... and when they're temporarily disabled by a Firefox update you'll get a second front page story in/. about that.
If it's an image handling vulnerability in Safari then according to half the OSS community it's nothing to worry about, and according to the other half it's what you deserve for supping with the devil, and Unsanity will come out with a patch it within 24 hours.
Since it's in the iPhone there will be another story when the security alert comes out, another when the patch comes out, another when the patch bricks someone's iPhone, and another when it shows up in Dilbert.
As has been pointed out, any contract term, EULA, et cetera that did specify the iPhone must not be hacked in order to allow it to be used with other carriers
The problem with the iPhone seems to be that the software radio is vulnerable to being exploited if you can get root on the iPhone, which may violate FCC rules and certainly makes carriers nervous. Originally, articles claimed that the software radio was driven directly from an OS X driver, but it seems from comments elsewhere that you still have to use AT commands to talk to the cellphone part of the device. I have not seen any clarification as to whether locking the iPhone is necessary for FCC certification or not... obviously if the software radio is under direct control of an OSX driver it almost certainly would be.
I have asked for clarification on this point before but answer came there none.
In any case, if that point is true, then a contract term that required the iPhone software not be modified to continue to use the iPhone as a certified device would probably be enforceable... but if you could modify it without becoming root you'd be home free.:)
I beg to differ, there is some creative work involved when compiling, but I'll skip the details about that
No, no, elaborate. I wrote my first compiler in 1979 and I thought that after all this time I was pretty familiar with the process of mechanically translating a program from one form to another.
You mention a "cover" of a song, well that clearly is infringing as the lyrics remain intact.
There's ample case law supporting the tune itself being a copyrightable work, and for the argument that a faithful translation from a score, piano roll, MIDI file, or other "source code" into audio format, whether mechanically (as in a player piano, score-driven sequencer, or MIDI sequencer) or by human effort, makes the sounds themselves a derived work, and a recording of those sounds a derived work. There's no wriggle room here.
If I read a book on algorithms, and I implement an algorithm from the book, I am not infringing on copyright.
It would be interesting to see how that would apply where you were performing a faithful mechanical translation from one form to another, as I did when porting the RATFOR compiler from the book Software Tools to RSX-11 in 1982. The FORTRAN code I produced was hundreds of lines of code hand-translated from RATFOR, almost line for line and step for step the equivalent code... never in the past 30 years have I done anything like it. THAT is something that might be in the grey area between transcription and reference, but using an algorithm from a text book is rarely even that similar to the process of compilation.
Is it much different than google parsing documents to words for indexing?
Oh yes, very much so. An index is not a translation of the original work. One can not imagine an "English - Index" followed by "Index - English" that would produce results similar to decompilation, to transcription of music, or to translating a translated work to the original language.
If the compilation process is seen as removing the idea from the expression, it may reasonably be "fair use" of the published work.
Indeed, I have to admit that sentence in its entirety is true, but so is "If I was born on Mars, then I am the emperor of the universe".
The "fair use" doctrine is not very well defined it is constantly being reevaluated by judges.
The envelope of what the fair use doctrine allows, however, is extremely narrow. The gray area is real, but it's around a much smaller part of the range of possibilities than you're implying... it certainly does not allow for unrestricted redistribution of a nontrivial copyrighted work.
It can be argued that source code is the "expression" of the idea, and a compiled program is merely a synopsis or crux of the idea, a separate work.
There is no creative work involved in creating a compiled program from the source code, therefore it's not a separate work. Hell, even if there was, it would still be a derived work, like a cover of a song. You would have to throw out too much existing law and reverse too many precedents, as well as find a judge who is unaware of the effect that such a decision would make on the software industry, that such an argument can not possibly be carried through in anything like the current legal environment.
The GPL may not be able to exceed the rights granted under copyright law.
The GPL is not an attempt to exceed those rights, so that point is moot.
I'm sorry that I accused you of being confused. It was the kindest interpretation I could cast on your argument, but since you insist I withdraw the accusation.
This part of your argument makes no sense to me. What does it refer to?
Think about a binary program, it is arguable that producing a binary program from a legally obtained copyrighted material does not violate copyright law regardless of the GPL because the copyrighted "expression" is never republished.
The GPL explicitly does not restrict what you can do with a binary you created from GPLed software UNLESS you do, in fact, republish it.
Whatever document you might be reading that actually claims to restrict anything but distribution, well, it's not the GPL.
You also seem to be confused about what fair use allows, and what a derivative work is.
I have to admit, though, that you're not the only one confused.
For example, I'm kind of confused as to what you think this has to do with copyright on cease-and-desist letters.
I have never thought that it is UNIX way to not to check and sanitize input
What the hell are you talking about?
What I wrote was that the UNIX "exec" API passes strings through to the called program without having to concatenate them into a command line that is then parsed by the called program and separated out into separate parameters again. That is, the calling program does not have to guess how the called program will parse quotes. It's got nothing to do with "sanitizing": the calling program itself actually has to PUT QUOTES IN to the command line it's building up.
This is like using prepared statements in SQL, a technique that is widely used to avoid SQL quoting attacks by preventing an extra quoting-and-reparsing step. It's a more secure API, and provides an additional layer of security.
This has nothing to do with sanitizing... performing checks when you DO know how the target is going to interpret text. It has to do with eliminating a whole category of attacks completely.
Something else that IE (as of last time I looked anyway) and possibly other browsers get wrong is that they try to "guess" the content of the file instead of trusting that what the web server says the file is, the file actually is.
If the OS and the browser were configured correctly, and the browser maintained a hard sandbox and the OS made it possible for it to know reliably what helper applications and plugins also maintained a hard sandbox, then it wouldn't matter whether the MIME type was guessed or not... because there would be no mechanism for it to be passed to an application that would allow the content to execute of the type were wrong.
THAT is the real problem, that the Windows registry and Apple's LaunchServices can not be trusted to securely handle untrusted content.
IE, itself, has additional problems because it has internal components that themselves are not secure, and so it can be tricked into executing code even without using naive helper applications. That's a whole different class of problems and one that is, so far at least, limited to IE and (to a far lesser extent) Firefox.
PS: It's not the *type* that is trusted or not trusted... it's the *application* that's supposed to display it. No attribute of a file downloaded from an untrusted source (and all web pages, no matter where located, are 'untrusted') should ever need to be correct for trust to be maintained, and only the user should be able to request that a file be granted any kind of trust.
That means, a downloaded file is not unpacked, installed, or otherwise opened unless there is a trusted viewer that maintains a hard sandbox registered for it, OR the user selects the file and requests that it be opened, installed, unpacked, etcetera. And that trusted viewer, in turn. must not install or unpack a file outside of a sandbox that normal applications won't stumble into.
I don't know of any system that maintains this level of security without custom user configuration, but nothing else is acceptable.
I'm pretty sure all the major browsers do some guessing these days, since there are a lot of misconfigured servers out there
It doesn't matter what the browser does. The problem is that when the browser goes to resolve a URI, it sees one list of URI and mime-type handlers (and, in the case of Windows, ActiveX controls) that are used both for local content (for example, "help:" on OSX and the ".chm" handler on Windows) and global (for example, "http:" or ".html").
Applications, like a help viewer, that are not intended to be used by untrusted objects, are frequently subject to attacks that more paranoid applications designed for the web aren't. In some cases, like the control panel applets in Windows and the script handlers on both platforms, they can't be made secure because they need to do dangerous things.
There needs to be a way for an application to register it as a handler for internal, local use only... and that needs to be the default for applications that have not upgraded to the new API. There needs to be a way for applications that are handling untrusted objects to request only handlers that have explicitly registered as "secure"... and, ideally, it should be possible to make that the default for an application that has not yet upgraded to the new API.
Windows has a second problem that isn't shared by other desktops, in that the mechanism used to call a program is more like the UNIX "system" API than the UNIX "exec" API... and the calling application has to guess how the called application will interpret things like quotes.
Regardless of how the browser decides what the mime-type is, there must be a way for the browser to request from the OS a list of handlers that will always use a sandbox when displaying the content, regardless of its nominal source.
I get into this hyperfocus state quite easily when working, and lose all sense of time and space. And not just programming, I've gotten into the zone when driving and suddenly come to myself *after* I've had to react (like, I've avoided someone pulling into my lane unexpectedly), aware that I hadn't been really conscious of anything up to then. This is fine when programming, but it's a bit worrying when one's driving a couple of tons of metal. On the other hand, I'm not necessarily any better at accident avoidance maneuvers when I *am* concentrating on driving, so...
This is bad news for the future of REAL AI if this gets generalized... imagine a future of self-aware machines, programmed to be neurotic, trapped there because they don't want to lose their jobs by getting their personalities rebalanced...
Scientific basis for Sirius Cybernetics in Hitchhikers' Guide to the Galaxy?
URI and MIME type handling in both Windows and OSX is profoundly broken. It's second only to ActiveX in the opportunity for exploits... the basic problem is that when apps register handlers for local use (eg, 'help:' or '.chm') they are available to untrusted content by default. The fix is to have separate registries or separate flags that allow applications to explicitly register as handlers for internal use, or for use on untrusted documents.
A 6809-based computer couldn't have competed with a 68000-based one, any more than the 16-bit 6502 variant in the Apple IIGS could have let it compete on a level playing field with the 68000. OS/9 was in assembler, but Microware already had a portable C port (OS/9000) in the pipe when the Amiga came out. If Tandy had made OS/9 a standard part of the Coco that would have accelerated things and given them a credible high-end personal computer.
But there's no way they'd have done that, because they didn't want to pay Microware royalties with every Coco sold. They were aiming the Coco at the low end, their equivalent of the VIC-20. The overhead of the OS/9 license would never have fit.
So take a Linux or BSD Unix distro, port the Amiga GUI over to it, port Amiga libraries over to it to support AmigaOS API calls, and call it AmigaOS 5.0, right?
Basically, yes. The only way AmigaOS 5 can possibly recover development costs, let alone be considered a success, is if it introduces some capability that's such an incredible breakthrough that people are compelled to switch to it (including switching hardware) just to get that capability... or if the cheapest possible implementation - compatibility libraries on an existing OS - is used.
Apple had a viable presence in the market to start with and had to use BOTH tricks, and they're still haven't returned to their peak market share.
I loved the original Amiga OS, but it was killed dead by the feud between Gould and Tramiel, and it was already doomed when the even-more-doomed BeOS showed up to steal the geeks away. All the killer Amiga apps and vendors, inlcuding NewTek, have already gone elsewhere - there's probably more of a market for BeOS apps than Amiga apps right now.
So they're starting out with no hardware, no support for commodity hardware, no user base, no apps, claim to be doing a scratch implementation, and given that QNX couldn't get any interest in QNX (which blew away AmigaOS) after Amiga failed to pay for the development of the consumer version... I can't see any killer capabilities coming. The only hope I can see for the latest rump of AmigaOS is for them to be maximally cynical and basically sell an emulation kit.
Menus at the top of the GUI, rather than the application window. Brain-damaged limitation on the location of the window resize controls.
Those misfeatures were copied from the original Mac.
Task bar/dock.
That was not part of Intuition.
Drive icons. Drag'n'drop,...
That was copied from the original Mac.
Really usable command line interface.
That's been part of every UNIX system since before Commodore made computers.
BTW, anyone got a "stickies" (on-screen Post-It (tm)) equivalent for the Mac or Gnome?
That's not part of Intuition. And the first version of Stickies was written by Apple and shipped in System 7.5. It's now a dashboard widget, which makes it even more pointless than it was to begin with.
The only actual feature of the Amiga that you're looking for is "screens", and the only reason you needed multiple screens rather than just running windows in different modes was that the Copper wasn't fast enough to composite on a window-by-window basis... so they had it switch modes and bitmaps in the horizontal sync interval... which was bloody impressive at the time. Modern GPUs support 3d compositing on a surface-by-surface basis in real time, so you can get the effect of "screens" on a window-by-window basis without the CPU having to deal with it.
The Amiga user interface had two main advantages over its contemporaries.
(1) It was running on top of an actual operating system. This wasn't a user interface feature, but it did make it possible to do things on the Amiga that MacOS and Windows and TOS couldn't dream of.
(2) In addition, the widgets in the UI were implemented in Intuition itself, rather than via callbacks or in the application message loop, so it didn't freeze when an application quit responding.
That second feature is about all I'd like to bring forward from the Amiga into a modern OS, since it's unlikely they'll actually have a real-time kernel... if they wanted that they'd pay QNX what they owed, pay whatever it took to make them happy, and then pay them more for an Amiga-branded port of Photon and QNX. Because, frankly, there's not much else that's got a chance of making an Amiga OS that's anything but a money sink.
I just lined that map up with NASA's city lights map, and the correspondence is awfully close, allowing for the low resolution of the internet map: connectivity does seem to be "as common as electric power".
Slashdot Mirror
DEC systematically avoided extending their systems into the personal computer world, and overcharged when they did, so that despite the fact that virtually all the personal computer platforms in use today have descended from DEC systems[1] or were developed on DEC hardware[2], DEC was swallowed up whole by a personal computer company and virtually lost as the corpse of Compaq was digested by HP.
Linden Labs has to either adapt to an open virtual world environment someone else comes up with, or drive the development of the open environment themselves. They seem to be making the choice of leading the charge instead of waiting to be run over.
[1] CP/M is much like an RSX-11/RT-11 lookalike, and MS-DOS and Windows inherit that. NT was designed by the principle architect of VMS and RSX.
[2] UNIX of course grew to maturity on the PDP-11 and the VAX.
The first story that had a real "virtual world" feel - Vinge's True Names - has proven awfully visionary too. Including the newbies with the giant badly-rendered motorcycles. :)
The cute and cartoony Miis would be a poor fit in Second Life,
Have you visited Raglan Shire recently?
Steve Mann has been doing this kind of thing since the '90s. Well, since 1981, but it didn't really get wearable until the '90s.
http://en.wikipedia.org/wiki/Steve_Mann
http://wearcam.org/steve.html
When I met him at Usenix he looked more like a guy wearing dark glasses and an unusually thick sweater for the season... his wearable computer was built into a vest and the display was hidden in the glasses frame. The new model Eyetap is no more obtrusive than the borg-style bluetooth headsets you see people wearing.
He's done stuff like having his reality completely mediated, with advertising around him bluescreened out by an image recogniser back in his office. The possibilities are endless.
Unless the iPhone hardware itself is capable of transmitting outside of its assigned telephony frequency range
That is one specific claim that I have seen, that the iPhone does use a "software defined radio" except that (quoting that section) the software isn't "expected to be modified by a party other than the manufacturer".
Declaring that the iPhone is not supposed to run native third-party software and then backing that claim up by vigorously acting to prevent it from being used that way is completely consistent with Apple's handling of attempts to break Fairplay. They do not make it particularly hard to bypass the DRM in iTunes by converting the music to uncompressed digital data, because that was explicitly allowed for burning CDs, but they respond very quickly when someone comes up with a way of removing the DRM from the compressed file without converting it.
Whether specific control and access to the telephony components of the iPhone are via an OS X driver on the one hand, or via a PalmOS or Windows CE driver would appear to have no specific bearing.
The second claim that I have seen is that the iPhone CPU has that applications are running on the same CPU that directly controls the software radio, whereas the Palm and Windows CE devices have a second processor handling the telephony functions.
Palm OS is unlikely to be an issue because the published PalmOS API is not that of the underlying OS (AMX in the 68000 based devices, I don't know about the ARMs), and in the ARM-based palms I was investigating before I washed my hands of them for cellphones most software still ran under a 68000 emulator and even native code didn't have direct access to the hardware. In addition, of course, the early Palm phones using the 68000 processor did not have the CPU power to spare for D/A and A/D conversion in software in realtime.
Windows CE started out from the start with native code support, so any phone using Windows CE would have to have additional technical barriers in place (such as a separate telephony CPU) to keep the software from having direct access to a software defined radio if any specific Windows CE device used one. Windows CE devices are made by a number of manufacturers, and each gets their own certification.
I'm not trying to suggest that you're bringing up the possibility deliberately as fodder for FUD, just that it has some of the hallmarks: a general concern that sounds potentially problematic, whether it actually is or not, and not much in the way of detail other than that.
I'm not particularly a fan of the iPhone and I am DEFINITELY not one to let Apple off the hook when they do something stupid (check my webpage under "IO Port"), and I'm kind of confused as to what I would be seeding uncertainty about here... whether Apple has a good reason for restricting access or not, most iPhone customers simply won't care, so even if everyone believes everything I say here as gospel it'll make no difference to Apple one way or the other. Meanwhile, folks willing to mod their iPhone at this point are not risk-averse individuals nor can I see why they'd care whether Apple has a "good" reason or not, courts are not speedy, so the only impact that'll have will be years down the road long after their warranties would have expired anyway.
This implies that you have to downgrade to get a version with the hole in it.
Well, if it's an exploit in Firefox it'll be fixed within 24 hours, and /. will just make that an update to the article.
/. about that.
If it's in IE it'll take 2-6 weeks and effect Windows Media Player, Real Player, and seven Windows-specific Firefox extensions... and when they're temporarily disabled by a Firefox update you'll get a second front page story in
If it's an image handling vulnerability in Safari then according to half the OSS community it's nothing to worry about, and according to the other half it's what you deserve for supping with the devil, and Unsanity will come out with a patch it within 24 hours.
Since it's in the iPhone there will be another story when the security alert comes out, another when the patch comes out, another when the patch bricks someone's iPhone, and another when it shows up in Dilbert.
If it's in Opera nobody will ever hear about it.
As has been pointed out, any contract term, EULA, et cetera that did specify the iPhone must not be hacked in order to allow it to be used with other carriers
:)
The problem with the iPhone seems to be that the software radio is vulnerable to being exploited if you can get root on the iPhone, which may violate FCC rules and certainly makes carriers nervous. Originally, articles claimed that the software radio was driven directly from an OS X driver, but it seems from comments elsewhere that you still have to use AT commands to talk to the cellphone part of the device. I have not seen any clarification as to whether locking the iPhone is necessary for FCC certification or not... obviously if the software radio is under direct control of an OSX driver it almost certainly would be.
I have asked for clarification on this point before but answer came there none.
In any case, if that point is true, then a contract term that required the iPhone software not be modified to continue to use the iPhone as a certified device would probably be enforceable... but if you could modify it without becoming root you'd be home free.
I beg to differ, there is some creative work involved when compiling, but I'll skip the details about that
No, no, elaborate. I wrote my first compiler in 1979 and I thought that after all this time I was pretty familiar with the process of mechanically translating a program from one form to another.
You mention a "cover" of a song, well that clearly is infringing as the lyrics remain intact.
There's ample case law supporting the tune itself being a copyrightable work, and for the argument that a faithful translation from a score, piano roll, MIDI file, or other "source code" into audio format, whether mechanically (as in a player piano, score-driven sequencer, or MIDI sequencer) or by human effort, makes the sounds themselves a derived work, and a recording of those sounds a derived work. There's no wriggle room here.
If I read a book on algorithms, and I implement an algorithm from the book, I am not infringing on copyright.
It would be interesting to see how that would apply where you were performing a faithful mechanical translation from one form to another, as I did when porting the RATFOR compiler from the book Software Tools to RSX-11 in 1982. The FORTRAN code I produced was hundreds of lines of code hand-translated from RATFOR, almost line for line and step for step the equivalent code... never in the past 30 years have I done anything like it. THAT is something that might be in the grey area between transcription and reference, but using an algorithm from a text book is rarely even that similar to the process of compilation.
Is it much different than google parsing documents to words for indexing?
Oh yes, very much so. An index is not a translation of the original work. One can not imagine an "English - Index" followed by "Index - English" that would produce results similar to decompilation, to transcription of music, or to translating a translated work to the original language.
If the compilation process is seen as removing the idea from the expression, it may reasonably be "fair use" of the published work.
Indeed, I have to admit that sentence in its entirety is true, but so is "If I was born on Mars, then I am the emperor of the universe".
The "fair use" doctrine is not very well defined it is constantly being reevaluated by judges.
The envelope of what the fair use doctrine allows, however, is extremely narrow. The gray area is real, but it's around a much smaller part of the range of possibilities than you're implying... it certainly does not allow for unrestricted redistribution of a nontrivial copyrighted work.
It can be argued that source code is the "expression" of the idea, and a compiled program is merely a synopsis or crux of the idea, a separate work.
There is no creative work involved in creating a compiled program from the source code, therefore it's not a separate work. Hell, even if there was, it would still be a derived work, like a cover of a song. You would have to throw out too much existing law and reverse too many precedents, as well as find a judge who is unaware of the effect that such a decision would make on the software industry, that such an argument can not possibly be carried through in anything like the current legal environment.
The GPL may not be able to exceed the rights granted under copyright law.
The GPL is not an attempt to exceed those rights, so that point is moot.
I'm sorry that I accused you of being confused. It was the kindest interpretation I could cast on your argument, but since you insist I withdraw the accusation.
This part of your argument makes no sense to me. What does it refer to?
Think about a binary program, it is arguable that producing a binary program from a legally obtained copyrighted material does not violate copyright law regardless of the GPL because the copyrighted "expression" is never republished.
The GPL explicitly does not restrict what you can do with a binary you created from GPLed software UNLESS you do, in fact, republish it.
Whatever document you might be reading that actually claims to restrict anything but distribution, well, it's not the GPL.
You also seem to be confused about what fair use allows, and what a derivative work is.
I have to admit, though, that you're not the only one confused.
For example, I'm kind of confused as to what you think this has to do with copyright on cease-and-desist letters.
I have never thought that it is UNIX way to not to check and sanitize input
... performing checks when you DO know how the target is going to interpret text. It has to do with eliminating a whole category of attacks completely.
What the hell are you talking about?
What I wrote was that the UNIX "exec" API passes strings through to the called program without having to concatenate them into a command line that is then parsed by the called program and separated out into separate parameters again. That is, the calling program does not have to guess how the called program will parse quotes. It's got nothing to do with "sanitizing": the calling program itself actually has to PUT QUOTES IN to the command line it's building up.
This is like using prepared statements in SQL, a technique that is widely used to avoid SQL quoting attacks by preventing an extra quoting-and-reparsing step. It's a more secure API, and provides an additional layer of security.
This has nothing to do with sanitizing
Something else that IE (as of last time I looked anyway) and possibly other browsers get wrong is that they try to "guess" the content of the file instead of trusting that what the web server says the file is, the file actually is.
If the OS and the browser were configured correctly, and the browser maintained a hard sandbox and the OS made it possible for it to know reliably what helper applications and plugins also maintained a hard sandbox, then it wouldn't matter whether the MIME type was guessed or not... because there would be no mechanism for it to be passed to an application that would allow the content to execute of the type were wrong.
THAT is the real problem, that the Windows registry and Apple's LaunchServices can not be trusted to securely handle untrusted content.
IE, itself, has additional problems because it has internal components that themselves are not secure, and so it can be tricked into executing code even without using naive helper applications. That's a whole different class of problems and one that is, so far at least, limited to IE and (to a far lesser extent) Firefox.
PS: It's not the *type* that is trusted or not trusted... it's the *application* that's supposed to display it. No attribute of a file downloaded from an untrusted source (and all web pages, no matter where located, are 'untrusted') should ever need to be correct for trust to be maintained, and only the user should be able to request that a file be granted any kind of trust.
That means, a downloaded file is not unpacked, installed, or otherwise opened unless there is a trusted viewer that maintains a hard sandbox registered for it, OR the user selects the file and requests that it be opened, installed, unpacked, etcetera. And that trusted viewer, in turn. must not install or unpack a file outside of a sandbox that normal applications won't stumble into.
I don't know of any system that maintains this level of security without custom user configuration, but nothing else is acceptable.
I'm pretty sure all the major browsers do some guessing these days, since there are a lot of misconfigured servers out there
It doesn't matter what the browser does. The problem is that when the browser goes to resolve a URI, it sees one list of URI and mime-type handlers (and, in the case of Windows, ActiveX controls) that are used both for local content (for example, "help:" on OSX and the ".chm" handler on Windows) and global (for example, "http:" or ".html").
Applications, like a help viewer, that are not intended to be used by untrusted objects, are frequently subject to attacks that more paranoid applications designed for the web aren't. In some cases, like the control panel applets in Windows and the script handlers on both platforms, they can't be made secure because they need to do dangerous things.
There needs to be a way for an application to register it as a handler for internal, local use only... and that needs to be the default for applications that have not upgraded to the new API. There needs to be a way for applications that are handling untrusted objects to request only handlers that have explicitly registered as "secure"... and, ideally, it should be possible to make that the default for an application that has not yet upgraded to the new API.
Windows has a second problem that isn't shared by other desktops, in that the mechanism used to call a program is more like the UNIX "system" API than the UNIX "exec" API... and the calling application has to guess how the called application will interpret things like quotes.
Regardless of how the browser decides what the mime-type is, there must be a way for the browser to request from the OS a list of handlers that will always use a sandbox when displaying the content, regardless of its nominal source.
I get into this hyperfocus state quite easily when working, and lose all sense of time and space. And not just programming, I've gotten into the zone when driving and suddenly come to myself *after* I've had to react (like, I've avoided someone pulling into my lane unexpectedly), aware that I hadn't been really conscious of anything up to then. This is fine when programming, but it's a bit worrying when one's driving a couple of tons of metal. On the other hand, I'm not necessarily any better at accident avoidance maneuvers when I *am* concentrating on driving, so...
BTW Google reads your slashdot comments too.
And the Wayback Machine keeps them forever! Muahahahah!
This is bad news for the future of REAL AI if this gets generalized... imagine a future of self-aware machines, programmed to be neurotic, trapped there because they don't want to lose their jobs by getting their personalities rebalanced...
Scientific basis for Sirius Cybernetics in Hitchhikers' Guide to the Galaxy?
URI and MIME type handling in both Windows and OSX is profoundly broken. It's second only to ActiveX in the opportunity for exploits... the basic problem is that when apps register handlers for local use (eg, 'help:' or '.chm') they are available to untrusted content by default. The fix is to have separate registries or separate flags that allow applications to explicitly register as handlers for internal use, or for use on untrusted documents.
Cochlear implants connected via a secure encrypted path to an RIAA-authorized epoxy-embedded temper-evident "droud" jack.
Oh, and people with perfect pitch will need to be registered and larynx-tagged.
A 6809-based computer couldn't have competed with a 68000-based one, any more than the 16-bit 6502 variant in the Apple IIGS could have let it compete on a level playing field with the 68000. OS/9 was in assembler, but Microware already had a portable C port (OS/9000) in the pipe when the Amiga came out. If Tandy had made OS/9 a standard part of the Coco that would have accelerated things and given them a credible high-end personal computer.
But there's no way they'd have done that, because they didn't want to pay Microware royalties with every Coco sold. They were aiming the Coco at the low end, their equivalent of the VIC-20. The overhead of the OS/9 license would never have fit.
So take a Linux or BSD Unix distro, port the Amiga GUI over to it, port Amiga libraries over to it to support AmigaOS API calls, and call it AmigaOS 5.0, right?
Basically, yes. The only way AmigaOS 5 can possibly recover development costs, let alone be considered a success, is if it introduces some capability that's such an incredible breakthrough that people are compelled to switch to it (including switching hardware) just to get that capability... or if the cheapest possible implementation - compatibility libraries on an existing OS - is used.
Apple had a viable presence in the market to start with and had to use BOTH tricks, and they're still haven't returned to their peak market share.
I loved the original Amiga OS, but it was killed dead by the feud between Gould and Tramiel, and it was already doomed when the even-more-doomed BeOS showed up to steal the geeks away. All the killer Amiga apps and vendors, inlcuding NewTek, have already gone elsewhere - there's probably more of a market for BeOS apps than Amiga apps right now.
So they're starting out with no hardware, no support for commodity hardware, no user base, no apps, claim to be doing a scratch implementation, and given that QNX couldn't get any interest in QNX (which blew away AmigaOS) after Amiga failed to pay for the development of the consumer version... I can't see any killer capabilities coming. The only hope I can see for the latest rump of AmigaOS is for them to be maximally cynical and basically sell an emulation kit.
Menus at the top of the GUI, rather than the application window.
...
Brain-damaged limitation on the location of the window resize controls.
Those misfeatures were copied from the original Mac.
Task bar/dock.
That was not part of Intuition.
Drive icons.
Drag'n'drop,
That was copied from the original Mac.
Really usable command line interface.
That's been part of every UNIX system since before Commodore made computers.
BTW, anyone got a "stickies" (on-screen Post-It (tm)) equivalent for the Mac or Gnome?
That's not part of Intuition. And the first version of Stickies was written by Apple and shipped in System 7.5. It's now a dashboard widget, which makes it even more pointless than it was to begin with.
The only actual feature of the Amiga that you're looking for is "screens", and the only reason you needed multiple screens rather than just running windows in different modes was that the Copper wasn't fast enough to composite on a window-by-window basis... so they had it switch modes and bitmaps in the horizontal sync interval... which was bloody impressive at the time. Modern GPUs support 3d compositing on a surface-by-surface basis in real time, so you can get the effect of "screens" on a window-by-window basis without the CPU having to deal with it.
The Amiga user interface had two main advantages over its contemporaries.
(1) It was running on top of an actual operating system. This wasn't a user interface feature, but it did make it possible to do things on the Amiga that MacOS and Windows and TOS couldn't dream of.
(2) In addition, the widgets in the UI were implemented in Intuition itself, rather than via callbacks or in the application message loop, so it didn't freeze when an application quit responding.
That second feature is about all I'd like to bring forward from the Amiga into a modern OS, since it's unlikely they'll actually have a real-time kernel... if they wanted that they'd pay QNX what they owed, pay whatever it took to make them happy, and then pay them more for an Amiga-branded port of Photon and QNX. Because, frankly, there's not much else that's got a chance of making an Amiga OS that's anything but a money sink.
#0 Take a generic Linux or BSD kernel and build an Amiga-branded distro, include UAE for compatibility, and call it Amiga System 5.
I just lined that map up with NASA's city lights map, and the correspondence is awfully close, allowing for the low resolution of the internet map: connectivity does seem to be "as common as electric power".