So let's say a tourist brings some CDs with them to Antigua and someone there copies them, then more copies are made for people in Antigua.
You didn't understand the bloke you're responding to.
If these copies were part of the 3.5 billion in question, then they would need to be accounted for. We're not talking about them becoming some kind of IP free trade zone, we're talking about them being able to get the 3.5 billion judgement by selling 3.5 billion dollars worth of US-owned intellectual property.
Are you crazy? Do you honestly think that Microsoft would deliberately force an entire country to switch to Linux? Microsoft will happily bend over backwards to keep Windows on desktops any time anyone with a high profile actually suggests such a thing.
Not to mention that in the long term turfing Windows would be a huge benefit for them.
Linux has had very *fast* file systems, but it hasn't really had very *reliable* file systems. The traditional BSD file system still wins there, and since the introduction of Softupdates it's not been far behind the bleeding edge in performance for typical use.
It's a substitute library that handles the win32 calls so in theory it can be faster than Windows itself
That's still emulation. FreeBSD's Linux and SCO emulation works that way, handling the system calls directly. Meanwhile both VMware and Parallels include specialized drivers and libraries that bypass the hardware emulation when possible. The difference is not so great as you imply.
In theory, yes, WINE could be faster.
But the difference between theory and practice in practice is greater than the difference between theory and pracice in theory.
It's not a reaction engine, so it's not a rocket. It's an expansion engine... the same basic principle as any gasoline or steam engine, with the working fluid being steam generated from internal combustion.
Since they're running under Windows emulation anyway, I reckon that within 6 months it'll be faster under VMware or Parallels than under their cobbled together WINE derivative.
DPS is a perfect example of what I was referring to, and NeWS is an even better on. Postscript integrated with web pages would have given us the capabilities AJAX provides years earlier, without the problems inherent in the way PDF is designed. PDF barely touches the surface of the capabilities of Postscript, even DPS ignores most of what it can do. Using Postscript as an interchange format or layout created by another program is like using HTML to display images by building tables of one-pixel cells set to appropriate colors... yes, you can do it, but other tools are better and you're throwing away most of the advantages of the language.
PDF wastes the abilities of Postscript, and does a bad job of presenting at least 90% of the pages distributed that way.
I think that depends on the creator - when it comes to long texts that needs a special layout, PDF can work great.
That's true, there's a lot of material that is not well adapted to HTML. At the moment that means creating a print-quality document and distributing it over the web, and PDF is a decent format for that.
In the context of "being a web page", though, PDF fails badly, and the vast majority of documents distributed in PDF (most of which are not academic papers, they're basically advertising) should be HTML.
Yes, you see PDF everywhere, but in virtually every case it's just another downloaded document format. Yes, you *can* view PDF in your browser, but you don't actually get any particular benefit from doing it that way no matter what Adobe seems to think: the fraction of PDFs that contain hyperlinks is negligible, and Adobe's embedded reader is balky and unreliable by comparison with the standalone one. And PDFs are inherently harder to read... the print-quality rendering and page orientation means that the text can not be adapted to the viewer. I recall one of Adobe's early ads for PDF, pushing Postscript as a web technology: they had the same page rendered in Postscript and HTML, and the HTML version had been rendered with deliberately odd browser settings... the Postscript version looked much nicer at first glance.
But even in a print ad, with magazine quality rendering, the Postscript version was completely unreadable and the HTML version was totally legible. As an ad for PDF it showed exactly why PDF isn't an appropriate web technology.
This is not, by the way, an inherent shortcoming of Postscript. It's possible to write Postscript code that does its own layout and adapts to the page dimensions and resolution, but no tools generate Postscript like that because the results don't look as good on paper. Perhaps if the Web had early support for Postscript in browsers it would be used that way by now, and used for scripting instead of Javascript, but that didn't happen.
Regardless of what might have been, PDF is not really relevant to the web today, except as a shining example of how not to create content.
When I've spoken to people at microsoft, about zero percent have been drones. They're all smart. The problem is the culture there is all about protecting the crown jewels... not about producing the best product. I saw that over and over in the Pocket PC... they crippled it to keep it from potentially competing with the Tablet PC, and to keep it as an annex to your *real* computer.
So whatever they do with virtualization, they won't change the basic OS radically the way Apple did, because once you make the jump to using a virtual machine for your applications there's nothing keeping you in Windows any more.
I really don't think there's any question but that giving people more control over their set-top scares the cable companies. And putting it in a computer gives up too much control...
How else is firefox supposed to handle protocols liek mailto on a Windows system?
Using the URI bindings provided for *untrusted* objects. Just like it would use the MIME type bindings for untrusted objects.
The problem is that the URI's shouldn't have been trusted in the first place.
Certainly not the ones that browsers use.
The problem is not limited to URIs. There are also plugins, file-type mappings, MIME-type mappings, and so on. Most of these, no matter what type of binding they are, have nothing to do with browsers. The mistake that Microsoft and Apple made was saying "these types of mappings are used by browsers, and these types aren't". Microsoft draws the line at plugins... browsers can execute any ActiveX plugin in the system, and quite a few more, unless they explicitly exclude them. Apple draws the line at file type mappings for downloaded files... browsers will by default open "safe" files, regardless of what the bindings for them are.
You're just drawing another line along the same axis. The problem is, that's the wrong axis.
Files, binding types (URi vs plugin vs MIME type), URI types, and so on, are not "safe" or "unsafe".
It's the *handlers* that are safe (they either implement a sandbox or do not have mechanisms to do dangerous things) or unsafe (they have the ability to do dangerous things). The syntax (URI, path, COM API, what have you) is an implementation detail... if the application is designed securely and uses the API for that binding type securely... it doesn't matter which way the binding was implemented. If the application isn't designed securely or is sloppy about the binding, you're owned no matter how it gets invoked. There will always be applications you can safely open from the shell to view or operate on files that you must never expose to a browser.
And MOST applications fall into that category.
MOST applications are not sandboxed or secure. Not only is that hard to do for non-trivial apps, but MANY of them can not be, because it's their job to do dangerous things. It's up to the application to register as a shell application (to be used by applications for references that the use or application is in control of), or a browser application (to be used for untrusted objects). When the OS has no way to distinguish between the two, you lose.
This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.
IE, this is a "shell" URI that should not be visible to non-trusted content *at all*.
There need to be separate registries for this.
OS X has the same problem, though at least there it doesn't include any equivalent to ActiveX, and the KHTML-based API makes it easier to implement a fix.
Griesi said that he does not see any of these URI issues as something that needs to be fixed in Windows or Internet Explorer. That's up to the individual software developers whose programs may be misused. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."
100% wrong. Microsoft doesn't provide a mechanism for applications to create both secure URI handlers for browsers as well as shell URIs for internal use. If they did, if they had a way to register components (URI handlers, file type handlers, Plugins, ActiveX controls, and so on) for use by shells (eg, Windows Explorer) only, or for use by browsers only, then we would have seen significantly fewer exploits on Windows over the past decade.
This is harder for Microsoft to fix than for Apple to fix, because in Windows the HTML control is the gatekeeper... not the application. Apple hasn't integrated Webcore as far as IE, and since Webcore is based on KHTML it's using the inherently secure IO Slave model rather than leaving it up to the HTML display engine to try and guess what plugins should be allowed.
The articles on my site are primarily about Apple, mostly because Microsoft has similar vulnerabilities discovered at far too great a rate for me to keep up. There was a patch for another one (an ActiveX component used by other programs not being explicitly blocked by the HTML control) on Tuesday.
I've been talking about this kind of problem in Windows and the HTML control since the late '90s, and in OSX and LaunchServices since 2004. It's worse in Windows, because you have the same stupid lack of security design in ActiveX which is a much harder nut to crack...
The problem is that there's no way on Windows or OSX to register a protocol handler for shell programs (Finder, Windows Explorer, the KDE file manager) or applications internal use (help: on both Windows and OSX) without it also being available to the web browsers. This means that any application that isn't designed to deal with untrusted input that the browser developer hasn't yet explicitly blocked is a point of entry.
Exploits using this approach have been found via IE since 1997, and via Safari since 2004.
It's not just free software that loses. Commercial software does as well... if it's not the market leader.
That's because of the application barrier to entry, the ecosystem effect, whatever you want to call it. Software naturally tends towards everyone needing to use compatible software, and once one company gets to control what's "compatible" they actually benefit from piracy.
That seems to be a more complete version, but googling for that I've found it attributed to Alan Shepard, Michael Collins, John Glenn, John Glenn quoting Alan Shepard, and a NASA tour guide named Mary Glenn quoting Shepard... which could have been the source of the John Glenn reference because the paragraph with the quote only contains her last name.
Ah yes, a character in a film released in 1998 is the source to a quote made in the early '60s.:)
If you have a time machine, I'd like to go back and pick up some stuff I left back in Australia before my parents got rid of it when they moved, and the Apple II Forth code that I lost when someone stole my backpack. Thanks much!
Slashdot Mirror
So let's say a tourist brings some CDs with them to Antigua and someone there copies them, then more copies are made for people in Antigua.
You didn't understand the bloke you're responding to.
If these copies were part of the 3.5 billion in question, then they would need to be accounted for. We're not talking about them becoming some kind of IP free trade zone, we're talking about them being able to get the 3.5 billion judgement by selling 3.5 billion dollars worth of US-owned intellectual property.
Are you crazy? Do you honestly think that Microsoft would deliberately force an entire country to switch to Linux? Microsoft will happily bend over backwards to keep Windows on desktops any time anyone with a high profile actually suggests such a thing.
Not to mention that in the long term turfing Windows would be a huge benefit for them.
Linux has had very *fast* file systems, but it hasn't really had very *reliable* file systems. The traditional BSD file system still wins there, and since the introduction of Softupdates it's not been far behind the bleeding edge in performance for typical use.
It's a substitute library that handles the win32 calls so in theory it can be faster than Windows itself
That's still emulation. FreeBSD's Linux and SCO emulation works that way, handling the system calls directly. Meanwhile both VMware and Parallels include specialized drivers and libraries that bypass the hardware emulation when possible. The difference is not so great as you imply.
In theory, yes, WINE could be faster.
But the difference between theory and practice in practice is greater than the difference between theory and pracice in theory.
It's not a reaction engine, so it's not a rocket. It's an expansion engine... the same basic principle as any gasoline or steam engine, with the working fluid being steam generated from internal combustion.
Since they're running under Windows emulation anyway, I reckon that within 6 months it'll be faster under VMware or Parallels than under their cobbled together WINE derivative.
The fraction of PDFs that are academic papers in computer science are negligible. :)
:(
Most are advertising fliers, real or disguised.
DPS is a perfect example of what I was referring to, and NeWS is an even better on. Postscript integrated with web pages would have given us the capabilities AJAX provides years earlier, without the problems inherent in the way PDF is designed. PDF barely touches the surface of the capabilities of Postscript, even DPS ignores most of what it can do. Using Postscript as an interchange format or layout created by another program is like using HTML to display images by building tables of one-pixel cells set to appropriate colors... yes, you can do it, but other tools are better and you're throwing away most of the advantages of the language.
PDF wastes the abilities of Postscript, and does a bad job of presenting at least 90% of the pages distributed that way.
I think that depends on the creator - when it comes to long texts that needs a special layout, PDF can work great.
That's true, there's a lot of material that is not well adapted to HTML. At the moment that means creating a print-quality document and distributing it over the web, and PDF is a decent format for that.
In the context of "being a web page", though, PDF fails badly, and the vast majority of documents distributed in PDF (most of which are not academic papers, they're basically advertising) should be HTML.
First time I'd ever seen an SVG file was when I clicked your link.
First time that you know of, anyway.
Yes, you see PDF everywhere, but in virtually every case it's just another downloaded document format. Yes, you *can* view PDF in your browser, but you don't actually get any particular benefit from doing it that way no matter what Adobe seems to think: the fraction of PDFs that contain hyperlinks is negligible, and Adobe's embedded reader is balky and unreliable by comparison with the standalone one. And PDFs are inherently harder to read... the print-quality rendering and page orientation means that the text can not be adapted to the viewer. I recall one of Adobe's early ads for PDF, pushing Postscript as a web technology: they had the same page rendered in Postscript and HTML, and the HTML version had been rendered with deliberately odd browser settings... the Postscript version looked much nicer at first glance.
But even in a print ad, with magazine quality rendering, the Postscript version was completely unreadable and the HTML version was totally legible. As an ad for PDF it showed exactly why PDF isn't an appropriate web technology.
This is not, by the way, an inherent shortcoming of Postscript. It's possible to write Postscript code that does its own layout and adapts to the page dimensions and resolution, but no tools generate Postscript like that because the results don't look as good on paper. Perhaps if the Web had early support for Postscript in browsers it would be used that way by now, and used for scripting instead of Javascript, but that didn't happen.
Regardless of what might have been, PDF is not really relevant to the web today, except as a shining example of how not to create content.
When I've spoken to people at microsoft, about zero percent have been drones. They're all smart. The problem is the culture there is all about protecting the crown jewels... not about producing the best product. I saw that over and over in the Pocket PC... they crippled it to keep it from potentially competing with the Tablet PC, and to keep it as an annex to your *real* computer.
So whatever they do with virtualization, they won't change the basic OS radically the way Apple did, because once you make the jump to using a virtual machine for your applications there's nothing keeping you in Windows any more.
If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
So if it's linked to Microsoft's own runtime, then that runtime has to be distributed under a compatible license?
I really don't think there's any question but that giving people more control over their set-top scares the cable companies. And putting it in a computer gives up too much control...
How else is firefox supposed to handle protocols liek mailto on a Windows system?
Using the URI bindings provided for *untrusted* objects. Just like it would use the MIME type bindings for untrusted objects.
The problem is that the URI's shouldn't have been trusted in the first place.
Certainly not the ones that browsers use.
The problem is not limited to URIs. There are also plugins, file-type mappings, MIME-type mappings, and so on. Most of these, no matter what type of binding they are, have nothing to do with browsers. The mistake that Microsoft and Apple made was saying "these types of mappings are used by browsers, and these types aren't". Microsoft draws the line at plugins... browsers can execute any ActiveX plugin in the system, and quite a few more, unless they explicitly exclude them. Apple draws the line at file type mappings for downloaded files... browsers will by default open "safe" files, regardless of what the bindings for them are.
You're just drawing another line along the same axis. The problem is, that's the wrong axis.
Files, binding types (URi vs plugin vs MIME type), URI types, and so on, are not "safe" or "unsafe".
It's the *handlers* that are safe (they either implement a sandbox or do not have mechanisms to do dangerous things) or unsafe (they have the ability to do dangerous things). The syntax (URI, path, COM API, what have you) is an implementation detail... if the application is designed securely and uses the API for that binding type securely... it doesn't matter which way the binding was implemented. If the application isn't designed securely or is sloppy about the binding, you're owned no matter how it gets invoked. There will always be applications you can safely open from the shell to view or operate on files that you must never expose to a browser.
And MOST applications fall into that category.
MOST applications are not sandboxed or secure. Not only is that hard to do for non-trivial apps, but MANY of them can not be, because it's their job to do dangerous things. It's up to the application to register as a shell application (to be used by applications for references that the use or application is in control of), or a browser application (to be used for untrusted objects). When the OS has no way to distinguish between the two, you lose.
This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.
IE, this is a "shell" URI that should not be visible to non-trusted content *at all*.
There need to be separate registries for this.
OS X has the same problem, though at least there it doesn't include any equivalent to ActiveX, and the KHTML-based API makes it easier to implement a fix.
http://www.scarydevil.com/~peter/io/apple.html
Griesi said that he does not see any of these URI issues as something that needs to be fixed in Windows or Internet Explorer. That's up to the individual software developers whose programs may be misused. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."
100% wrong. Microsoft doesn't provide a mechanism for applications to create both secure URI handlers for browsers as well as shell URIs for internal use. If they did, if they had a way to register components (URI handlers, file type handlers, Plugins, ActiveX controls, and so on) for use by shells (eg, Windows Explorer) only, or for use by browsers only, then we would have seen significantly fewer exploits on Windows over the past decade.
This is harder for Microsoft to fix than for Apple to fix, because in Windows the HTML control is the gatekeeper... not the application. Apple hasn't integrated Webcore as far as IE, and since Webcore is based on KHTML it's using the inherently secure IO Slave model rather than leaving it up to the HTML display engine to try and guess what plugins should be allowed.
But it DOES need to be fixed on both platforms.
The articles on my site are primarily about Apple, mostly because Microsoft has similar vulnerabilities discovered at far too great a rate for me to keep up. There was a patch for another one (an ActiveX component used by other programs not being explicitly blocked by the HTML control) on Tuesday.
I've been talking about this kind of problem in Windows and the HTML control since the late '90s, and in OSX and LaunchServices since 2004. It's worse in Windows, because you have the same stupid lack of security design in ActiveX which is a much harder nut to crack...
...
http://www.scarydevil.com/~peter/io/apple.html and later posts in http://www.scarydevil.com/~peter/io/
The problem is that there's no way on Windows or OSX to register a protocol handler for shell programs (Finder, Windows Explorer, the KDE file manager) or applications internal use (help: on both Windows and OSX) without it also being available to the web browsers. This means that any application that isn't designed to deal with untrusted input that the browser developer hasn't yet explicitly blocked is a point of entry.
Exploits using this approach have been found via IE since 1997, and via Safari since 2004.
It's not just free software that loses. Commercial software does as well... if it's not the market leader.
That's because of the application barrier to entry, the ecosystem effect, whatever you want to call it. Software naturally tends towards everyone needing to use compatible software, and once one company gets to control what's "compatible" they actually benefit from piracy.
(insert LOLCAT here)
Microsoft's APIs are an ecosystem all right. One of those toxic post-apocalyptic ones with tentacles reaching out of swamps to strangle passers-by.
That seems to be a more complete version, but googling for that I've found it attributed to Alan Shepard, Michael Collins, John Glenn, John Glenn quoting Alan Shepard, and a NASA tour guide named Mary Glenn quoting Shepard... which could have been the source of the John Glenn reference because the paragraph with the quote only contains her last name.
Where are you quoting from?
Ah yes, a character in a film released in 1998 is the source to a quote made in the early '60s. :)
If you have a time machine, I'd like to go back and pick up some stuff I left back in Australia before my parents got rid of it when they moved, and the Apple II Forth code that I lost when someone stole my backpack. Thanks much!
If you can come up with a computer technology related story set in China I bet they'll post it.
Like the recent one about the surveillance state they're setting up.