Firstly, false dichotomy. We can prepare for problems caused by AGW and reduce CO2 at the same time.
Secondly, nature has been shown to do a pretty darn good job of keeping the climate incredibly stable over many millennia before man for the majority of it's life (ice age transitions are short, relatively), and we even have the capabilities to help nature keep it stable even during external pressures if we take the necessary steps (say by using CO2 as a controlled feedback system).
Thirdly, the non-AGW scenarios that cause significant shifts in climate (including the ones you list) are so incredibly rare in human time-scales that what you say becomes analogous to a doctor considering not treating a patient due to expenses because they might die in a car crash. The universe will eventually become unliveable (AFAWK) - should we give up all our cares due to this?
Lastly, we're not ready to power everything via alternatives, but we're ready and able (if not willing) to power everything with nuclear, alternatives and only as much fossil as nature and us can re-absorb for as long as we need to till we get fusion (or something that beats it).
57% of Italians vote to pollute the World's atmosphere (cos there's no way in they'll get it back via renewables if they don't ban fossil fuels too). I want my vote on what is done to my atmosphere.
And if 60% of people voted to destroy the world, we should always ignore those 57%.
Why does everyone always make the assumption that hypocrisy = bad?
When you believe in something you have 2 socially acceptable alternatives: 1. State you believe in it and voluntarily make the sacrifices that would be required if everyone believed in it. 2. Don't state you believe in it so that you don't have to make the sacrifices in #1.
When presented with these options, so many people pick #2, and we all suffer for it.
I hate inheritance. I believe it to be the root of so much evil and unfairness. I will vote to reduce it. I may yet campaign against it. Yet if you tell me I should refuse it when it comes along, I will laugh and take it. A weak person might simply lie and say they like inheritance. If I choose to forego it, people will see me suffer for it and be unwilling to support my cause.
Things like this don't change by masses of people volunteering. They change by laws written by rational elected government.
If you want change, stop deceiving yourself that people who can provide us with solutions or analysis should suffer for their service.
As much as drivers cause problems on Linux, using them as a defense for Open Source failings to provide stable and quality libraries and programs is pathetic... It is part of GNOME's job to make sure their library works with the drivers out there.
I have to disagree here. Just because it's your job does NOT mean when you achieve slightly less (even if your progress is more impressive) than your competitors while being severely handicapped by forces outside your control that you can't blame those forces.
If the GFX drivers and/or architectures were open source, linux would have better performance, both natively and under wine.
In fact, in an alternative universe where linux graphics drivers had been open source for years, linux could possibly have the best graphics performance of any OS.
This defense isn't pathetic, it's 100% accurate. And it needs to be talked about, and blamed, if we want to get better graphics. I would go as far as saying this issue is the #1 thing holding linux back.
Computers function in a different way to physical objects.
Making people accept this is far, far simpler than trying to force every computer idea into a real-world analog.
Stop treating a computer like a car or bike - you can't learn it in a week and you'll be spending a lot of your life using one so get it right. Even if you're old you can learn (and it'll do your mind good too).
Everyone can name ways that an application should be simpler. Trouble is, ask 100 people and you'll get 100 different answers, many of which will be mutually exclusive.
I would think the increase in terrorist activity due to abuses (profiling, body scanners) becoming widely known plus the increase due to terrorists showing they're successfully causing fear (all these new security measures show we're scared) would significantly outweigh the increase in terrorist activity due to terrorists showing they're successfully killing people. I'm not even entirely sure whether the latter would be positive.
If you kill/catch X terrorists but in the process create X+1 terrorists, you're better off not doing what you did. And that's without even considering any harm (including TSA annoyance) you're causing to innocents with your measures.
There's no reason to be locked to an array of arrays of characters as the only code format. Program code is inherently tree-structured.
Recent Blizzard editors (WC3, SC2), they have a tree-based system for their code. I'm not sure if there are many other examples, but IMO this is the way forward. Pluses: - No compilation errors. - Faster compilation since parsing is already done. - No typos. - Perfect code-completion / syntax-highlighting. - No arguments about style guidelines because there's nothing but content. No whitespace etc. Style can be set from your end in your editor. - Changing all copies of an identifier name is instant and flawless. - Smaller files. Downsides: - Can't use regular text editors. - Difficult to work backwards (can't write a variable before its declared). - Catch 22 when there's no editors that deal with the format. Also, format wars. - Included files need to be read by editor.
There'll be more pluses and minuses I'm sure.
There's nothing stopping anyone from making a C++ (or C++-esque) frontend like this. There's nothing stopping these editors from being as quick to use as text editors. In fact, they should be way faster.
I'm all for someone developing a tool/app that alters window positions, volume etc when various inputs generate specific events. Of course it should be highly customizable.
However, I'd hope it's built as a standalone distro-independent (or platform-independent at best) tool. TFA doesn't really point one way or the other on this.
I'd also hope that no special-purpose development is done to Ubuntu itself solely to work with this tool. A tool like that shouldn't need distro-specific help.
Personally, I'd have no interest in a tool like this. Voice commands, gestures etc to control the UI are fine (as long as they never ever cause false-positives) only because they're deliberate actions.
I'm not entirely sure I'm using the right OS for me, though.
> Flash is no worse on 32-Bit Linux than any other platform. FTFY
Even default 64-bit Ubuntu installations have many flash issues. Adobe is planning to release a 64 bit version, but it's been a long time coming and no sign on the horizon.
Yet far more complex 32-bit apps in WinE run fine.
There are many issues in the world that can best be solved by people being nothing like you.
Simply put: If the consumer doesn't reward good deeds, business (with it's legal obligation to maximize profit) won't do as many good deeds.
In this case, your pragmatism, along with that of millions of others, is partly to blame for closed source drivers are so common. You yourself probably have lower quality graphics or operating system functionality due to this.
While it's fine to be pragmatic in many circumstances, your stance that buying on principle isn't morally above buying through total pragmatism is, IMO, ultimately harmful.
Blood diamonds are an extreme example of what comes from mass pragmatism. Would you knowingly buy one it it was better value?
1) Standard Video Format:
A fully open Firefox cannot offer Flash.
2) Robust video streaming:
Final spec will probably have this, as it is sorely needed.
3) Content Protection:
"Content Protection" cannot offer Content Protection either.
4) Encapsulation + Embedding:
Frames? Oh, I forgot, you want to be able to make my browser do things that I, the one running the browser, don't want it too.
5) Fullscreen Video:
If the browser doesn't implement this, a plugin could.
6) Camera and Microphone access:
"Every day, thousands of users record videos directly to YouTube from within their browser using webcams, which would not be possible without Flash technology."
What makes recording from streaming webcams impossible without Flash? Also, how is this relevant to a discussion on browser video display?
And I'll add a list of things that flash can't do that HTML5 video (+ plugins if necessary) should be able to (unless the spec authors suck):
- Arbitrary video codecs.
- Arbitrary resizing in browsers.
- Arbitrary speed control.
- Arbitrary video filters.
Actually, I have a very different view of where we might be without dedicated graphics hardware.
The introduction of hardware acceleration removed the incentive to develop real-time software rendering techniques. All 3D hardware has been designed for just one rendering technique: Drawing triangles one at a time with a depth buffer. Couple this with the problem that for a long time none of the major graphics architectures were open (which prevented any APIs apart from OpenGL and DirectX to be developed), and you're left with a very stagnant set of usable rendering techniques.
There hasn't been enough effort in real-time ray tracing, and very little in combined approaches, (eg using the standard per-triangle method to compute the 1st ray when performing ray tracing). It's very rare to hear news of new rendering algorithms being developed, and yet there's plenty of scope for more.
We've also been limited to not using procedurally generated models, given only a few arbitrary blending modes (thus making transparency far uglier), been forced to use only a handful of supported scalar types (which varies depending on whether you're calculating vectors or pixels), and a million other issues that programmers would've avoided by using a CPU. And your games and applications have surely suffered.
At the bottom I will describe a few techniques that I would like to use, which would be possible on a fully programmable CPU, but are not (AFAIK, at least they weren't a year ago) possible on current hardware.
Now, compare the reality above with what we would have had if we hadn't used GPUs: - We'd've focused very early on on high degrees of hardware parallelism, meaning overall computing power would be higher and rendering frame rates would probably be comparable to present. - We'd've developed many new and superior rendering techniques, like those mentioned above. - We'd've been able to write our own APIs, instead of having to choose between Windows-only (DirectX) or inferior feature set (OpenGL), both of which have less than optimal coding interfaces. - And lastly, there'd be far more Linux gaming as developers would have no reason to force a proprietary single-OS API on us (DirectX), which is the primary reason for the lack of uptake of Linux amongst gamers.
Now we're heading back in the right direction: - GPUs are becoming more general purpose chips (CUDA etc). - We're possibly seeing the first steps in a return to memory sharing between graphics and applications (like with Larrabee). Of course we need to increase memory bandwidth to make this worthwhile. - Next we'll get access to the raw instruction sets, and the ability compile and run arbitrary code on these chips. And then we'll be back to square one - (specialist) CPUs doing our graphics. Yet we could've gotten here far earlier if we didn't take the GPU diversion.
In my opinion, what we really did is we sold out on the long future of rendering and gaming for a few years of good times.
ASIDE: Two (of thousands of) techniques that we could be using now, if it weren't for GPUs.
1: Per-pixel curved surfaces (Eg spheres, cones, spline planes). For these you just need a programmable depth value and a programmable "edge" shader that allows you to specify the start and end pixels of each line.
Eg: A sphere 100 pixels round in an orthographic projection can be drawn in 1 pass with no unnecessary pixel calculations by: Calculating the edge start and end points per line as sqrt((50^2) - (Y - CentreY)^2). Per pixel, calculate the Z by CentreZ - sqrt((50^2) - ((X - CentreX)^2) - ((Y - CentreY)^2)). It gives a perfectly smooth sphere and it renders far faster than multiple triangles.
Last time I tried, with OpenGL, about a year ago, the above was impossible, although I did make it work partially by ignoring depth and using a triangle that fully enclosed the sphere.
2: Subtraction from surface. (Not sure if there is an official name).
Slashdot Mirror
Firstly, false dichotomy. We can prepare for problems caused by AGW and reduce CO2 at the same time.
Secondly, nature has been shown to do a pretty darn good job of keeping the climate incredibly stable over many millennia before man for the majority of it's life (ice age transitions are short, relatively), and we even have the capabilities to help nature keep it stable even during external pressures if we take the necessary steps (say by using CO2 as a controlled feedback system).
Thirdly, the non-AGW scenarios that cause significant shifts in climate (including the ones you list) are so incredibly rare in human time-scales that what you say becomes analogous to a doctor considering not treating a patient due to expenses because they might die in a car crash.
The universe will eventually become unliveable (AFAWK) - should we give up all our cares due to this?
Lastly, we're not ready to power everything via alternatives, but we're ready and able (if not willing) to power everything with nuclear, alternatives and only as much fossil as nature and us can re-absorb for as long as we need to till we get fusion (or something that beats it).
57% of Italians vote to pollute the World's atmosphere (cos there's no way in they'll get it back via renewables if they don't ban fossil fuels too).
I want my vote on what is done to my atmosphere.
And if 60% of people voted to destroy the world, we should always ignore those 57%.
Democracy isn't everything.
Why does everyone always make the assumption that hypocrisy = bad?
When you believe in something you have 2 socially acceptable alternatives:
1. State you believe in it and voluntarily make the sacrifices that would be required if everyone believed in it.
2. Don't state you believe in it so that you don't have to make the sacrifices in #1.
When presented with these options, so many people pick #2, and we all suffer for it.
I hate inheritance. I believe it to be the root of so much evil and unfairness. I will vote to reduce it. I may yet campaign against it. Yet if you tell me I should refuse it when it comes along, I will laugh and take it. A weak person might simply lie and say they like inheritance. If I choose to forego it, people will see me suffer for it and be unwilling to support my cause.
Things like this don't change by masses of people volunteering. They change by laws written by rational elected government.
If you want change, stop deceiving yourself that people who can provide us with solutions or analysis should suffer for their service.
Stop being hypocrisy bigots please.
As much as drivers cause problems on Linux, using them as a defense for Open Source failings to provide stable and quality libraries and programs is pathetic ... It is part of GNOME's job to make sure their library works with the drivers out there.
I have to disagree here. Just because it's your job does NOT mean when you achieve slightly less (even if your progress is more impressive) than your competitors while being severely handicapped by forces outside your control that you can't blame those forces.
If the GFX drivers and/or architectures were open source, linux would have better performance, both natively and under wine.
In fact, in an alternative universe where linux graphics drivers had been open source for years, linux could possibly have the best graphics performance of any OS.
This defense isn't pathetic, it's 100% accurate. And it needs to be talked about, and blamed, if we want to get better graphics. I would go as far as saying this issue is the #1 thing holding linux back.
Having at least 1200px vertically as standard and 1536px for less than $500. Nowdays you often have to pay over $1000 to get more than 1200px.
To me it seems widescreen simply meant, to most manufacturers, removing rows of pixels.
Rotatable monitors are nice, but 1080px horizontally is also quite annoying.
Computers function in a different way to physical objects.
Making people accept this is far, far simpler than trying to force every computer idea into a real-world analog.
Stop treating a computer like a car or bike - you can't learn it in a week and you'll be spending a lot of your life using one so get it right. Even if you're old you can learn (and it'll do your mind good too).
Everyone can name ways that an application should be simpler. Trouble is, ask 100 people and you'll get 100 different answers, many of which will be mutually exclusive.
I would think the increase in terrorist activity due to abuses (profiling, body scanners) becoming widely known plus the increase due to terrorists showing they're successfully causing fear (all these new security measures show we're scared) would significantly outweigh the increase in terrorist activity due to terrorists showing they're successfully killing people. I'm not even entirely sure whether the latter would be positive.
If you kill/catch X terrorists but in the process create X+1 terrorists, you're better off not doing what you did. And that's without even considering any harm (including TSA annoyance) you're causing to innocents with your measures.
There's no reason to be locked to an array of arrays of characters as the only code format. Program code is inherently tree-structured.
Recent Blizzard editors (WC3, SC2), they have a tree-based system for their code. I'm not sure if there are many other examples, but IMO this is the way forward.
Pluses:
- No compilation errors.
- Faster compilation since parsing is already done.
- No typos.
- Perfect code-completion / syntax-highlighting.
- No arguments about style guidelines because there's nothing but content. No whitespace etc. Style can be set from your end in your editor.
- Changing all copies of an identifier name is instant and flawless.
- Smaller files.
Downsides:
- Can't use regular text editors.
- Difficult to work backwards (can't write a variable before its declared).
- Catch 22 when there's no editors that deal with the format. Also, format wars.
- Included files need to be read by editor.
There'll be more pluses and minuses I'm sure.
There's nothing stopping anyone from making a C++ (or C++-esque) frontend like this.
There's nothing stopping these editors from being as quick to use as text editors. In fact, they should be way faster.
I'm all for someone developing a tool/app that alters window positions, volume etc when various inputs generate specific events. Of course it should be highly customizable.
However, I'd hope it's built as a standalone distro-independent (or platform-independent at best) tool. TFA doesn't really point one way or the other on this.
I'd also hope that no special-purpose development is done to Ubuntu itself solely to work with this tool. A tool like that shouldn't need distro-specific help.
Personally, I'd have no interest in a tool like this.
Voice commands, gestures etc to control the UI are fine (as long as they never ever cause false-positives) only because they're deliberate actions.
I'm not entirely sure I'm using the right OS for me, though.
> Flash is no worse on 32-Bit Linux than any other platform.
FTFY
Even default 64-bit Ubuntu installations have many flash issues.
Adobe is planning to release a 64 bit version, but it's been a long time coming and no sign on the horizon.
Yet far more complex 32-bit apps in WinE run fine.
Apologies, this was posted as a reply to: http://news.slashdot.org/comments.pl?sid=1761364&cid=33320798 But Slashdot thought better of it... or something like that anyway :P
Mod me to oblivion plz.
There are many issues in the world that can best be solved by people being nothing like you.
Simply put: If the consumer doesn't reward good deeds, business (with it's legal obligation to maximize profit) won't do as many good deeds.
In this case, your pragmatism, along with that of millions of others, is partly to blame for closed source drivers are so common. You yourself probably have lower quality graphics or operating system functionality due to this.
While it's fine to be pragmatic in many circumstances, your stance that buying on principle isn't morally above buying through total pragmatism is, IMO, ultimately harmful.
Blood diamonds are an extreme example of what comes from mass pragmatism. Would you knowingly buy one it it was better value?
Apologies for somehow allowing my spaces to be eaten during submission - BTW anyone know why (Firefox 3.6.6 - Ubuntu 10.4 64bit)?
1) Standard Video Format: A fully open Firefox cannot offer Flash. 2) Robust video streaming: Final spec will probably have this, as it is sorely needed. 3) Content Protection: "Content Protection" cannot offer Content Protection either. 4) Encapsulation + Embedding: Frames? Oh, I forgot, you want to be able to make my browser do things that I, the one running the browser, don't want it too. 5) Fullscreen Video: If the browser doesn't implement this, a plugin could. 6) Camera and Microphone access: "Every day, thousands of users record videos directly to YouTube from within their browser using webcams, which would not be possible without Flash technology." What makes recording from streaming webcams impossible without Flash? Also, how is this relevant to a discussion on browser video display? And I'll add a list of things that flash can't do that HTML5 video (+ plugins if necessary) should be able to (unless the spec authors suck): - Arbitrary video codecs. - Arbitrary resizing in browsers. - Arbitrary speed control. - Arbitrary video filters.
However, The Lancet just published a study by a well-known British surgeon which found these drugs frequently caused MMR.
Actually, I have a very different view of where we might be without dedicated graphics hardware.
The introduction of hardware acceleration removed the incentive to develop real-time software rendering techniques.
All 3D hardware has been designed for just one rendering technique: Drawing triangles one at a time with a depth buffer.
Couple this with the problem that for a long time none of the major graphics architectures were open (which prevented any APIs apart from OpenGL and DirectX to be developed), and you're left with a very stagnant set of usable rendering techniques.
There hasn't been enough effort in real-time ray tracing, and very little in combined approaches, (eg using the standard per-triangle method to compute the 1st ray when performing ray tracing). It's very rare to hear news of new rendering algorithms being developed, and yet there's plenty of scope for more.
We've also been limited to not using procedurally generated models, given only a few arbitrary blending modes (thus making transparency far uglier), been forced to use only a handful of supported scalar types (which varies depending on whether you're calculating vectors or pixels), and a million other issues that programmers would've avoided by using a CPU. And your games and applications have surely suffered.
At the bottom I will describe a few techniques that I would like to use, which would be possible on a fully programmable CPU, but are not (AFAIK, at least they weren't a year ago) possible on current hardware.
Now, compare the reality above with what we would have had if we hadn't used GPUs:
- We'd've focused very early on on high degrees of hardware parallelism, meaning overall computing power would be higher and rendering frame rates would probably be comparable to present.
- We'd've developed many new and superior rendering techniques, like those mentioned above.
- We'd've been able to write our own APIs, instead of having to choose between Windows-only (DirectX) or inferior feature set (OpenGL), both of which have less than optimal coding interfaces.
- And lastly, there'd be far more Linux gaming as developers would have no reason to force a proprietary single-OS API on us (DirectX), which is the primary reason for the lack of uptake of Linux amongst gamers.
Now we're heading back in the right direction:
- GPUs are becoming more general purpose chips (CUDA etc).
- We're possibly seeing the first steps in a return to memory sharing between graphics and applications (like with Larrabee). Of course we need to increase memory bandwidth to make this worthwhile.
- Next we'll get access to the raw instruction sets, and the ability compile and run arbitrary code on these chips.
And then we'll be back to square one - (specialist) CPUs doing our graphics.
Yet we could've gotten here far earlier if we didn't take the GPU diversion.
In my opinion, what we really did is we sold out on the long future of rendering and gaming for a few years of good times.
ASIDE: Two (of thousands of) techniques that we could be using now, if it weren't for GPUs.
1: Per-pixel curved surfaces (Eg spheres, cones, spline planes).
For these you just need a programmable depth value and a programmable "edge" shader that allows you to specify the start and end pixels of each line.
Eg:
A sphere 100 pixels round in an orthographic projection can be drawn in 1 pass with no unnecessary pixel calculations by:
Calculating the edge start and end points per line as sqrt((50^2) - (Y - CentreY)^2).
Per pixel, calculate the Z by CentreZ - sqrt((50^2) - ((X - CentreX)^2) - ((Y - CentreY)^2)).
It gives a perfectly smooth sphere and it renders far faster than multiple triangles.
Last time I tried, with OpenGL, about a year ago, the above was impossible, although I did make it work partially by ignoring depth and using a triangle that fully enclosed the sphere.
2: Subtraction from surface. (Not sure if there is an official name).