...as a taxpayer, i don't think it's fair that i'm already paying for your child's education, and now i must also pay to motivate them to receive it. the burden of motivation should land completely on the parents.
So you think it's fair that children who happen to be born to less motivational parents should have less opportunity in life? Or that kids born to parents who can afford to financially motivate them (and this is a very common technique) should have a better start in life? By the same token do you think it's fair that some people should be born into nobility and have greater legal rights as well?
Are you sure that DOC and XLS files are a good format? I've certainly run into compatibility problems over the years.
Anyone who has run document management for a significant time has probably run into this. "Sure sure, we have all those files archived and backed up, legal can have them to prove our ownership." This is then followed by the sickening discovery that half the archived.doc files won't open in any halfway recent version of Word. If you find yourself here, try OpenOffice, it works for another chunk of them. Then comes the fun of going on Ebay to buy an old copy of Windows 3.1 and an old copy of Word and and a floppy drive and getting the bloody thing to run in a VM.
The experience hammered into my head the importance of actual published standards for archive file types and preferably for all the file types we use.
It's OK if harming Windows is a side-effect of delivering a quality product, but if it is the "point", something is wrong.
If one accepts the premise that lack of real progress in OS development is caused by the Windows monopoly and one allows that such lack makes apps less functional, then harming the Windows monopoly can very well not only incidental to better apps, but a method to achieve better apps. So that point of view follows a very real logical progression, even if you do not agree with the initial premises.
I'm not going to comment on your whole list, but doing things like sharing a spell checker have been possible on Windows for at least 15 years.
Where did I claim it wasn't? What I claimed was that coding a spell checker to work with multiple applications you develop and to share library information (including that from users) between them is more difficult on Windows than with Web based applications. Thus either you completely misunderstood me or you're making a strawman argument.
Show me a web based game that uses the same code to run on iPhones, PCs, and PSPs and I'll show you a game that sucks.
Show me a web based game that uses the same code to run on iPhones, PCs, and PSPs and I'll show you a game that sucks.
Mostly that is the case, but that's the point of these enhancements. No one said hardware accelerated HTML5 was today a good platform for creating quality, cross-platform apps. If it was, these sorts of improvements would not be needed or useful. That's why people are working on these improvements, so you can run a quality application on any platform you want without three different dev trees.
"The point of turning the web into an application platform is that Windows is suddenly rendered completely irrelevant."
Perhaps web apps would be more successful if the point was providing the user with a superior tool.
You make it sound as if the two were mutually exclusive, but one may well lead to the other. Windows has been a significant limitation for application developers since it gained dominance. Do you develop two apps and want them to share the same spell checker including libraries? It's easier to do that via Web apps than it is to do it on Windows. Ditto for grammar checking. Want your apps to run wherever your user wants instead of just on devices that have licensed Windows? Well that's an obvious one, but important to users. Want your users to automatically be able to access their data from multiple devices and stay in synch? Want your users to be able to collaborate and easily discover and connect to collaborators? Want to write a game and let people play it on iPhones, PCs, and PSPs? Want your app to run without a complex install process? Want your app to stay updated for security reasons? Both tasks are again easier for Web apps. Want to allow users to migrate your installed and licensed application from their old computer to their new one? Again, Web apps are easier.
Windows provides a lot of limitations and pitfalls for developers. The Web is a platform that is standardized enough that sometimes those problems go away... and people are working hard to make it moreso.
Rendering speed is rarely the bottleneck. Slow response from ad networks on ad-heavy pages is a more common bottleneck.
Rendering speed is rarely a bottleneck for Slashdot users who tend to have much better hardware than average. Of course that is because Web app developers need to create apps that target mediocre hardware and bandwidth limitations. Mind you, bandwidth i still probably a bigger bottleneck today, but both are significant. Thats Why Google is spending billion creating a faster browser while at the same time rolling out fiber to the home projects.
Pixlr [pixlr.com], the browser-based image editor
I was under the impression that Pixlr used Flash for display and uploading, but relied primarily on server side processing. I haven't looked into their API a lot, but I thought that's why they were implementing a FF plug-in.
If you want real 3D hardware acceleration in a browser, Shockwave has had it for a decade.
True, but that's a proprietary technology, limited in platform support (Linux, iPhone, iPad, etc.) and it ties you to a single vendor, which is problematic in several ways. Open standard technologies seem to be the way forward here from security, cost, and performance perspectives.
There's Quake in Shockwave.
Yup and it's been around a while. More recently, however, we saw an HTML5 version of Quake as well, demonstrating this new direction.
If you need hardware graphics acceleration to implement a word processor or "social networking", something has been very badly designed.
Not really. It makes sense to take advantage of all the power sitting around to make things better for end users. I like word processors with good graphics capabilities that let me drag images anywhere I want in a document while dynamically flowing text around them. I prefer they use my GPU while they do it so my CPU is not maxed out while the GPU sits idle and performance suffers. I'm all for efficient code, but I'm not for artificial limitations to technology based on the idea that no one will ever need that because no one is using it now.
Many people have predicted the move toward either One Single Console To Rule Them All, or in this case none at all. The problem with this sort of prediction is that it does not account for the profitability of such systems.
Actually, I believe it does to some extent. Right now, most console makers profit primarily upon game licensing revenue. Nintendo makes some money on the hardware as well. So what happens when a company decides to undercut the existing players and just sell the hardware at a profit, while making game licensing as cheap as possible. We're looking at an iPhone store model here, where developers pay next to nothing and the hardware maker is content to profit on their own apps and the hardware profit. It's the profitability of the current model that will keep existing players from adapting fast enough, opening the way for the "one true console" maker to gain enough momentum to dominate the market. Once established, such dominance is hard to shake.
I'm actually surprised none of the major TV makers have gone this route, providing a built in console for little added cost, perhaps even opening up the spec to competitors, just as a way to get a head start and grab some more market share. Apple is certainly considering such a market, although they might have too much going right now to do it.
With the exception of chat, email, and slashdot, I've missed them purposely. I see no point in a web based word processor or image editor, as there's no way one would be superior in any way at all and inferior in most metrics to having your files on your PC itself.
Actually, while Web apps are often inferior in many ways, they also have their advantages. For example, your word processor files are automatically in synch regardless of whether you're accessing them from your desktop, laptop, work desktop, phone, friend's system, the library computer, school lab, or fancy new iPad. Second, Web apps can and often do have simpler and better collaboration ability. Getting a collaborative editor to connect across the Web and past firewalls and NAT can be an exercise in frustration in many environments, but everyone has Web access working.
I know I can access my disk based word processor, but there's no gurantee I can access a web based one.
Really? When your machine has a hardware failure just before your presentation you can guarantee access to the files on it? Compared to a Web app where you can grab the backup laptop at work or borrow a colleague's machine and still have access. Both methodologies have a trade off.
Note, I'm not saying Web apps are better in most circumstances. It all depends upon your use cases and the apps in question. What I'm saying is that both local and Web apps have strengths. If they don't fit with your use cases, I certainly don't think you should use them. Just don't expect everyone else to be like you.
This is actually a fairly clever move on the part of MS. A lot of GPUs in use today are more optimized for DirectX than OpenGL. DirectX is a Windows only technology owned by MS. IE is about the only Windows only browser out there. So if Firefox, Chrome and Safari are planning on implementing GPU acceleration they have to implement either both Direct2D and an open alternative for Linux and OS X (OpenCL?) or they risk lagging on performance based upon MS's leverage with graphics card manufacturers via hardware and driver optimization. Further, MS can contrive tests that show for some use cases IE9 is faster than whatever browser on OS X or Linux.
I've never understood this 'my browser is faster than your browser' attention. Most people use their browser over the Internet, with download speeds that make any computer wait.
So you've completely missed the advent of Web applications? Little Web based games, chat, e-mail, social networking, word processing, image editing, and hundreds of other incredibly popular Web technologies are currently limited by the rendering speed as often as by bandwidth. People will wait for a Web app to load, but that doesn't mean they're okay with waiting for it to respond when they do something in it.
If you just use your computer to edit text, then the same could probably be said about OS's and computer hardware. Why bother improving their graphics capabilities? Of course to do so you have to willfully ignore how they are used by normal people today and the direction they have been developing. They don't develop things just for you.
Why do people keep using idioms which don't mean anything in the modern language any more?
By definition, no idiom's meaning is apparent in modern language. Unless you don't know what a gauntlet is, this idiom is no different than any other. They are used because they are colorful and make our language more interesting.
Why would you give a PDF reader the ability to modify or delete files on the disk? If you're running it in a virtual machine that's designed for security, I'd think that would be one of the things that would be prevented. Have it think of the disk as a really fast CD.
While I agree that seems a reasonable configuration provided it is easy for the user to get around (For PDF forms and PDFs I want to annotate), I don't think that is a normal setup for Qubes, the technology we're discussing. Rather, it lets you copy and paste files between VMs, so the workflow would probably look more like, downloading them in one VM, then copying them to your PDF reader's VM. Normal users would probably delete them from the former to save space. Now if your PDF reader reacted badly to a PDF, it could probably (by default) still hose all the PDFs in that VM. The user could, in turn, roll back the VM, provided the state before that was still saved.
In a perfect world, each app should be segregated and limited and access to read a file should have to be in response to one user action, and the ability to write to a file would have to result from another, with a sandbox monitored for integrity (whether and ACL, jail, or VM) blocking that action. We were not, however, discussing a perfect setup but what actually happens today using Qubes.
In general, do apps really need delete permission anyway? How about just giving them change permission. In other words, something like a local svn commit.
Agreed. And Qubes does provide the ability to revert an entire VM, so even if your PDFs were all deleted or corrupted, it should not be permanent if you catch it in time.
I think Macs come with something like that built in... the name escapes me.
Macs do have a nice, built in versioning called "Time Machine" but most users do not buy the required external drive to make use of it.
A document that's infected would still need to be opened, and thus presents a vector that needs to be scanned against.
If the PDF viewer is running in a separate VM container, however, what exactly do you think it's going to accomplish? Read your other PDFs? sure. Delete them even? Okay. But since you probably did not give that VM access to your network it's unlikely to be able to do anything actually beneficial to a malware writer.
Well, virus scanners are a bonus, although not a lot of use on Linux given the amount of malware out there. Configuration of VMs takes over a lot of the same task as application level firewalls here, although the overhead tradeoffs of each approach should be looked at.
Since it has been so obvious that companies are ruined when MS buys them (I've been hearing this for the past 10+ years), these small company owners clearly don't give a F*** about their artistic integrity.
Business owners care about profit primarily, not artistic integrity. Ever worked at a startup? It's not like there's a dozen artists and coders that run the company. Rather, those employees own a small share in it, while the investors own most and the board makes all the major decisions. Things like Google where the primary developers retain majority share while a company grows to any size are extreme edge cases.
But in a normal environment, it's okay because enlightened self interest drives better products because better products are decided by consumers in the market place. This breaks down when a monopolist or other huge company decides they need to use their money from other markets to alter the course of say the video game market, for strategic purposes related to long term plans in other markets. That is when suddenly the market starts hurting and companies making worse crap end up making more money, like really good games being crippled or killed because they threaten Windows market dominance in some way by promoting standards compliant APIs or cross platform development tools and practices.
I do wish people would remember that in this country at least, it takes two sides to make a business transaction - the buyer and the seller.
Sure it does, but one side has all the money and power that's not much comfort.
The whole refrain of "MS bought it and it's ruined", while containing a tiny kernel of truth, is ultimately based on flawed logic.
It's not based on logic at all. It's an observed phenomenon. Let's see Bungie has the next generation of their innovative products as playable demos on multiple platforms, then MS buys them and nothing is released for years then, what comes out only runs on Windows and has fewer features not only than the demoes they had shown but than the previous generation of those games. There's no logic being applied here, it's just what happened again and again.
If these companies really had more innovation to offer the world and they felt it could be profitable, they would not have sold out to MS.
Yeah, and if everyone would just be charitable and share food and housing and medical services with the poor there would be no need for social assistance programs. Too bad people predictably act in their own, selfish best interests most of the time so we need that and we need a fairly free and competitive marketplace to harness that self interest and turn it into innovation.
Re:iChat? Really? What about multi-tasking?
on
iPad Review
·
· Score: 3, Informative
Does gmail chat/facebook chat not work in the iPad browser? If it does, this is probably better for most than some proprietary chat client. Quite frankly, I'm inclined to place the unavailability of multi-task greater than iChat.
But what about when you want to quickly use some other app? Then you have to close your chat. It's things like this that demand multitasking.
Okay, let me provide a little clarification. The OS multitasks. Third party apps don't, because Apple has not provided an API. They have provided a push messaging API, however, so the OS can get a notification and flag a chat client so you know you have a new message, which will appear as soon as you switch back to the chat client. This is pretty much the same as Blackberry's push notification, except third parties use it, instead of just RIM. This is the right way to handle resource allocation and push notifications on devices with limited resources, limited bandwidth, and where UI responsiveness is important. So multitasking is not really related to the feasibility of implementing chat. Even if it was, that limitation has never applied to apps pre-installed by Apple.
As a side note, Apple is demoing the next version of the iPhone OS to developers on Thursday. The new version (by almost all accounts) provides third party apps the ability to run in the background, but it is questionable that Apple will accept a chat client app submission that does not use the push notification in any case.
Umm, generally middle age refers to a period of a person's life, not a point in time. The US census bureau considers middle age to be 35-54, so claiming a company is becoming "middle aged" when it is 35 is not really all that unusual or outside of the normal use of the phrase.
Toes are being stepped on, to be sure, but I just don't see Microsoft and Apple as being on a collision course for the most part. Given the conservative nature of the corporate market, what's much more likely is that Apple will end up as the dominant home player, at least for a while, and Microsoft will follow IBM into being solely a corporate player.
I see it a little differently. Apple is not targeting the corporate market, but others are and Apple is enabling those others to be successful. MS makes a lot of money, but their business strategy is based upon locking people in and being dominant. If they lose the lock-in or the dominance, they will lose ground very, very quickly to other players, including Apple unless MS can adapt and completely turn around their own ossified corporate culture.
Both Microsoft and Apple are big enough that they can make large bets on new technology and ideas and have them fail. You are right that other companies flame out when they make a large bet and it doesn't work out, but that doesn't apply here.
If the iPad were a complete flop and nobody bought it, that wouldn't kill apple. It wouldn't even cripple them. It would represent a large waste of time and capitol, but the company would go on doing what it does. that is the advantage of being a big company.
Hmm, I'm going to have to disagree in general. While you're right about the iPad, that is not reflective of past Apple's gambles. Buying Next and putting Jobs back in charge, for example, could have killed Apple. Betting big on all in one machines and laptops , when those were both niche markets could have killed the company. Licensing OS 9 to other hardware makers nearly did kill them, and buying out and abandoning that strategy could have done the same if it had not worked (not that they had anything to lose). The iPod started out slow and cautious, so was not an issue. The iPhone, well it would not have killed Apple, but it would have hurt them a lot, since the basically shunted all their best talent into making it while letting other products languish.
MS, on the other hand, has bet big a few times, like betting that they could influence courts enough to prevent being broken up after blatantly and repeatedly violating antitrust law.
Age of Empires series - developed by Ensemble Studios and which withered after MS's acquisition,
Halo - developed by Bungie, another company that made awesome products until MS bought them.
Train Simulator - developed by Kuju Entertainment and licensed to MS.
MechWarrior - developed by Dynamix, is this owned by MS now?
Links - developed by Access Software, again bought by MS afterwards.
Midtown Madness - Developed by Angel studios, part of Rockstar, later bought by Take2. I don't think this is owned by MS though.
Motocross Madness - developed by THQ, part of Rainbow, not MS.
You've put together a lovely homage to MS's buying out and ruining of good game companies since every good game you came up with was developed by a company that MS bought out after they made something good, or which you thought was made by MS but was actually not. More than half the companies no longer exist having been mothballed by MS.
While details are hard to come by I think this may run deeper than pdf.
Clearly security issues go beyond this single flaw in PDF and to some of the primary assumptions of OS's in mainstream computing.
The whole idea of "opening a file in a way determined by the OS for that type of file" is poor from a security point of view.
I disagree. That is to say, can't think of any better way. The OS determining what to use makes for a smaller exposure to exploitation because an attacker cannot specify or know what will be used to open a particular data type in most instances.
Opening a file can mean anything from viewing an image in an image viewer (safe unless there is a bug in the image viewer) through opening something like an office document (may or may not be safe depending on office security settings) though to running an executable (unsafe by design).
You provide three examples, but all three could be made quite safe if OS's were designed to do that. Sandbox every application and give it access to only what it needs. Monitor the integrity of the sandbox. In my opinion an average user should be able to run a random.exe file from an unknown, untrusted source and the OS should appropriately restrict that executable to prevent harm. That's not to say the user should not be able to override the OS's decision, but only when made aware of exactly what the executable is trying to do and being given the choice of doing it in a safe environment instead.
Heck, I can do it today. Send me a random.exe file and I can put it into one of my premade windows VMs, run it, only granting explicit access to my real data as needed, and reverting the VM back to it's original state or saving it as a one-off for using that executable. The problem is, this task is far too difficult for the normal user. The whole process could be streamlined and automatic though, if the market was responsive to the needs of users.
Yes, that is the summary of what it does, but the spec I'm read ing (1.5) says it is to be implemented via a URI, not call a specific application. That is to say, hand the URI for a.exe file to the OS and let it decide what is registered to open it. The spec lists the variable type as "File" which in turn requires URI and a file location.The only option listed is a new window or not a new window. So if they implemented "Launch" to launch a specific application, it looks like a violation of the spec, or at very least something not included in the spec.
Of course if Adobe goes beyond the spec it is easy to see why sometimes third parties copy them for compatibility.
Are you sure that's how he does it? He apparently has a better proof-of-concept that he hasn't posted, only sent to Adobe.
That certainly seems to be the basis for his attack based upon the data and samples he's presented. It's not the first time this particular part of the spec has been a security problem either.
He says that it works in other PDF Readers (well he mentioned one, Foxit) - because he's not exploiting a vulnerability in any of the applications, but the PDF Language itself.
Technically, I think he's exploiting a common way the spec is implemented. the "/launch" command is supposed to be to a PDF file or be handled as a URI action.
He implements a file including:
/Type/Action/S/Launch/Win/F (cmd.exe)
By my reading of the spec (which is admittedly not expert) the way things are being handled by the PDF reader are questionable and by the OS is stupid.
In my mind this is simply one more argument for default ACLs and sandboxing for all applications as an integral part of OS design..
Slashdot Mirror
...as a taxpayer, i don't think it's fair that i'm already paying for your child's education, and now i must also pay to motivate them to receive it. the burden of motivation should land completely on the parents.
So you think it's fair that children who happen to be born to less motivational parents should have less opportunity in life? Or that kids born to parents who can afford to financially motivate them (and this is a very common technique) should have a better start in life? By the same token do you think it's fair that some people should be born into nobility and have greater legal rights as well?
Are you sure that DOC and XLS files are a good format? I've certainly run into compatibility problems over the years.
Anyone who has run document management for a significant time has probably run into this. "Sure sure, we have all those files archived and backed up, legal can have them to prove our ownership." This is then followed by the sickening discovery that half the archived .doc files won't open in any halfway recent version of Word. If you find yourself here, try OpenOffice, it works for another chunk of them. Then comes the fun of going on Ebay to buy an old copy of Windows 3.1 and an old copy of Word and and a floppy drive and getting the bloody thing to run in a VM.
The experience hammered into my head the importance of actual published standards for archive file types and preferably for all the file types we use.
It's OK if harming Windows is a side-effect of delivering a quality product, but if it is the "point", something is wrong.
If one accepts the premise that lack of real progress in OS development is caused by the Windows monopoly and one allows that such lack makes apps less functional, then harming the Windows monopoly can very well not only incidental to better apps, but a method to achieve better apps. So that point of view follows a very real logical progression, even if you do not agree with the initial premises.
I'm not going to comment on your whole list, but doing things like sharing a spell checker have been possible on Windows for at least 15 years.
Where did I claim it wasn't? What I claimed was that coding a spell checker to work with multiple applications you develop and to share library information (including that from users) between them is more difficult on Windows than with Web based applications. Thus either you completely misunderstood me or you're making a strawman argument.
Show me a web based game that uses the same code to run on iPhones, PCs, and PSPs and I'll show you a game that sucks.
Show me a web based game that uses the same code to run on iPhones, PCs, and PSPs and I'll show you a game that sucks.
Mostly that is the case, but that's the point of these enhancements. No one said hardware accelerated HTML5 was today a good platform for creating quality, cross-platform apps. If it was, these sorts of improvements would not be needed or useful. That's why people are working on these improvements, so you can run a quality application on any platform you want without three different dev trees.
"The point of turning the web into an application platform is that Windows is suddenly rendered completely irrelevant."
Perhaps web apps would be more successful if the point was providing the user with a superior tool.
You make it sound as if the two were mutually exclusive, but one may well lead to the other. Windows has been a significant limitation for application developers since it gained dominance. Do you develop two apps and want them to share the same spell checker including libraries? It's easier to do that via Web apps than it is to do it on Windows. Ditto for grammar checking. Want your apps to run wherever your user wants instead of just on devices that have licensed Windows? Well that's an obvious one, but important to users. Want your users to automatically be able to access their data from multiple devices and stay in synch? Want your users to be able to collaborate and easily discover and connect to collaborators? Want to write a game and let people play it on iPhones, PCs, and PSPs? Want your app to run without a complex install process? Want your app to stay updated for security reasons? Both tasks are again easier for Web apps. Want to allow users to migrate your installed and licensed application from their old computer to their new one? Again, Web apps are easier.
Windows provides a lot of limitations and pitfalls for developers. The Web is a platform that is standardized enough that sometimes those problems go away... and people are working hard to make it moreso.
Rendering speed is rarely the bottleneck. Slow response from ad networks on ad-heavy pages is a more common bottleneck.
Rendering speed is rarely a bottleneck for Slashdot users who tend to have much better hardware than average. Of course that is because Web app developers need to create apps that target mediocre hardware and bandwidth limitations. Mind you, bandwidth i still probably a bigger bottleneck today, but both are significant. Thats Why Google is spending billion creating a faster browser while at the same time rolling out fiber to the home projects.
Pixlr [pixlr.com], the browser-based image editor
I was under the impression that Pixlr used Flash for display and uploading, but relied primarily on server side processing. I haven't looked into their API a lot, but I thought that's why they were implementing a FF plug-in.
If you want real 3D hardware acceleration in a browser, Shockwave has had it for a decade.
True, but that's a proprietary technology, limited in platform support (Linux, iPhone, iPad, etc.) and it ties you to a single vendor, which is problematic in several ways. Open standard technologies seem to be the way forward here from security, cost, and performance perspectives.
There's Quake in Shockwave.
Yup and it's been around a while. More recently, however, we saw an HTML5 version of Quake as well, demonstrating this new direction.
If you need hardware graphics acceleration to implement a word processor or "social networking", something has been very badly designed.
Not really. It makes sense to take advantage of all the power sitting around to make things better for end users. I like word processors with good graphics capabilities that let me drag images anywhere I want in a document while dynamically flowing text around them. I prefer they use my GPU while they do it so my CPU is not maxed out while the GPU sits idle and performance suffers. I'm all for efficient code, but I'm not for artificial limitations to technology based on the idea that no one will ever need that because no one is using it now.
Many people have predicted the move toward either One Single Console To Rule Them All, or in this case none at all. The problem with this sort of prediction is that it does not account for the profitability of such systems.
Actually, I believe it does to some extent. Right now, most console makers profit primarily upon game licensing revenue. Nintendo makes some money on the hardware as well. So what happens when a company decides to undercut the existing players and just sell the hardware at a profit, while making game licensing as cheap as possible. We're looking at an iPhone store model here, where developers pay next to nothing and the hardware maker is content to profit on their own apps and the hardware profit. It's the profitability of the current model that will keep existing players from adapting fast enough, opening the way for the "one true console" maker to gain enough momentum to dominate the market. Once established, such dominance is hard to shake.
I'm actually surprised none of the major TV makers have gone this route, providing a built in console for little added cost, perhaps even opening up the spec to competitors, just as a way to get a head start and grab some more market share. Apple is certainly considering such a market, although they might have too much going right now to do it.
With the exception of chat, email, and slashdot, I've missed them purposely. I see no point in a web based word processor or image editor, as there's no way one would be superior in any way at all and inferior in most metrics to having your files on your PC itself.
Actually, while Web apps are often inferior in many ways, they also have their advantages. For example, your word processor files are automatically in synch regardless of whether you're accessing them from your desktop, laptop, work desktop, phone, friend's system, the library computer, school lab, or fancy new iPad. Second, Web apps can and often do have simpler and better collaboration ability. Getting a collaborative editor to connect across the Web and past firewalls and NAT can be an exercise in frustration in many environments, but everyone has Web access working.
I know I can access my disk based word processor, but there's no gurantee I can access a web based one.
Really? When your machine has a hardware failure just before your presentation you can guarantee access to the files on it? Compared to a Web app where you can grab the backup laptop at work or borrow a colleague's machine and still have access. Both methodologies have a trade off.
Note, I'm not saying Web apps are better in most circumstances. It all depends upon your use cases and the apps in question. What I'm saying is that both local and Web apps have strengths. If they don't fit with your use cases, I certainly don't think you should use them. Just don't expect everyone else to be like you.
IE 9 gets 60 fps with hundreds of images...
That's funny, IE 9 won't even run on my version of OS X so it gets 0 fps. :)
This is actually a fairly clever move on the part of MS. A lot of GPUs in use today are more optimized for DirectX than OpenGL. DirectX is a Windows only technology owned by MS. IE is about the only Windows only browser out there. So if Firefox, Chrome and Safari are planning on implementing GPU acceleration they have to implement either both Direct2D and an open alternative for Linux and OS X (OpenCL?) or they risk lagging on performance based upon MS's leverage with graphics card manufacturers via hardware and driver optimization. Further, MS can contrive tests that show for some use cases IE9 is faster than whatever browser on OS X or Linux.
I've never understood this 'my browser is faster than your browser' attention. Most people use their browser over the Internet, with download speeds that make any computer wait.
So you've completely missed the advent of Web applications? Little Web based games, chat, e-mail, social networking, word processing, image editing, and hundreds of other incredibly popular Web technologies are currently limited by the rendering speed as often as by bandwidth. People will wait for a Web app to load, but that doesn't mean they're okay with waiting for it to respond when they do something in it.
If you just use your computer to edit text, then the same could probably be said about OS's and computer hardware. Why bother improving their graphics capabilities? Of course to do so you have to willfully ignore how they are used by normal people today and the direction they have been developing. They don't develop things just for you.
What about those of us who don't want to see flying-rotating-3d-semitransparent-glowing-shaded adverts flying across our web pages.
Just use Lynx.
Why do people keep using idioms which don't mean anything in the modern language any more?
By definition, no idiom's meaning is apparent in modern language. Unless you don't know what a gauntlet is, this idiom is no different than any other. They are used because they are colorful and make our language more interesting.
Why would you give a PDF reader the ability to modify or delete files on the disk? If you're running it in a virtual machine that's designed for security, I'd think that would be one of the things that would be prevented. Have it think of the disk as a really fast CD.
While I agree that seems a reasonable configuration provided it is easy for the user to get around (For PDF forms and PDFs I want to annotate), I don't think that is a normal setup for Qubes, the technology we're discussing. Rather, it lets you copy and paste files between VMs, so the workflow would probably look more like, downloading them in one VM, then copying them to your PDF reader's VM. Normal users would probably delete them from the former to save space. Now if your PDF reader reacted badly to a PDF, it could probably (by default) still hose all the PDFs in that VM. The user could, in turn, roll back the VM, provided the state before that was still saved.
In a perfect world, each app should be segregated and limited and access to read a file should have to be in response to one user action, and the ability to write to a file would have to result from another, with a sandbox monitored for integrity (whether and ACL, jail, or VM) blocking that action. We were not, however, discussing a perfect setup but what actually happens today using Qubes.
In general, do apps really need delete permission anyway? How about just giving them change permission. In other words, something like a local svn commit.
Agreed. And Qubes does provide the ability to revert an entire VM, so even if your PDFs were all deleted or corrupted, it should not be permanent if you catch it in time.
I think Macs come with something like that built in... the name escapes me.
Macs do have a nice, built in versioning called "Time Machine" but most users do not buy the required external drive to make use of it.
A document that's infected would still need to be opened, and thus presents a vector that needs to be scanned against.
If the PDF viewer is running in a separate VM container, however, what exactly do you think it's going to accomplish? Read your other PDFs? sure. Delete them even? Okay. But since you probably did not give that VM access to your network it's unlikely to be able to do anything actually beneficial to a malware writer.
...still necessitating virus scanners (and app firewalls).
Well, virus scanners are a bonus, although not a lot of use on Linux given the amount of malware out there. Configuration of VMs takes over a lot of the same task as application level firewalls here, although the overhead tradeoffs of each approach should be looked at.
Since it has been so obvious that companies are ruined when MS buys them (I've been hearing this for the past 10+ years), these small company owners clearly don't give a F*** about their artistic integrity.
Business owners care about profit primarily, not artistic integrity. Ever worked at a startup? It's not like there's a dozen artists and coders that run the company. Rather, those employees own a small share in it, while the investors own most and the board makes all the major decisions. Things like Google where the primary developers retain majority share while a company grows to any size are extreme edge cases.
But in a normal environment, it's okay because enlightened self interest drives better products because better products are decided by consumers in the market place. This breaks down when a monopolist or other huge company decides they need to use their money from other markets to alter the course of say the video game market, for strategic purposes related to long term plans in other markets. That is when suddenly the market starts hurting and companies making worse crap end up making more money, like really good games being crippled or killed because they threaten Windows market dominance in some way by promoting standards compliant APIs or cross platform development tools and practices.
I do wish people would remember that in this country at least, it takes two sides to make a business transaction - the buyer and the seller.
Sure it does, but one side has all the money and power that's not much comfort.
The whole refrain of "MS bought it and it's ruined", while containing a tiny kernel of truth, is ultimately based on flawed logic.
It's not based on logic at all. It's an observed phenomenon. Let's see Bungie has the next generation of their innovative products as playable demos on multiple platforms, then MS buys them and nothing is released for years then, what comes out only runs on Windows and has fewer features not only than the demoes they had shown but than the previous generation of those games. There's no logic being applied here, it's just what happened again and again.
If these companies really had more innovation to offer the world and they felt it could be profitable, they would not have sold out to MS.
Yeah, and if everyone would just be charitable and share food and housing and medical services with the poor there would be no need for social assistance programs. Too bad people predictably act in their own, selfish best interests most of the time so we need that and we need a fairly free and competitive marketplace to harness that self interest and turn it into innovation.
Does gmail chat/facebook chat not work in the iPad browser? If it does, this is probably better for most than some proprietary chat client. Quite frankly, I'm inclined to place the unavailability of multi-task greater than iChat.
But what about when you want to quickly use some other app? Then you have to close your chat. It's things like this that demand multitasking.
Okay, let me provide a little clarification. The OS multitasks. Third party apps don't, because Apple has not provided an API. They have provided a push messaging API, however, so the OS can get a notification and flag a chat client so you know you have a new message, which will appear as soon as you switch back to the chat client. This is pretty much the same as Blackberry's push notification, except third parties use it, instead of just RIM. This is the right way to handle resource allocation and push notifications on devices with limited resources, limited bandwidth, and where UI responsiveness is important. So multitasking is not really related to the feasibility of implementing chat. Even if it was, that limitation has never applied to apps pre-installed by Apple.
As a side note, Apple is demoing the next version of the iPhone OS to developers on Thursday. The new version (by almost all accounts) provides third party apps the ability to run in the background, but it is questionable that Apple will accept a chat client app submission that does not use the push notification in any case.
Umm, generally middle age refers to a period of a person's life, not a point in time. The US census bureau considers middle age to be 35-54, so claiming a company is becoming "middle aged" when it is 35 is not really all that unusual or outside of the normal use of the phrase.
Toes are being stepped on, to be sure, but I just don't see Microsoft and Apple as being on a collision course for the most part. Given the conservative nature of the corporate market, what's much more likely is that Apple will end up as the dominant home player, at least for a while, and Microsoft will follow IBM into being solely a corporate player.
I see it a little differently. Apple is not targeting the corporate market, but others are and Apple is enabling those others to be successful. MS makes a lot of money, but their business strategy is based upon locking people in and being dominant. If they lose the lock-in or the dominance, they will lose ground very, very quickly to other players, including Apple unless MS can adapt and completely turn around their own ossified corporate culture.
Both Microsoft and Apple are big enough that they can make large bets on new technology and ideas and have them fail. You are right that other companies flame out when they make a large bet and it doesn't work out, but that doesn't apply here. If the iPad were a complete flop and nobody bought it, that wouldn't kill apple. It wouldn't even cripple them. It would represent a large waste of time and capitol, but the company would go on doing what it does. that is the advantage of being a big company.
Hmm, I'm going to have to disagree in general. While you're right about the iPad, that is not reflective of past Apple's gambles. Buying Next and putting Jobs back in charge, for example, could have killed Apple. Betting big on all in one machines and laptops , when those were both niche markets could have killed the company. Licensing OS 9 to other hardware makers nearly did kill them, and buying out and abandoning that strategy could have done the same if it had not worked (not that they had anything to lose). The iPod started out slow and cautious, so was not an issue. The iPhone, well it would not have killed Apple, but it would have hurt them a lot, since the basically shunted all their best talent into making it while letting other products languish.
MS, on the other hand, has bet big a few times, like betting that they could influence courts enough to prevent being broken up after blatantly and repeatedly violating antitrust law.
Microsoft Games as:
You've put together a lovely homage to MS's buying out and ruining of good game companies since every good game you came up with was developed by a company that MS bought out after they made something good, or which you thought was made by MS but was actually not. More than half the companies no longer exist having been mothballed by MS.
While details are hard to come by I think this may run deeper than pdf.
Clearly security issues go beyond this single flaw in PDF and to some of the primary assumptions of OS's in mainstream computing.
The whole idea of "opening a file in a way determined by the OS for that type of file" is poor from a security point of view.
I disagree. That is to say, can't think of any better way. The OS determining what to use makes for a smaller exposure to exploitation because an attacker cannot specify or know what will be used to open a particular data type in most instances.
Opening a file can mean anything from viewing an image in an image viewer (safe unless there is a bug in the image viewer) through opening something like an office document (may or may not be safe depending on office security settings) though to running an executable (unsafe by design).
You provide three examples, but all three could be made quite safe if OS's were designed to do that. Sandbox every application and give it access to only what it needs. Monitor the integrity of the sandbox. In my opinion an average user should be able to run a random .exe file from an unknown, untrusted source and the OS should appropriately restrict that executable to prevent harm. That's not to say the user should not be able to override the OS's decision, but only when made aware of exactly what the executable is trying to do and being given the choice of doing it in a safe environment instead.
Heck, I can do it today. Send me a random .exe file and I can put it into one of my premade windows VMs, run it, only granting explicit access to my real data as needed, and reverting the VM back to it's original state or saving it as a one-off for using that executable. The problem is, this task is far too difficult for the normal user. The whole process could be streamlined and automatic though, if the market was responsive to the needs of users.
Yes, that is the summary of what it does, but the spec I'm read ing (1.5) says it is to be implemented via a URI, not call a specific application. That is to say, hand the URI for a .exe file to the OS and let it decide what is registered to open it. The spec lists the variable type as "File" which in turn requires URI and a file location.The only option listed is a new window or not a new window. So if they implemented "Launch" to launch a specific application, it looks like a violation of the spec, or at very least something not included in the spec.
Of course if Adobe goes beyond the spec it is easy to see why sometimes third parties copy them for compatibility.
Are you sure that's how he does it? He apparently has a better proof-of-concept that he hasn't posted, only sent to Adobe.
That certainly seems to be the basis for his attack based upon the data and samples he's presented. It's not the first time this particular part of the spec has been a security problem either.
He says that it works in other PDF Readers (well he mentioned one, Foxit) - because he's not exploiting a vulnerability in any of the applications, but the PDF Language itself.
Technically, I think he's exploiting a common way the spec is implemented. the "/launch" command is supposed to be to a PDF file or be handled as a URI action.
He implements a file including:
By my reading of the spec (which is admittedly not expert) the way things are being handled by the PDF reader are questionable and by the OS is stupid.
In my mind this is simply one more argument for default ACLs and sandboxing for all applications as an integral part of OS design..