that WOULD be an improvement over what they are doing now, which is to simply not play anything!
The proper response, though, is not to put up some sort of error message, but to use an external solution such as mplayer, ffplay, vlc, gstreamer, or whatever, and make it "someone else's problem".
Chrome up and coming is an even bigger issue because of this. If it works well with youtube, and firefox doesn't, then firefox will lose dramatic market share to Chrome.
It is likely not legal for them to pay for a license directly. Such a license would likely require them to not release the patented code openly, like they are required to do for the GPL.
Such a license would also not pass to others, so Ubuntu/etc would not be able to distribute the licensed firefox.
This is why I suggest they either:
1) Make it a non-USA release, similar to PGP/PGPi in the past. This would be if they wanted to take a stand, and make lots of activist-style press releases on the subject. It would also probably be more effective than trying to talk everybody into using Theora.
2) Externalize the issue, by using an external program instead. That way they aren't decoding any video, and are totally safe from patent issues.
Option #2 is recommended, as a pragmatic decision.
While I'd love it if the patent/licencing issues could be easily fixed like that, I seriously doubt it will ever be the case. In the world of video, more than most other fields, patents have become a total minefield. Even in things like "patent free" Theora, companies are still reluctant to implement them for fear of submarine patents.
So I suspect we will have this problem in one form or another no matter what.
So Firefox should sidestep the issue by externalizing it. This is not idea, but it's practical and strategic. Firefox is riding a powerful wave of popularity right now, and they need to keep that momentum going to win the larger war. Pop culture these days means things like youtube, and if you don't work perfectly with youtube (and hulu, and vimeo, and related sites), you will be ignored by the masses.
I'm a total GNU fanboy most days, and generally agree with the moral move they are trying to make with OOG formats, but in this case it is a losing strategy. H264 video has gotten a momentum that is hard to break, similar to how MP3 got a momentum in the past. It has nothing to do with technical features, morals, licensing, or other commonly-argued things. Instead, it's about a critical-mass of popularity. H264 video the new pop thing, even in cases where people don't even know terms like "H264".
By not finding a way to make video work properly, Firefox is saying they want to be left behind. No, I highly doubt people like google or others will re-encode video into Theora. They will make the business decision that not only is it a lot of work, it's not necessary as firefox is supported with Flash.
If the Firefox people want to make a good moral stand with this issue, they should pull something similar to the crypto situation and make an "international" version. That version could serve as an embarrassment to the restrictive patent system, and a useful political talking point. At a minimum, though, they should simply remove all codec processing form the project, leaving that particular can of worms to an external project (gstreamer? embed mplayer/vlc/other? some new project created specifically for this purpose?).
I love firefox. I really do. So please don't choose to be non-player in the video arena!
But I think I blew the charts with my AHI score of 152. Verified it with a 2nd sleep study that scored 148.
I think the nasal septum surgery helped that a bit, but the CPAP/BiPAP actually made me wake up (and notice waking up) more often. I still have no clue what is actually causing this... *sigh*
It's a tool that allows the person administering it to better understand the mental state of the person they're dealing with in a way that doesn't allow them to employ the usual defensive responses.
Really? And what double-blind study shows this?
That's just another in the long line of grand assumptions that psychologists make with these kinds of "tests".
As far as "showing pathologies", how would such idiocy be different from just doing any other kid of cold reading on someone, and why would it have better accuracy?
While actual damages can never be determined, they can be estimated fairly easily.
Most modern P2P software works by distributing the uploading over the entire network. This is certainly true for bittorrent, and mostly true on older networks referenced in this case, if I remember correctly.
A == "number of people wanting a copy" B == "number of copies desired per-person" == 1 C == "number of copies needed" == A * B == A D == "number of uploaders" ~= C
X == "number of copies uploaded, per-person" == D / C == C / C == 1
On average (mean), a SINGLE copy is uploaded by any one person. Just look at your average bittorrent swarm. How often do you get a share ratio above 1.0? How often do you get a share ratio above, say, 100.0? Ever?
Actual damages here are on the order of $0.99 * 24. Probably not that exactly, but it's going to be around that order of magnitude. S why, again, is $750 or more sane?
Upload speed of a cable modem? You're falling into the trap that the RIAA and others are playing.
Potential upload speeds aren't relevant here. That's all fancy numbers thrown around, to justify large statutory damages by implying someone could have uploaded a lot of copies of any given work.
Some simple math:
- There are N people that want a song, and download it over P2P
- Number of copies that have to be made: N
- Number of people providing those copies: ~N, on most P2P networks
- average (mean) copies made by any one person: (number of copies made)/(number of uploaders) => (N/N) => 1.
On average, any given copyright infringer is making a single copy. Any discussion of damages, statutory or actual, needs to take this harsh reality into consideration.
That's simply not true on modern computers. The CPU is often idle - it's starved for data, with the bottleneck being the buss that feeds it (RAM, generally). Add to this the fact that reading neighboring areas of DRAM is a much faster than randomly reading spots in in memory spread across whole megabytes (or gigabytes, even).
Compare recomputing something, where you never have to leave L1 cache, versus flushing the first few cache levels continuously to do spread-out reads of already-computed data. It's very likely, on a modern CPU, that the first will be faster.
Of course, this will vary considerably based on what your actual problem is, and you may be getting into bad "must hand-write assembly" cases which should generally be avoided, but... it is still true that computing every time is not only smaller, it's faster some of the time. For evidence of this, check how some people are finding compiling with -Os instead of -O2 actually produces faster code.
In any case... trying to stuff a 1GB working set through the Von Neumann bottleneck is never going to produce an efficient and responsive program. Firefox is not exception here, though it's getting better with each release.
Yes, there are always pathological cases that demonstrate the weaknesses of any technique. A big point I take away from RFC1925 (and personal experience), is that you have to A) recognize that trade-offs are always going to be made, and B) adapt your implementation to fit the laws of physics, instead of trying to bend the network to fit what you think an implementation should be.
The simple fact is that Sockets have worked very well for a long time. Yes, this sometimes means you have to shape your design and implementations to fit the "socket style", and history has shown that it is not only possible, but practical. Changing to a new design will not remove the fact that if you design your protocol/app badly, or are inherently in a pathological use-case, then your network performance will suffer.
For some problems, the ssh idea of multiplexing a single socket works well. For others, multiple rsh (*1) style work better. To say that Sockets need to be replaced because you chose to use rsh for your transport is an amazingly arrogant (*2) position. And yes, some of this is "tradition" and inertia, but designing a whole new library should be for significant real-world benefit, and not for corner-cases or maginal 1% gains.
Of course, if someone can actually produce some real-world benchmarks that validate the "let's ditch Sockets" claim...
[*1] As with you, this is totally ignoring the security implications, etc. [*2] In no way is this a personal attack at you; I mean it in a purely academic sense. It's a very tall claim to say that decades of networking history, and thousands of talented engineers were wrong.
That's a very reasonable interpretation of the situation, IMHO. I totally disagree with it in several places, but I can at least respect the position, and do agree with the intent of you (and the article). That said... <rant style="socialist software nut">
Not to necessarily block ALL ads, but to give users the power to block excessively annoying ads
I would argue that humanity is better off without ads as they are used now. We are deluged with information and requests for our attention at a level never before seen in history, and I strongly suspect the human mind is not entirely suited to this task. Yes, I'm probably projecting a bit, as I know I am affected particularly strongly by this, but I suspect (with circumstantial evidence) that this is generally true at some level.
Therefor I see ABP as a tool to save the general stress and clutter plaguing the human race. The fact that (mostly) everyone I show ABP to seem to exhibit profound relief at the prospect of a less-cluttered internet is evidence in support of this. Therefor, anything that interrupts the blocking of ads is going to be dead on the vine.
Now, I know people need income and such, but pissing off customers and causing more stress and hastle in the world is not the way to do it.
I like the idea of being able to preview how annoying ads are for a site... I, for one, want to be able to support sites that are smart enough to have reasonable ads.
This brings up a good point, and possibly some inspiration. If the ABP people want to sway the balance back to the websites a bit, they should make it easier for people to whitelist, without annoying them. If you pop stuff up, you will annoy people and not win any friends. I think NoScript has a good idea here, though: a simple popup menu on the status bar. Make it really easy for someone to temporarily allow ads on a site, and easy to allow permanently.
Even with my hard-line stance against ads, a notice in the status bar would not be intrusive. You could put a number in the icon that shows how many elements were blocked, and allow them one at a time. This would not impact my anti-ad stance at all, yet still allow people like you that want to whitelist.
*sigh* - I would have thought, of all people, that people in the ad-blocking business would understand the futility of annoying people on every web site with a popup... especially when you could get most of the benefit without any META tag and just a simple status-bar icon and menu. </rant>
I'm starting a totally new app that is (hopefully) going to use OpenGL for the display. Not full 3D, but I kind of want the fancy blending features. The problem is the last time I used OpenGL was... a VERY long time ago. It seems to have changed substantially sense then.
I'm totally out of the loop, though, as far as graphics programming goes, so... does anybody know of a decent source for discussion, tutorials, docs, anything on doing modern OpenGL the "right way"? Seeing as this project is starting from scratch, I might as well get it correct from the beginning.
Because it's performance blows on non-standard platforms? Because it's lack of support for 64-bit (well, last I checked) is a pain in the ass? Because it's a constant source of memory leaks and segfaults?
The day I can get rid of that stupid plugin will be a day I celebrate a lot.
- The graphics hit a point where things no longer looked blatantly texture-mapped (the DOOM/early-quake problem) - The pacing was incredible - The weapons were surprisingly balanced. It's not like Q1 where it's "rockets or nothing"; every weapon is useful at some point. - Very customizable. (lots of FPS games have that, but it's still a point in UT2004's favor) - A variety of modes, that were generally well done. Ok, "double dominate" blows, but I still find myself playing a Bombing Run match and such just because it's crazy and different. - Very gameplay-oriented level design. Sure, some of the maps look totally absurd, but the look that way because they have specific choke-points, carefully designed flow, etc. - An extra level of polish across the board. I never really found myself saying "if it only had this feature, it'd be perfect". Even the little stuff like settings to change the crosshairs on a per-weapon basis - it showed a level of caring about the gameplay (the "fun"!) that most games skimp on.
I can't speak to how customizable UT3 is, but it(and many other games sense then) skimped on many of these features. The engine is there, though. It is potentially something that could be solved by simply adding a bunch of polish, little features, and playtesting a LOT to get the pacing/balance/etc right.
Maybe we'll get lucky and see a "UT3.5" remake where they get it right... they did show they can "reboot" things once before.
They completely failed to stay with the feature that made UT2004 a joy to play: pacing. UT2004 is manic. You run fast, the game-flow is fast. There's no room for error, and you get the feeling that standing still for even a second is a fatal mistake. When I first played UT3, though, it felt like everything was slowed way down. They lost the frantic twitch aspect, and therefor lost the feature that make their franchise distinctive.
It's something that started with DOOM/Quake1, really - the "throw realism to the wind, let's just make it fast and fun" theory. UT seemed to be following in that style - doom3 certainly wasn't - but that's over now it seems.
Hell, if they just remade the UT2004 gameplay straight into the UT3 engine, that could be a major win right there. Maybe they'll figure it out from the slow-sales of UT3. Well, one can hope...
Slashdot Mirror
in stylish or usercss or whatever:
.share, .sharebar {
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("slashdot.org") {
display: none !important;
}
}
Sure, in 15 year or whatever, it'll be trivial. Most software will be able to implement all of this with minimal hastle.
But in the mean time, the war against other things like Flash, Silverlight, IE, and open-web-standards in general will be lost.
Google (or any similar company) has no business reason to use Theora.
If they do nothing, they still support Firefox, though flash. So why spend even a small amount of time/money to re-encode video?
that WOULD be an improvement over what they are doing now, which is to simply not play anything!
The proper response, though, is not to put up some sort of error message, but to use an external solution such as mplayer, ffplay, vlc, gstreamer, or whatever, and make it "someone else's problem".
Chrome up and coming is an even bigger issue because of this. If it works well with youtube, and firefox doesn't, then firefox will lose dramatic market share to Chrome.
It's unreasonable to expect pop culture to shift because it's choice is inconvenient.
Trying to change perceptions like that didn't work with Vorbis-vs-MP3, and it won't work here either.
One nice thing about HTML5 over flash: it's much easier to fix such things in greasmonkey or similar tools.
It is likely not legal for them to pay for a license directly. Such a license would likely require them to not release the patented code openly, like they are required to do for the GPL.
Such a license would also not pass to others, so Ubuntu/etc would not be able to distribute the licensed firefox.
This is why I suggest they either:
1) Make it a non-USA release, similar to PGP/PGPi in the past. This would be if they wanted to take a stand, and make lots of activist-style press releases on the subject. It would also probably be more effective than trying to talk everybody into using Theora.
2) Externalize the issue, by using an external program instead. That way they aren't decoding any video, and are totally safe from patent issues.
Option #2 is recommended, as a pragmatic decision.
While I'd love it if the patent/licencing issues could be easily fixed like that, I seriously doubt it will ever be the case. In the world of video, more than most other fields, patents have become a total minefield. Even in things like "patent free" Theora, companies are still reluctant to implement them for fear of submarine patents.
So I suspect we will have this problem in one form or another no matter what.
So Firefox should sidestep the issue by externalizing it. This is not idea, but it's practical and strategic. Firefox is riding a powerful wave of popularity right now, and they need to keep that momentum going to win the larger war. Pop culture these days means things like youtube, and if you don't work perfectly with youtube (and hulu, and vimeo, and related sites), you will be ignored by the masses.
That's the sound of you getting passed by.
I'm a total GNU fanboy most days, and generally agree with the moral move they are trying to make with OOG formats, but in this case it is a losing strategy. H264 video has gotten a momentum that is hard to break, similar to how MP3 got a momentum in the past. It has nothing to do with technical features, morals, licensing, or other commonly-argued things. Instead, it's about a critical-mass of popularity. H264 video the new pop thing, even in cases where people don't even know terms like "H264".
By not finding a way to make video work properly, Firefox is saying they want to be left behind. No, I highly doubt people like google or others will re-encode video into Theora. They will make the business decision that not only is it a lot of work, it's not necessary as firefox is supported with Flash.
If the Firefox people want to make a good moral stand with this issue, they should pull something similar to the crypto situation and make an "international" version. That version could serve as an embarrassment to the restrictive patent system, and a useful political talking point. At a minimum, though, they should simply remove all codec processing form the project, leaving that particular can of worms to an external project (gstreamer? embed mplayer/vlc/other? some new project created specifically for this purpose?).
I love firefox. I really do. So please don't choose to be non-player in the video arena!
57? that's pretty bad...
But I think I blew the charts with my AHI score of 152. Verified it with a 2nd sleep study that scored 148.
I think the nasal septum surgery helped that a bit, but the CPAP/BiPAP actually made me wake up (and notice waking up) more often. I still have no clue what is actually causing this... *sigh*
Well, there goes one more sale.
I was about to buy that - the demo looks so good on my new HD monitor. But then they pull this crap...
It's a tool that allows the person administering it to better understand the mental state of the person they're dealing with in a way that doesn't allow them to employ the usual defensive responses.
Really? And what double-blind study shows this?
That's just another in the long line of grand assumptions that psychologists make with these kinds of "tests".
As far as "showing pathologies", how would such idiocy be different from just doing any other kid of cold reading on someone, and why would it have better accuracy?
While actual damages can never be determined, they can be estimated fairly easily.
Most modern P2P software works by distributing the uploading over the entire network. This is certainly true for bittorrent, and mostly true on older networks referenced in this case, if I remember correctly.
A == "number of people wanting a copy"
B == "number of copies desired per-person" == 1
C == "number of copies needed" == A * B == A
D == "number of uploaders" ~= C
X == "number of copies uploaded, per-person" == D / C == C / C == 1
On average (mean), a SINGLE copy is uploaded by any one person. Just look at your average bittorrent swarm. How often do you get a share ratio above 1.0? How often do you get a share ratio above, say, 100.0? Ever?
Actual damages here are on the order of $0.99 * 24. Probably not that exactly, but it's going to be around that order of magnitude. S why, again, is $750 or more sane?
see my other post to the parent comment
it's not possible for someone to give out 100 copies of a song on most P2P networks.
Do you get a share ratio of 100.0+ on bittorrent? ever?
Upload speed of a cable modem? You're falling into the trap that the RIAA and others are playing.
Potential upload speeds aren't relevant here. That's all fancy numbers thrown around, to justify large statutory damages by implying someone could have uploaded a lot of copies of any given work.
Some simple math:
- There are N people that want a song, and download it over P2P
- Number of copies that have to be made: N
- Number of people providing those copies: ~N, on most P2P networks
- average (mean) copies made by any one person: (number of copies made)/(number of uploaders) => (N/N) => 1.
On average, any given copyright infringer is making a single copy. Any discussion of damages, statutory or actual, needs to take this harsh reality into consideration.
That's simply not true on modern computers. The CPU is often idle - it's starved for data, with the bottleneck being the buss that feeds it (RAM, generally). Add to this the fact that reading neighboring areas of DRAM is a much faster than randomly reading spots in in memory spread across whole megabytes (or gigabytes, even).
Compare recomputing something, where you never have to leave L1 cache, versus flushing the first few cache levels continuously to do spread-out reads of already-computed data. It's very likely, on a modern CPU, that the first will be faster.
Of course, this will vary considerably based on what your actual problem is, and you may be getting into bad "must hand-write assembly" cases which should generally be avoided, but... it is still true that computing every time is not only smaller, it's faster some of the time. For evidence of this, check how some people are finding compiling with -Os instead of -O2 actually produces faster code. In any case... trying to stuff a 1GB working set through the Von Neumann bottleneck is never going to produce an efficient and responsive program. Firefox is not exception here, though it's getting better with each release.
I think I'm going to have to add to my list of RFC1924 issues with this proposal...
"(1) It Has To Work."
This whole topic stinks of a really bad case of Premature Optimization.
Yes, there are always pathological cases that demonstrate the weaknesses of any technique. A big point I take away from RFC1925 (and personal experience), is that you have to A) recognize that trade-offs are always going to be made, and B) adapt your implementation to fit the laws of physics, instead of trying to bend the network to fit what you think an implementation should be.
The simple fact is that Sockets have worked very well for a long time. Yes, this sometimes means you have to shape your design and implementations to fit the "socket style", and history has shown that it is not only possible, but practical. Changing to a new design will not remove the fact that if you design your protocol/app badly, or are inherently in a pathological use-case, then your network performance will suffer.
For some problems, the ssh idea of multiplexing a single socket works well. For others, multiple rsh (*1) style work better. To say that Sockets need to be replaced because you chose to use rsh for your transport is an amazingly arrogant (*2) position. And yes, some of this is "tradition" and inertia, but designing a whole new library should be for significant real-world benefit, and not for corner-cases or maginal 1% gains.
Of course, if someone can actually produce some real-world benchmarks that validate the "let's ditch Sockets" claim...
[*1] As with you, this is totally ignoring the security implications, etc.
[*2] In no way is this a personal attack at you; I mean it in a purely academic sense. It's a very tall claim to say that decades of networking history, and thousands of talented engineers were wrong.
This seems to dance a bit too close to Networking Truths 6a, 11, and possibly 12. I will reserve judgment until I see solid real-world evidence.
That's a very reasonable interpretation of the situation, IMHO. I totally disagree with it in several places, but I can at least respect the position, and do agree with the intent of you (and the article). That said...
<rant style="socialist software nut">
I would argue that humanity is better off without ads as they are used now. We are deluged with information and requests for our attention at a level never before seen in history, and I strongly suspect the human mind is not entirely suited to this task. Yes, I'm probably projecting a bit, as I know I am affected particularly strongly by this, but I suspect (with circumstantial evidence) that this is generally true at some level.
Therefor I see ABP as a tool to save the general stress and clutter plaguing the human race. The fact that (mostly) everyone I show ABP to seem to exhibit profound relief at the prospect of a less-cluttered internet is evidence in support of this. Therefor, anything that interrupts the blocking of ads is going to be dead on the vine.
Now, I know people need income and such, but pissing off customers and causing more stress and hastle in the world is not the way to do it.
This brings up a good point, and possibly some inspiration. If the ABP people want to sway the balance back to the websites a bit, they should make it easier for people to whitelist, without annoying them. If you pop stuff up, you will annoy people and not win any friends. I think NoScript has a good idea here, though: a simple popup menu on the status bar. Make it really easy for someone to temporarily allow ads on a site, and easy to allow permanently.
Even with my hard-line stance against ads, a notice in the status bar would not be intrusive. You could put a number in the icon that shows how many elements were blocked, and allow them one at a time. This would not impact my anti-ad stance at all, yet still allow people like you that want to whitelist.
*sigh* - I would have thought, of all people, that people in the ad-blocking business would understand the futility of annoying people on every web site with a popup... especially when you could get most of the benefit without any META tag and just a simple status-bar icon and menu.
</rant>
I'm starting a totally new app that is (hopefully) going to use OpenGL for the display. Not full 3D, but I kind of want the fancy blending features. The problem is the last time I used OpenGL was... a VERY long time ago. It seems to have changed substantially sense then.
I'm totally out of the loop, though, as far as graphics programming goes, so... does anybody know of a decent source for discussion, tutorials, docs, anything on doing modern OpenGL the "right way"? Seeing as this project is starting from scratch, I might as well get it correct from the beginning.
Because it's performance blows on non-standard platforms? Because it's lack of support for 64-bit (well, last I checked) is a pain in the ass? Because it's a constant source of memory leaks and segfaults?
The day I can get rid of that stupid plugin will be a day I celebrate a lot.
UT2004 was a perfect mix of many things.
- The graphics hit a point where things no longer looked blatantly texture-mapped (the DOOM/early-quake problem)
- The pacing was incredible
- The weapons were surprisingly balanced. It's not like Q1 where it's "rockets or nothing"; every weapon is useful at some point.
- Very customizable. (lots of FPS games have that, but it's still a point in UT2004's favor)
- A variety of modes, that were generally well done. Ok, "double dominate" blows, but I still find myself playing a Bombing Run match and such just because it's crazy and different.
- Very gameplay-oriented level design. Sure, some of the maps look totally absurd, but the look that way because they have specific choke-points, carefully designed flow, etc.
- An extra level of polish across the board. I never really found myself saying "if it only had this feature, it'd be perfect". Even the little stuff like settings to change the crosshairs on a per-weapon basis - it showed a level of caring about the gameplay (the "fun"!) that most games skimp on.
I can't speak to how customizable UT3 is, but it(and many other games sense then) skimped on many of these features. The engine is there, though. It is potentially something that could be solved by simply adding a bunch of polish, little features, and playtesting a LOT to get the pacing/balance/etc right.
Maybe we'll get lucky and see a "UT3.5" remake where they get it right... they did show they can "reboot" things once before.
UT3 was just at tech demo.
They completely failed to stay with the feature that made UT2004 a joy to play: pacing. UT2004 is manic. You run fast, the game-flow is fast. There's no room for error, and you get the feeling that standing still for even a second is a fatal mistake. When I first played UT3, though, it felt like everything was slowed way down. They lost the frantic twitch aspect, and therefor lost the feature that make their franchise distinctive.
It's something that started with DOOM/Quake1, really - the "throw realism to the wind, let's just make it fast and fun" theory. UT seemed to be following in that style - doom3 certainly wasn't - but that's over now it seems.
Hell, if they just remade the UT2004 gameplay straight into the UT3 engine, that could be a major win right there. Maybe they'll figure it out from the slow-sales of UT3. Well, one can hope...