I see you didn't even take the time to read the main page.
No. Guilty. Googled right to the download page.
Poking around in the user agent string, however, is a but much.
Frankly, back when I last tried it, in June or July, it was so far from ready for prime time that I didn't do much more than install it and play with it for a few minutes.
Yes, I assumed that they would be using the "K" name because they were using the KHTML engine.
That we had to wait for Safari on Windows to get a KHTML-based browser at all is appalling.
In any case, I think I should have said something more to the effect of "it's a pity that there isn't a decent lightweight browser for Windows using the native UI *at all*". Because, right now, there isn't. I don't know what the problem with Safari is... for me it started out nice and fast but bogged down very quickly. K-Meleon might be worthwhile with a year of polishing. Firefox 3 seems like an improvement, but it's still not native and I'm still concerned about XPI. There's a third party webkit browser but last I looked it was kind of stalled.
There doesn't seem to be anything out there for Windows, at all.
The fact that the XPI install is initiated from within the browser. This means it's necessary to provide a hole in the sandbox whereby an untrusted object can request privileges necessary to install an extension. Since this privilege is equivalent to full local user privileges, any exploits that could use this hole would be extremely serious. It is certainly possible that they have blocked all possible avenues of attack through this hole, but given that similar (albeit somewhat broader) holes in the Microsoft HTML sandbox have been responsible for the majority of exploits through IE, it seems poor design to even allow such a hole to exist.
The alternative design would simply download the extension like any other file, and leave it in the user's download directory and download manager. Then the user would, outside the untrusted object, explicitly request that the extension be installed. The operation of installing would, depending on the platform, include:
1. Opening the extension in the OS file manager, with the handler for that file type set to Firefox. 2. Right-clicking the Firefox download manager entry and selecting "install". 3. Selecting an "Install Extension" menu entry and navigating to the downloaded file.
By making the installation a separate step, explicitly requested by the user, you gain two advantages.
1. It is not necessary to provide a mechanism for a web page to request an operation that can grant them full local user privileges. This should be an obvious point, so I won't go into further detail.
2. Making the install a separate operation from the download means that the user is explicitly requesting it, and not just clicking on an approval dialog. The difference in these two user interface models is surprisingly large... in 20 years as a network and system administrator, and almost 10 years experience with Internet Explorer, I have only had one user (out of several hundred over that period) who was unable to learn not to download files and double click them after the first time they came to me with an infected computer. I have had many users come to me over and over again and say they clicked OK (or open, or "infect me now", or whatever the dialog of the week said) and their computer was acting funny. Because people get trained to approve dialogs, the dialog comes up and it's a reflex to click it.
Currently, XPI does make it fairly hard to open by accident. But to do this they have made the whole operation more complicated than just treating an XPI file with the same security model as an executable would. Instead of downloading it then (at your convenience) selecting "install", you have to whitelist the site (which takes several steps), then wait through a countdown, then click on an approval dialog.
A simpler design would be both more secure and more convenient. It's rare enough that you can say this of anything, no?
It's certainly possible to write applications that run in place (I don't like overriding the existing meaning of the term 'portable application' for this) for Windows, but Microsoft makes it hard. Apart from the registry issues, their shared libraries don't normally get tracked by the complete path name so if your application needs (and includes) a copy of a Windows library that may not be installed you really need to do something to make sure it GETS installed in %systemroot% unless there's a more recent one there. Portable applications really need to eschew those libraries, and they must avoid others because they expect the application to be using the registry. On top of that Microsoft, by default, hides the contents of "Program Files".
I disagree that configuration for the application should be restricted to the application directory. A versioned config file in your profile is more useful for the more typical case, because it allows you to run the application from read-only directories or media.
On traditional UNIX systems you can set up standalone applications a lot more easily, but they're not the default.
The Scheme NeXT came up with and that Apple continues to use in OS X makes standalone apps the default, and installers the exception. That's the real distinction.
Perhaps a weaker term than "necessary" is desirable, I suppose "inevitable" is better. Microsoft makes you bend over backwards to avoid them, Apple makes you appear a tad eccentric if you use them.
Before installing it, rename the existing application bundle to something different (e.g. "Firefox 2.0"), and then drag the other App bundle to the Applications folder.
That's another way to do it, yes.
I tend to install beta software in ~/Applications so that it doesn't impact other users on the same machine.
Apple would have to come out with an iPod touch or iPhone with a larger screen.
Only if they believed in the fantasy that you just need a good enough display and you'll finally get the eBook-reader market to take off.
It ain't so. What's keeping the eBook-reader market from "taking off" is that a dedicated reader with a big high-quality screen is completely irrelevant. There is no "eBook-reader market" at all. There's no demand for a digital device that's the size and shape of a book, for reading novels on. There's very little demand for any kind of expensive dedicated devices, for that matter. What categories have really taken off?
Cameras. Music players. Cellphones. Handheld games. GPS/mapping devices. PDAs. General purpose handhelds. Combinations of the above.
And all the successful ones are small enough to easily fit in a pocket or a purse. Bigger handhelds, like the Newton and notebook replacement devices, are gone. I can't imagine any device that's bigger than something like an iPaq getting much traction.
And once you remove the big screen, why should your eBook reader be a separate device? Books don't take up much space, and you don't need to store that many... the 8M in my Clie is plenty big enough for more books than I can comfortably scroll through already, and reading a book takes long enough that you really don't need storage for more than a handful. Once you get even a 2" screen, you've got enough text on the page to comfortably read.
The eBook market is currently doing OK, but it's stagnating, there's enough eBooks published to let me keep an unread one on hand for when I'm stick in a queue or a waiting room, but what's keeping it from taking off is the idea that DRM is needed, and the halo effect from the ongoing failure of dedicated readers.
Put out eBooks in an open unprotected format for paperback-like prices (ie, half the 10 bucks that Kindle books cost), with readers for the larger-screen cellphones, the PSP and other handhelds, PalmOS, Pocket PC, and such music players as have 2" or better screens. Then watch the market take off. I suggest an HTML-like format like Mobipocket's, rather than one that's trying to emulate the printed page like Microsoft's or Adobe's: Fictionwise and Baen make their books available in at least HTML, PDF, Palm Reader, Mobibook, and Microsoft Reader.
I was about to ask WTF happened to them. They weren't linked from the download page, and I couldn't find them elsewhere on the site.
If the initial review had linked to the right page I would have seen "Requirements... Mac OS X 10.4 and later" and not bothered downloading it until I got in to work (still on Panther on my Mac mini).
The Mac installation instructions have a problem... they suggest you drag Firefox to your applications folder, which will overwrite your existing copy of Firefox. They should either give it a different name (like, Firefox Beta) or suggest installing it in a different location, so that you can easily back out of the beta back to your existing Firefox version... particularly when they make a point that this is intended for developer testing only.
The Windows install doesn't seem to make the same mistake. Well, at least on the Mac the whole "installer" insanity isn't actually needed, and users have the option of installing most packages in a private folder instead.
I've been using Camino because it's got a fraction of the overhead of Firefox and doesn't have the insecure XPI installer design.
Pity there's not a similar lightweight native Firefox derivative for Windows.
So... is Firefox secure, or does it still have the "I'm going to ask you to do something stupid in 10 seconds" countdown when you click on an install link for an XPI file? I swear, they have made it less convenient to install extensions in Firefox than they would have by just letting you download them and install them manually, and they've had to close at least one security hole related to this unnecessary flourish.
This is another step down the path to the dark side.
First, the FSF extended their definition of derived work to include programs that were compatible with GPLed code but didn't actually contain any GPLed code, bringing the horrors of interface copyrights into the FSF's fold.
Now, they're invoking the madness that modifying but not redistributing software is against the license, which is a tool used to lock end-users in by denying them the right to modify commercial software.
These kinds of clauses and interpretations strengthen the dead grasp of Microsoft and other companies that want to use software patents, interface copyrights, and onerous and offensive non-modification clauses to keep users from modifying their own software. One day, I can see the LPF in court, attacking some onerous license, and their opposite number pointing out that the same clauses were right there in licenses drawn up by the same lawyers working for the FSF.
Don't fear one evil so much that you end up serving others just as great. Fear leads to hate, hate leads to anger, and anger leads to suffering.
I'm MySQL through and through, but honestly, the worst flame wars I've ever seen on the site were mysql vs. postgres.
Ah, youngsters these days, how soon they forget the dark times, the great OS wars, when geeks everywhere stood up for their right to use their OS of choice. Now all that is left is UNIX, and UNIX wannabes... even Windows bears the mark of the Beastie these days.
If it's okay for some dude to "share" a song by putting it on a P2P network, wouldn't it be okay for some GPL-hater to distribute binary code on a P2P network without including the source?
The issue isn't whether it's "OK" to share a song, it's the penalties, and the standard of evidence that the RIAA is using, and their contempt for due process.
Should the FSF decide to go after someone's private hack of Emacs and demand a hundred grand penalties from a dozen random users who just happened to have downloaded it, then I imagine this might weaken their case. I don't think this will keep them up nights.
Let's put it this way. If Freescale had shipped a G4 with a decent FSB a year earlier, Apple wouldn't have had an excuse to switch to Intel. Access to RAM is the real bottleneck these days.
I set a very specific criteria for the cases when it will continue to be true.
But do those criteria actually match the issue raised in the original article? The fact that the concerns expressed in the original article are not true in all cases doesn't actually address those concerns, because the fact that they're not universally true is obvious. The article that we're talking about isn't claiming that there's a problem now, for that matter. It's a cautionary tale, not a call to arms.
Slashdot Mirror
I see you didn't even take the time to read the main page.
No. Guilty. Googled right to the download page.
Poking around in the user agent string, however, is a but much.
Frankly, back when I last tried it, in June or July, it was so far from ready for prime time that I didn't do much more than install it and play with it for a few minutes.
Yes, I assumed that they would be using the "K" name because they were using the KHTML engine.
That we had to wait for Safari on Windows to get a KHTML-based browser at all is appalling.
In any case, I think I should have said something more to the effect of "it's a pity that there isn't a decent lightweight browser for Windows using the native UI *at all*". Because, right now, there isn't. I don't know what the problem with Safari is... for me it started out nice and fast but bogged down very quickly. K-Meleon might be worthwhile with a year of polishing. Firefox 3 seems like an improvement, but it's still not native and I'm still concerned about XPI. There's a third party webkit browser but last I looked it was kind of stalled.
There doesn't seem to be anything out there for Windows, at all.
If adblock is a deal-killer for you, then of course it isn't an alternative for you.
:)
Don't rule out the possibility (however remote) that other people may have different priorities.
What about XPI do you find insecure?
The fact that the XPI install is initiated from within the browser. This means it's necessary to provide a hole in the sandbox whereby an untrusted object can request privileges necessary to install an extension. Since this privilege is equivalent to full local user privileges, any exploits that could use this hole would be extremely serious. It is certainly possible that they have blocked all possible avenues of attack through this hole, but given that similar (albeit somewhat broader) holes in the Microsoft HTML sandbox have been responsible for the majority of exploits through IE, it seems poor design to even allow such a hole to exist.
The alternative design would simply download the extension like any other file, and leave it in the user's download directory and download manager. Then the user would, outside the untrusted object, explicitly request that the extension be installed. The operation of installing would, depending on the platform, include:
1. Opening the extension in the OS file manager, with the handler for that file type set to Firefox.
2. Right-clicking the Firefox download manager entry and selecting "install".
3. Selecting an "Install Extension" menu entry and navigating to the downloaded file.
By making the installation a separate step, explicitly requested by the user, you gain two advantages.
1. It is not necessary to provide a mechanism for a web page to request an operation that can grant them full local user privileges. This should be an obvious point, so I won't go into further detail.
2. Making the install a separate operation from the download means that the user is explicitly requesting it, and not just clicking on an approval dialog. The difference in these two user interface models is surprisingly large... in 20 years as a network and system administrator, and almost 10 years experience with Internet Explorer, I have only had one user (out of several hundred over that period) who was unable to learn not to download files and double click them after the first time they came to me with an infected computer. I have had many users come to me over and over again and say they clicked OK (or open, or "infect me now", or whatever the dialog of the week said) and their computer was acting funny. Because people get trained to approve dialogs, the dialog comes up and it's a reflex to click it.
Currently, XPI does make it fairly hard to open by accident. But to do this they have made the whole operation more complicated than just treating an XPI file with the same security model as an executable would. Instead of downloading it then (at your convenience) selecting "install", you have to whitelist the site (which takes several steps), then wait through a countdown, then click on an approval dialog.
A simpler design would be both more secure and more convenient. It's rare enough that you can say this of anything, no?
Well, I stand corrected. K-Meleon merely has an unfortunate name.
It's certainly possible to write applications that run in place (I don't like overriding the existing meaning of the term 'portable application' for this) for Windows, but Microsoft makes it hard. Apart from the registry issues, their shared libraries don't normally get tracked by the complete path name so if your application needs (and includes) a copy of a Windows library that may not be installed you really need to do something to make sure it GETS installed in %systemroot% unless there's a more recent one there. Portable applications really need to eschew those libraries, and they must avoid others because they expect the application to be using the registry. On top of that Microsoft, by default, hides the contents of "Program Files".
I disagree that configuration for the application should be restricted to the application directory. A versioned config file in your profile is more useful for the more typical case, because it allows you to run the application from read-only directories or media.
On traditional UNIX systems you can set up standalone applications a lot more easily, but they're not the default.
The Scheme NeXT came up with and that Apple continues to use in OS X makes standalone apps the default, and installers the exception. That's the real distinction.
Perhaps a weaker term than "necessary" is desirable, I suppose "inevitable" is better. Microsoft makes you bend over backwards to avoid them, Apple makes you appear a tad eccentric if you use them.
Go go K-Meleon!
K-Meleon is not based on the Mozilla/firefox rendering engine, it's based on KHTML.
I love that you managed to slip in "the whole "installer" insanity" after pissing and moaning about your platform's procedure.
There's nothing wrong with the Mac's procedure, my comment was about the instructions on the Firefox beta web page.
Before installing it, rename the existing application bundle to something different (e.g. "Firefox 2.0"), and then drag the other App bundle to the Applications folder.
That's another way to do it, yes.
I tend to install beta software in ~/Applications so that it doesn't impact other users on the same machine.
Apple would have to come out with an iPod touch or iPhone with a larger screen.
Only if they believed in the fantasy that you just need a good enough display and you'll finally get the eBook-reader market to take off.
It ain't so. What's keeping the eBook-reader market from "taking off" is that a dedicated reader with a big high-quality screen is completely irrelevant. There is no "eBook-reader market" at all. There's no demand for a digital device that's the size and shape of a book, for reading novels on. There's very little demand for any kind of expensive dedicated devices, for that matter. What categories have really taken off?
Cameras.
Music players.
Cellphones.
Handheld games.
GPS/mapping devices.
PDAs.
General purpose handhelds.
Combinations of the above.
And all the successful ones are small enough to easily fit in a pocket or a purse. Bigger handhelds, like the Newton and notebook replacement devices, are gone. I can't imagine any device that's bigger than something like an iPaq getting much traction.
And once you remove the big screen, why should your eBook reader be a separate device? Books don't take up much space, and you don't need to store that many... the 8M in my Clie is plenty big enough for more books than I can comfortably scroll through already, and reading a book takes long enough that you really don't need storage for more than a handful. Once you get even a 2" screen, you've got enough text on the page to comfortably read.
The eBook market is currently doing OK, but it's stagnating, there's enough eBooks published to let me keep an unread one on hand for when I'm stick in a queue or a waiting room, but what's keeping it from taking off is the idea that DRM is needed, and the halo effect from the ongoing failure of dedicated readers.
Put out eBooks in an open unprotected format for paperback-like prices (ie, half the 10 bucks that Kindle books cost), with readers for the larger-screen cellphones, the PSP and other handhelds, PalmOS, Pocket PC, and such music players as have 2" or better screens. Then watch the market take off. I suggest an HTML-like format like Mobipocket's, rather than one that's trying to emulate the printed page like Microsoft's or Adobe's: Fictionwise and Baen make their books available in at least HTML, PDF, Palm Reader, Mobibook, and Microsoft Reader.
I was about to ask WTF happened to them. They weren't linked from the download page, and I couldn't find them elsewhere on the site.
... Mac OS X 10.4 and later" and not bothered downloading it until I got in to work (still on Panther on my Mac mini).
If the initial review had linked to the right page I would have seen "Requirements
But... Firefox is already a lightweight derivative... of Mozilla Suite (SeaMonkey)...
It's lightweight in that it has less compiled code in it, alas it makes up for it with an excessive amount of scripted code.
The Mac installation instructions have a problem... they suggest you drag Firefox to your applications folder, which will overwrite your existing copy of Firefox. They should either give it a different name (like, Firefox Beta) or suggest installing it in a different location, so that you can easily back out of the beta back to your existing Firefox version... particularly when they make a point that this is intended for developer testing only.
The Windows install doesn't seem to make the same mistake. Well, at least on the Mac the whole "installer" insanity isn't actually needed, and users have the option of installing most packages in a private folder instead.
I've been using Camino because it's got a fraction of the overhead of Firefox and doesn't have the insecure XPI installer design.
Pity there's not a similar lightweight native Firefox derivative for Windows.
So... is Firefox secure, or does it still have the "I'm going to ask you to do something stupid in 10 seconds" countdown when you click on an install link for an XPI file? I swear, they have made it less convenient to install extensions in Firefox than they would have by just letting you download them and install them manually, and they've had to close at least one security hole related to this unnecessary flourish.
This is another step down the path to the dark side.
First, the FSF extended their definition of derived work to include programs that were compatible with GPLed code but didn't actually contain any GPLed code, bringing the horrors of interface copyrights into the FSF's fold.
Now, they're invoking the madness that modifying but not redistributing software is against the license, which is a tool used to lock end-users in by denying them the right to modify commercial software.
These kinds of clauses and interpretations strengthen the dead grasp of Microsoft and other companies that want to use software patents, interface copyrights, and onerous and offensive non-modification clauses to keep users from modifying their own software. One day, I can see the LPF in court, attacking some onerous license, and their opposite number pointing out that the same clauses were right there in licenses drawn up by the same lawyers working for the FSF.
Don't fear one evil so much that you end up serving others just as great. Fear leads to hate, hate leads to anger, and anger leads to suffering.
SQL Server is [...] the best thing that MS sells.
Damning with faint praise.
Fast times at Fairmont High, eh? You think Google's going to digitize a library with a shredder next?
You can't help but throw in a straw man, no matter what. I'm not biting this time.
I'm MySQL through and through, but honestly, the worst flame wars I've ever seen on the site were mysql vs. postgres.
Ah, youngsters these days, how soon they forget the dark times, the great OS wars, when geeks everywhere stood up for their right to use their OS of choice. Now all that is left is UNIX, and UNIX wannabes... even Windows bears the mark of the Beastie these days.
If it's okay for some dude to "share" a song by putting it on a P2P network, wouldn't it be okay for some GPL-hater to distribute binary code on a P2P network without including the source?
The issue isn't whether it's "OK" to share a song, it's the penalties, and the standard of evidence that the RIAA is using, and their contempt for due process.
Should the FSF decide to go after someone's private hack of Emacs and demand a hundred grand penalties from a dozen random users who just happened to have downloaded it, then I imagine this might weaken their case. I don't think this will keep them up nights.
How big of an impact will the faster FSB have?
Let's put it this way. If Freescale had shipped a G4 with a decent FSB a year earlier, Apple wouldn't have had an excuse to switch to Intel. Access to RAM is the real bottleneck these days.
The actual report isThe Internet Singularity, Delayed: Why Limits in Internet Capacity Will Stifle Innovation on the Web, free registration for a PDF download.
"Access is the path to the dark side, for Access leads to SQL Server, and SQL Server leads to suffering."
I hope we re-write our app in mySQL.
If Jet was adequate, you may be better off using SQLite.
You prefer PostgreSQL?
I set a very specific criteria for the cases when it will continue to be true.
But do those criteria actually match the issue raised in the original article? The fact that the concerns expressed in the original article are not true in all cases doesn't actually address those concerns, because the fact that they're not universally true is obvious. The article that we're talking about isn't claiming that there's a problem now, for that matter. It's a cautionary tale, not a call to arms.
Did you read it?