Strange, on most of the sites I visit it renders the page fine. Ah well, that's anecdotal evidence for you.
As for BSODs, you are aware that that's the equivalent of a kernel panic, right? Firefox crashing on Linux is the equivalent to Firefox or IE crashing on Windows. Now, it may be that FF for Linux is less stable than FF for Windows; given how much the Mozilla devs seem to not "get" Linux/Unix it wouldn't surprise me.
But unless you've been having kernel panics more often than BSODs, then Linux is still running fine. If FF is buggy, that's a problem with FF.
[x] It is too short [x] It fails to include humorous but not applicable options that are left unchecked. [x] It lacks a "furthermore..." section [x] You were clearly too lazy to put any real effort into...
Ah, to hell with it.
(And here's an extra bit to get round/.s "This exact comment has already been posted. Try to be more original..." filter. Way to completely miss the point/.)
So can anyone comment on whether this API is good enough to implement in other video drivers?
Or whether it's worth implementing the API in X, or even as part of Gtk/Qt/yourfavouritetoolkit, which would all seem to be more sensible places to put a video API than inside a single device driver. (â½)
I agree. I do things the other way around, and have almost everything encrypted.
I then have a unencrypted disk mounted at/mnt/unencrypted/ with per-user subdirectories (usually symlinked from ~/unencrypted for each user) which can be used for data - usually large files - that are known to be non-sensitive.
Everything users work on is protected by default. Users need to make a conscious decision to put stuff in the unencrypted partition, so they tend to only do it after they've noticed a performance problem, and thought through whether it belongs on an unencrypted disk.
So, what you're saying is, is that it's not reimplementable.
Oh, and you forgot to point out that it's only reimplementable by people who've not installed the Adobe Flash player, ever. Which means that even if someone *does* reimplement it, it's kind of hard for them to check that they've done it right, as they can't install and run Adobe's player side by side with their own, to check their player does the same thing.
Uh huh.
Did you not get the central point of my argument or something?
I mean, I'm sorry that I asked for the format to be open when it apparently already is, but I intended that as a means to an end, which is that a Flash player needs to be implementable by anyone for it to be a useful, viable Internet technology.
In the meantime, I'm still waiting for Adobe's Flash player to be available on my Linux/x86-64 and Linux/PPC boxes. After all, Adobe supports Flash on Linux, and they run Linux.
"They get screamed at for not releasing specs [...] Why should company X spend the most time supporting a platform that has the least marketshare?"
Depends on what the target market for the app is. If it's meant to work on a single PC, or even on a homogenous LAN, it doesn't really matter.
But, if you want your app to be a major part of The Internet, you need to realise that:
1) The Internet is not, and has pretty much never been, a network of homogenous devices.
2) The range of devices connected to the internet is not shinking; it is diversifying more and more as time progresses.
3) The Internet's greatest strength is the fact that it is an open platform, built on open standards, reimplementable by anyone. This is so that when diverse groups of people build new devices that are not like the others, the people who build the device can make it work. Distributing the development this way, instead of relying on a single company to port, e.g. a TCP/IP stack, to every device ever made, means that more devices can be built and tested in the real world than would be possible in the single-company approach.
4) The openness of the platform and the interconnectivity of the internet means that even if the manufacturer of a device doesn't have the resources to implement a particular bit of software (e.g. a mail reader) then development can be distributed further and any end user, or collection of end users, can write a mail reader for that device, making the device more valuable, and making email more valuable due to network effects.
I don't give a fuck if Photoshop is ported to Linux or not. Or, if it is, whether Adobe only ports it to LSB-3.2/x86-32. I don't give a fuck because I can use any application to manipulate photos and other images, because the formats are open, and the protocols you use to copy images around are also open.
But if you want your new file format to be widely used on The Internet, you should take the time to learn a fucking thing or two about why The Internet is as powerful, useful and ubiquitous as it is. Especially if you want your file format to succeed on The Internet because of how great The Internet is. Creating formats and applications to take advantage of The Internet, while at the same time not only ignoring, but actively working against, the principles and methods which caused The Internet to be the thing that you want to take advantage of, is going to make people who have thought about this shit frustrated, and scream at you for being so fucking short-sighted.
I wouldn't give a fuck about Adobe's Flash player being released/supported on Linux or not, if it the Flash format was open, documented and reimplementable - just like every other major technology out there. Then I could choose to use Adobe's Flash player, if I wanted to, based on whatever criteria I may happen to have. Be that price, freedom, stability, the device I'm using and the CPU it happens to have, etc...
If the Flash format were open, it wouldn't matter if supporting Linux were financially viable for Adobe. They wouldn't have to support it. The community would do that work for them. They'd support their own code.
And, by making the Flash format available for more platorms, and more devices, these diverse communities would make the Flash file format more valuable, again due to network effects. The wider the format is supported, the more useful it is as a technology.
I thought the problem was that DNF is on track to be nearly ready in 5-10 years. When this goes commercial, they'll have to go back and switch engines *again*!
"Think of it as anti-virus definitions. You only need ONE copy."
Yes, but how is that one copy updated? If it's not by a central daemon/service that runs even if no-one is logged in, then it has to be run by a user while they're running Firefox. If that is the case, that user needs write access to the shared database in order to write the updated definition. In which case, if you have a malicious user (or code running as a malicious user, thanks to a dancing bunnies error) who can write to the database, they can erase or alter the contents of the blacklist for everyone on the system.
"You also seemed to miss my point regarding places.sqlite"
Oh yeah, I did miss that bit. It is a pretty interesting idea, and could have the potential to be awesome.
But you still don't need a MySQL server to do it. SQLite (at least according to the docs I've read) can support a single writer/multiple readers of the same DB. So even with SQLite, if each users' places.sqlite is writable by them but readable by everyone, then you should still be able to tell someone to see your bookmarks, and have Firefox automatically look in "/home/[user]/.mozilla/firefox/[salt].default/places.sqlite" (or the Windows equivalent) to find it.
You can use all the standard file permissions that you'd need to use anyway to share other data between members of the same project/class/etc...
"There's no way that I know of, anyway, to share this data - SQLite seems to make it impossible."
Well, I doubt it's SQLite that makes it impossible, it's more that you don't want ordinary users writing to a single shared blacklist. Because if a user can download and write good data to it, they can write bad data to it.
Suddenly all it takes is for one user to click on the dancing bunnies, and they're running a daemon without knowing it that writes bad data to the blacklist, monitors the list for changes, and rewrites it if any of the other users change it back to what it "should" be. That fucks things up for *everyone*, which kind of defeats the whole idea of having separate user accounts that protect everyone from each other.
"The second mistake is enabling website blocking based on 3rd party blacklists by default."
If you don't do that then non-geeks - the people who need this most - will never find it to switch it on. If you're a geek and you don't like it and are smart enough to spot phishing attempts yourself (and good luck with that by the way; I've seen reports of many trials here on/. where even seasoned network admins don't get a 100% success rate at spotting them) then you're probably smart enough to find the checkbox to disable it.
"And even if you argue with that, at the LEAST make it cross-DB compatible, so you can put everyone's in a nice big central MySQL database."
Bleargh! You want a DB-abstraction layer so that... everyone can write to the same DB? That will add bloat and do nothing to fix the problem.
If you make the database writable only by root/Administrator and have a separate daemon/service that runs as that user to update, with all users having read-only access, that would solve your problem. But then someone else would complain that this service was running and creating network traffic uselessly when no-one was actually running firefox, or even logged in.
For a home user, what they've got makes sense. If you're running a reasonable-sized network, or have something like LTSP, you should be able to set up Squid proxy (or similar) so that only one user causes the list to be fetched from the network and everyone else loads your cached copy.
Make it do the right thing for n00bs out of the box. Experts can configure it differently for themselves because, well, they're experts.
Reporting of knife crime in the UK has increased dramatically. It just happens to be what the papers happen to be focusing on this year. Last year it was the McCann thing. A few years ago it was the great paedophile threat, which came about due to one or two high-profile cases featuring photogenic young girls. Before that it was... thankfully I can't remember.
Anyway, the papers finally decided they needed new "fear" stories to run and grab headlines with. Knife crime appears to be the one they're rallied around this time.
You are still much, much more likely to die in a car accident than to be stabbed to death by a "teenage yob". Doesn't make good headlines though or instill the same level of fear though, does it?
True, but I'm not just an end user. I download, makes copies of, and redistribute Free Software to my friends.
As far as end user use goes, this Firefox EULA is worse than Free Software licenses because it apparently is an EULA, and not a permission-to-redistribute license. As just an end user, I would need to read and understand the Firefox EULA merely in order to use the product.
So, in regards to the Firefox EULA, my point still stands. I don't want to have to wade through and make sense of that crap. If it offers me something new, or plenty of other software uses it, it might (just might) be worth my while. Until then, no thanks.
Is that just one time ever? Or will you need to agree one time for each new major version (4.x)? Or for each minor version (3.1)? Or for each security patch (3.0.x)? Or how about for each Ubuntu upgrade (8.10, 9.04)? If it's just one time in total, why does my implicit agreement of the current Firefox EULA (which does exist - it just doesn't pop up by default, but I am assumed to have agreed to it by the act of using the software) not already count?
Besides, I don't *want* to have to read and understand another license. There are enough licenses out there as it is for Free Software.
I've read, and I'm pretty sure I understand, the GPL2/3, the LGPL2/3, the BSD license (2-clause, 3-clause, 4-clause and MIT variants), the Apache license, the Artistic license, and probably a couple of others which escape me right now. I've also read and understand the Debian Free Software Guidelines and what it means for a license to conform to them, and what rights I get as a user, modifier and distributor of works under them.
That's enough for me. I don't want to read and try to understand another license. Maybe if it offers me some great advantage that these other licenses don't, or if enough software is released under it that it makes it worth my while to read and understand it so that I can actually use that collection of software, then maybe. But a new EULA for a single product? Nuh-uh. Not worth my while. Much easier to just switch to a different product which uses a license that already falls under the DFSG instead.
Reminds me something I heard a wise hacker say once, when someone tried to convince him that their new version of some code was better that his, because it ran in 10% of the time his did but produced (slightly) wrong results in a few cases...
"If it doesn't have to produce correct results, I can make my version use no memory and run in zero time."
Slashdot Mirror
Uh huh. And how are they going to get round the fact that the archive is signed?
Where "reverse engineered" should be translated as "telnetted to the bitkeeper server/port and typed 'help'"
I prefer Linus's
And I see
http://iwfwebfilter.thus.net/error/blocked.html
I've been kinda-sorta thinking about switching ISPs for a while. Guess it might be time to start doing something about it.
Strange, on most of the sites I visit it renders the page fine. Ah well, that's anecdotal evidence for you.
As for BSODs, you are aware that that's the equivalent of a kernel panic, right? Firefox crashing on Linux is the equivalent to Firefox or IE crashing on Windows. Now, it may be that FF for Linux is less stable than FF for Windows; given how much the Mozilla devs seem to not "get" Linux/Unix it wouldn't surprise me.
But unless you've been having kernel panics more often than BSODs, then Linux is still running fine. If FF is buggy, that's a problem with FF.
Why does no-one include Konqueror in these tests? It's even available for Windows these days.
Your "standard form" reply fails because:
[x] It is too short
[x] It fails to include humorous but not applicable options that are left unchecked.
[x] It lacks a "furthermore..." section
[x] You were clearly too lazy to put any real effort into...
Ah, to hell with it.
(And here's an extra bit to get round /.s "This exact comment has already been posted. Try to be more original..." filter. Way to completely miss the point /.)
So can anyone comment on whether this API is good enough to implement in other video drivers?
Or whether it's worth implementing the API in X, or even as part of Gtk/Qt/yourfavouritetoolkit, which would all seem to be more sensible places to put a video API than inside a single device driver. (â½)
"newsispants" and "pleasestop"
Why does it need knowledge of the plugin? Why not just:
<object data="file.ogv">Alt text goes here</object>
The browser/toolkit/OS is responsible for then loading any appropriate player based on the content-type of whatever file.ogv is. What else is needed?
They're only a part of the Holocene extinction event.
I agree. I do things the other way around, and have almost everything encrypted.
I then have a unencrypted disk mounted at /mnt/unencrypted/ with per-user subdirectories (usually symlinked from ~/unencrypted for each user) which can be used for data - usually large files - that are known to be non-sensitive.
Everything users work on is protected by default. Users need to make a conscious decision to put stuff in the unencrypted partition, so they tend to only do it after they've noticed a performance problem, and thought through whether it belongs on an unencrypted disk.
So, what you're saying is, is that it's not reimplementable.
Oh, and you forgot to point out that it's only reimplementable by people who've not installed the Adobe Flash player, ever. Which means that even if someone *does* reimplement it, it's kind of hard for them to check that they've done it right, as they can't install and run Adobe's player side by side with their own, to check their player does the same thing.
Uh huh.
Did you not get the central point of my argument or something?
I mean, I'm sorry that I asked for the format to be open when it apparently already is, but I intended that as a means to an end, which is that a Flash player needs to be implementable by anyone for it to be a useful, viable Internet technology.
In the meantime, I'm still waiting for Adobe's Flash player to be available on my Linux/x86-64 and Linux/PPC boxes. After all, Adobe supports Flash on Linux, and they run Linux.
"They get screamed at for not releasing specs [...] Why should company X spend the most time supporting a platform that has the least marketshare?"
Depends on what the target market for the app is. If it's meant to work on a single PC, or even on a homogenous LAN, it doesn't really matter.
But, if you want your app to be a major part of The Internet, you need to realise that:
1) The Internet is not, and has pretty much never been, a network of homogenous devices.
2) The range of devices connected to the internet is not shinking; it is diversifying more and more as time progresses.
3) The Internet's greatest strength is the fact that it is an open platform, built on open standards, reimplementable by anyone. This is so that when diverse groups of people build new devices that are not like the others, the people who build the device can make it work. Distributing the development this way, instead of relying on a single company to port, e.g. a TCP/IP stack, to every device ever made, means that more devices can be built and tested in the real world than would be possible in the single-company approach.
4) The openness of the platform and the interconnectivity of the internet means that even if the manufacturer of a device doesn't have the resources to implement a particular bit of software (e.g. a mail reader) then development can be distributed further and any end user, or collection of end users, can write a mail reader for that device, making the device more valuable, and making email more valuable due to network effects.
I don't give a fuck if Photoshop is ported to Linux or not. Or, if it is, whether Adobe only ports it to LSB-3.2/x86-32. I don't give a fuck because I can use any application to manipulate photos and other images, because the formats are open, and the protocols you use to copy images around are also open.
But if you want your new file format to be widely used on The Internet, you should take the time to learn a fucking thing or two about why The Internet is as powerful, useful and ubiquitous as it is. Especially if you want your file format to succeed on The Internet because of how great The Internet is. Creating formats and applications to take advantage of The Internet, while at the same time not only ignoring, but actively working against, the principles and methods which caused The Internet to be the thing that you want to take advantage of, is going to make people who have thought about this shit frustrated, and scream at you for being so fucking short-sighted.
I wouldn't give a fuck about Adobe's Flash player being released/supported on Linux or not, if it the Flash format was open, documented and reimplementable - just like every other major technology out there. Then I could choose to use Adobe's Flash player, if I wanted to, based on whatever criteria I may happen to have. Be that price, freedom, stability, the device I'm using and the CPU it happens to have, etc...
If the Flash format were open, it wouldn't matter if supporting Linux were financially viable for Adobe. They wouldn't have to support it. The community would do that work for them. They'd support their own code.
And, by making the Flash format available for more platorms, and more devices, these diverse communities would make the Flash file format more valuable, again due to network effects. The wider the format is supported, the more useful it is as a technology.
I thought the problem was that DNF is on track to be nearly ready in 5-10 years. When this goes commercial, they'll have to go back and switch engines *again*!
Huh? If their web server is crashing due to too much email, why not just move the mail server onto a different box?
WTF?
WTF?
Bollocks.
s/Linxen/Linuxen/
"...to create an x86-32 (and maybe, if you're really lucky, x86-64) binary-level interface that application developers can use..."
There, fixed that for you.
Best of luck getting your binary package to run on Linux/PPC, Linux/ARM, Linux/Alpha, Linux/Sparc, etc...
If you want your software to run on multiple Linxen, you need to make it open and let the distros compile it and build the packages. That's it.
"Think of it as anti-virus definitions. You only need ONE copy."
Yes, but how is that one copy updated? If it's not by a central daemon/service that runs even if no-one is logged in, then it has to be run by a user while they're running Firefox. If that is the case, that user needs write access to the shared database in order to write the updated definition. In which case, if you have a malicious user (or code running as a malicious user, thanks to a dancing bunnies error) who can write to the database, they can erase or alter the contents of the blacklist for everyone on the system.
"You also seemed to miss my point regarding places.sqlite"
Oh yeah, I did miss that bit. It is a pretty interesting idea, and could have the potential to be awesome.
But you still don't need a MySQL server to do it. SQLite (at least according to the docs I've read) can support a single writer/multiple readers of the same DB. So even with SQLite, if each users' places.sqlite is writable by them but readable by everyone, then you should still be able to tell someone to see your bookmarks, and have Firefox automatically look in "/home/[user]/.mozilla/firefox/[salt].default/places.sqlite" (or the Windows equivalent) to find it.
You can use all the standard file permissions that you'd need to use anyway to share other data between members of the same project/class/etc...
"There's no way that I know of, anyway, to share this data - SQLite seems to make it impossible."
Well, I doubt it's SQLite that makes it impossible, it's more that you don't want ordinary users writing to a single shared blacklist. Because if a user can download and write good data to it, they can write bad data to it.
Suddenly all it takes is for one user to click on the dancing bunnies, and they're running a daemon without knowing it that writes bad data to the blacklist, monitors the list for changes, and rewrites it if any of the other users change it back to what it "should" be. That fucks things up for *everyone*, which kind of defeats the whole idea of having separate user accounts that protect everyone from each other.
"The second mistake is enabling website blocking based on 3rd party blacklists by default."
If you don't do that then non-geeks - the people who need this most - will never find it to switch it on. If you're a geek and you don't like it and are smart enough to spot phishing attempts yourself (and good luck with that by the way; I've seen reports of many trials here on /. where even seasoned network admins don't get a 100% success rate at spotting them) then you're probably smart enough to find the checkbox to disable it.
"And even if you argue with that, at the LEAST make it cross-DB compatible, so you can put everyone's in a nice big central MySQL database."
Bleargh! You want a DB-abstraction layer so that ... everyone can write to the same DB? That will add bloat and do nothing to fix the problem.
If you make the database writable only by root/Administrator and have a separate daemon/service that runs as that user to update, with all users having read-only access, that would solve your problem. But then someone else would complain that this service was running and creating network traffic uselessly when no-one was actually running firefox, or even logged in.
For a home user, what they've got makes sense. If you're running a reasonable-sized network, or have something like LTSP, you should be able to set up Squid proxy (or similar) so that only one user causes the list to be fetched from the network and everyone else loads your cached copy.
Make it do the right thing for n00bs out of the box. Experts can configure it differently for themselves because, well, they're experts.
Knife crime has not increased in the UK.
Reporting of knife crime in the UK has increased dramatically. It just happens to be what the papers happen to be focusing on this year. Last year it was the McCann thing. A few years ago it was the great paedophile threat, which came about due to one or two high-profile cases featuring photogenic young girls. Before that it was ... thankfully I can't remember.
Anyway, the papers finally decided they needed new "fear" stories to run and grab headlines with. Knife crime appears to be the one they're rallied around this time.
You are still much, much more likely to die in a car accident than to be stabbed to death by a "teenage yob". Doesn't make good headlines though or instill the same level of fear though, does it?
True, but I'm not just an end user. I download, makes copies of, and redistribute Free Software to my friends.
As far as end user use goes, this Firefox EULA is worse than Free Software licenses because it apparently is an EULA, and not a permission-to-redistribute license. As just an end user, I would need to read and understand the Firefox EULA merely in order to use the product.
So, in regards to the Firefox EULA, my point still stands. I don't want to have to wade through and make sense of that crap. If it offers me something new, or plenty of other software uses it, it might (just might) be worth my while. Until then, no thanks.
Is that just one time ever? Or will you need to agree one time for each new major version (4.x)? Or for each minor version (3.1)? Or for each security patch (3.0.x)? Or how about for each Ubuntu upgrade (8.10, 9.04)? If it's just one time in total, why does my implicit agreement of the current Firefox EULA (which does exist - it just doesn't pop up by default, but I am assumed to have agreed to it by the act of using the software) not already count?
Besides, I don't *want* to have to read and understand another license. There are enough licenses out there as it is for Free Software.
I've read, and I'm pretty sure I understand, the GPL2/3, the LGPL2/3, the BSD license (2-clause, 3-clause, 4-clause and MIT variants), the Apache license, the Artistic license, and probably a couple of others which escape me right now. I've also read and understand the Debian Free Software Guidelines and what it means for a license to conform to them, and what rights I get as a user, modifier and distributor of works under them.
That's enough for me. I don't want to read and try to understand another license. Maybe if it offers me some great advantage that these other licenses don't, or if enough software is released under it that it makes it worth my while to read and understand it so that I can actually use that collection of software, then maybe. But a new EULA for a single product? Nuh-uh. Not worth my while. Much easier to just switch to a different product which uses a license that already falls under the DFSG instead.
Reminds me something I heard a wise hacker say once, when someone tried to convince him that their new version of some code was better that his, because it ran in 10% of the time his did but produced (slightly) wrong results in a few cases...
"If it doesn't have to produce correct results, I can make my version use no memory and run in zero time."