Have you possibly tried changing a setting in KDE before?
Seriously, it's not that hard. My desktop is entirely bare, I have a vertical panel with just a task bar, tray, and clock. My plasma theme almost completely lacks gradients. Oxygen is probably least offensive in this regard - it looks great on my high dpi screen, and isn't ridiculously glassed like certain themes are.
Note that hardware that includes a H.264 decoder has already paid for a license. So the browser does not need to pay any fees for the license.
In fact, I think it's generally true that any browser should not have to pay licensing fees - the decoder shouldn't be part of the browser. Major OSes already come with their own video API which either uses a software or hardware decoder.
I thought the whole point of the video tag was to allow in-browser video to reach parity with standalone player, not to force the browser to become a software video decoder too (Flash already does that mighty well).
There's some truth to the fluorescent light complainers... old magnetic ballasts run the light at 60Hz, which can create noticeable flickering (you can see it easier if you look with the side of your vision).
Modern electronic ballasts run at very high (30khz+) frequencies and so don't have this problem.
I think the point was that cell phones weren't allowed, and so any cell phone usage detected could be assumed as cheating, if not at least breaking the rules of the test.
No, there is no law that prevents other people from seeing that you are broadcasting signals, much like there is no laws that make it illegal for a police officer to notice that you are smoking a joint.
Spectrum analyzers don't decrypt the signal, they only check for its presence.
Maybe you completely failed to read the parent post... but the desktop OS and most applications would be native, not emulated. So you're only getting 50% to 75% in certain applications, but everything else runs native.
Granted, Cortex A9's are slow, but certainly not terrible, and unfortunately have had a rather poor showing to most consumers in the incredibly inefficient Android. Because Windows 7 and 8 have hardware accelerated graphics APIs, any applications using them (including all the builtin ones) will probably feel just as snappy as my Core 2 Duo. Obviously, comptationally intensive apps will be slower, but most of those will probably appear recompiled quickly - ARM is especially easy because it can run it little endian mode, in comparision to x86 and PowerPC compatability.
Also, ARM recently announced their Cortex-A15 core, which will probably be making its way into SoC's pretty soon...
On Mac, it's called CoreGraphics.
On Linux, it's called QPainter or Cairo.
On Windows, there are so many APIs that I don't feel like naming them all.
Android's graphics stack with the policy "let's do everything in software" is possibly one of the worst features of the platform. Most smartphones are capable of at least OpenGL ES 1.1, if not 2.0... and if you don't care about 2.0's features, there's only one API your compositor needs to implement to support ALL of the mobile GPU's out there. How's that for fragmentation?
Of course, on dumb framebuffer phones, you'd probably want to implement a software fallback, as most software OpenGL ES implementations would probably be slower.
So Android needs two compositing backends then... how sad for them. Seriously, the fact that I need a 1.2ghz Cortex A9 to smoothly scroll though a list of icons is just pathetic. I mean, a NES can do that at 60fps... the magic of hardware acceleration.
Now draw a circle.
Now draw a bezier curve.
Now draw a circular gradient.
Now draw a button with the text "OK" on it.
If all you want to do is draw some textured quads, it's not terrible. However, textured quads can only get you so far, and what the original poster really wants is unknown.
The "wonky" compilation system isn't bad, and the benefits it provides overcome any ideological "oh my we are corrupting the pure and wonderful C++" feelings that I might have. It's really easy to integrate into CMake, and it doesn't matter with autotools, because everything is hard with autotools.
I also don't know where you got the idea that the VS plugin works only with paid versions. It works fine with the LGPL plugin for me.
While this can be a great thing, if you do this for the sake of separation, you'll do it wrong.
When separating your OS-dependent code, many people make a nice wrapper library for the various toolkits. This is a great way to reinvent the wheel yet again.
However, if you program is oriented around the GUI (a file manager, IRC client, etc), there is no good reason to separate GUI... you'll just end up with a poorly documented GUI abstraction layer. You'd be better off using any other portable GUI toolkit.
As much as the parent comment looks like an ad, I've used Qt and can say that my experience matches what the parent said.
I use Qt Creator as my IDE and it's great with the Designer integration. It's not quite as full-featured in some respects to Visual Studio or KDevelop (Qt works with VS as well), but the integration with the documentation and preprocessor makes up for it.
And the key is of course the documentation. Qt's documentation is possibly the best example of what a doxygen-based documentation can look like. Every class has a multi-paragraph and in-depth description, and most even have one or two code examples.
OpenGL? "Lightweight"? Sure, I suppose because it's all implemented in the system, you don't have to redistribute much, but have you actually ever written anything remotely complicated in raw OpenGL? For anything resembling a GUI, the poster is going to spend months of writing low-level code that's been done a thousand times already.
Qt is heavy, but it's heavy for a reason - it includes a very nice set of tried-and-true widgets, with all the nice features and weird corner cases thought of already. It's also fairly speedy, and even more so if you use QGraphicsView, which can be optionally accelerated via OpenGL for even more speed.
Qt also has nice support for custom widgets. You can subclass any widget, or QWidget, and make anything you want. You can even integrate your custom widgets with Qt Designer, either by promoting a placeholder widget, or writing a Designer plugin so your widget is WYSIWYG.
OpenGL is so low level that everything I talked in the last two paragraphs is completely beyond its scope. Even font rendering is rather arduous, and good luck with nicely word-wrapped, formatted text.
Excuse me, slashdot ate my comment, but to finish the second sentence:
IBM's Blue Gene is made up of a huge pile of fairly low clocked (less than 2ghz) dual core powerpc chips optimized for vectorized floating point operations.
Since when are GPU's not a valid CPU design? In fact, many of the top 500 resemble a GPU much more than your favorite old x86. IBM's Blue Gene is made up of a huge pile of fairly low clocked (
The part of GPU's that is general purpose is pretty much the same thing - a big pile of vector processors and a fat memory pipe.
I would think that the risk of prolonged downtime in a factory that plows through millions of dollars a day would be enough of an incentive for any manager to tighten their security.
Why is AppArmor more user friendly? On Fedora, all the SELinux policies are automatically installed and updated.
For non-Fedora apps, it also has a GUI that tells you when a program was blocked and has a button for you to grant permission to that program.
Lithium batteries don't "explode". The worst are lithium polymer, which vent highly toxic gas and burn uncontrollably... while this would be pretty bad, the forced ventilation system would take care of the gas within a few minutes, and a fire in the passenger area won't take down the plane with relatively modern designs.
Which is sad because a single VGA cable can handle that without thinking about it.
Ever tried 2560x1600 over VGA? Unless you have a really good cable and hardware, I guarantee it will make your eyes bleed. The ringing is pretty terrible on most highres VGA setups I've seen.
So for the last month./ has been running stories about how we are quickly depleting our remaining helium supplies, and now we're floating a TV with 20,000 m^3 of it?
I mean, look at the most popular gaming handheld today... the nintendo DS! It does not run Linux, and so therefore requires no porting work on it at all! I can play portal and crysis on it no problem, as well as Minesweeper from Windows 95. And don't forget Chip's Challenge. Man, that game was awesome.
Seriously, the whole games-are-bad-on-Linux thing is taken out of context. The argument makes sense for desktop systems, not for a portable gaming platform that's for custom designed games. If something like that ran Windows 7, it would be a disaster. And the fact that TFA mentions how OS X would have been a better choice for Panasonic makes it even more laughable. For something like this, a custom API, architecture, and software distribution is what they are after, and it hardly matters how they implement it. There is little chance this will run the X window system, and if it does, I would hardly enjoy using openoffice with a d-pad.
Yeah, that might have been a bit on the extreme side - however, desktops are currently 32% of sales and falling.
Meh, maybe I'm just an embedded person who treasures ARM above all else and thinks that 640k ought to be enough for anyone.
Slashdot Mirror
Have you possibly tried changing a setting in KDE before?
Seriously, it's not that hard. My desktop is entirely bare, I have a vertical panel with just a task bar, tray, and clock. My plasma theme almost completely lacks gradients. Oxygen is probably least offensive in this regard - it looks great on my high dpi screen, and isn't ridiculously glassed like certain themes are.
Note that hardware that includes a H.264 decoder has already paid for a license. So the browser does not need to pay any fees for the license.
In fact, I think it's generally true that any browser should not have to pay licensing fees - the decoder shouldn't be part of the browser. Major OSes already come with their own video API which either uses a software or hardware decoder.
I thought the whole point of the video tag was to allow in-browser video to reach parity with standalone player, not to force the browser to become a software video decoder too (Flash already does that mighty well).
There's some truth to the fluorescent light complainers... old magnetic ballasts run the light at 60Hz, which can create noticeable flickering (you can see it easier if you look with the side of your vision).
Modern electronic ballasts run at very high (30khz+) frequencies and so don't have this problem.
I think the point was that cell phones weren't allowed, and so any cell phone usage detected could be assumed as cheating, if not at least breaking the rules of the test.
No, there is no law that prevents other people from seeing that you are broadcasting signals, much like there is no laws that make it illegal for a police officer to notice that you are smoking a joint.
Spectrum analyzers don't decrypt the signal, they only check for its presence.
It's like watching zombies and vampires fight. No matter who loses, I cheer.
No matter who loses, I run.
WebM can use many of the same acceleration blocks as H.264, it is a matter of writing the codecs that use the hardware.
Hence why it also is likely to run afoul of some H.264 patents. It's a pretty unoriginal ripoff of H.264.
In software. Sloooooooooooooooowwwwwwwwwly.
Maybe you completely failed to read the parent post... but the desktop OS and most applications would be native, not emulated. So you're only getting 50% to 75% in certain applications, but everything else runs native. Granted, Cortex A9's are slow, but certainly not terrible, and unfortunately have had a rather poor showing to most consumers in the incredibly inefficient Android. Because Windows 7 and 8 have hardware accelerated graphics APIs, any applications using them (including all the builtin ones) will probably feel just as snappy as my Core 2 Duo. Obviously, comptationally intensive apps will be slower, but most of those will probably appear recompiled quickly - ARM is especially easy because it can run it little endian mode, in comparision to x86 and PowerPC compatability.
Also, ARM recently announced their Cortex-A15 core, which will probably be making its way into SoC's pretty soon...
How about ARMv5TE and ARMv7-A?
On Mac, it's called CoreGraphics.
On Linux, it's called QPainter or Cairo.
On Windows, there are so many APIs that I don't feel like naming them all.
Android's graphics stack with the policy "let's do everything in software" is possibly one of the worst features of the platform. Most smartphones are capable of at least OpenGL ES 1.1, if not 2.0... and if you don't care about 2.0's features, there's only one API your compositor needs to implement to support ALL of the mobile GPU's out there. How's that for fragmentation? Of course, on dumb framebuffer phones, you'd probably want to implement a software fallback, as most software OpenGL ES implementations would probably be slower.
So Android needs two compositing backends then... how sad for them. Seriously, the fact that I need a 1.2ghz Cortex A9 to smoothly scroll though a list of icons is just pathetic. I mean, a NES can do that at 60fps... the magic of hardware acceleration.
Now draw a circle.
Now draw a bezier curve.
Now draw a circular gradient.
Now draw a button with the text "OK" on it.
If all you want to do is draw some textured quads, it's not terrible. However, textured quads can only get you so far, and what the original poster really wants is unknown.
The "wonky" compilation system isn't bad, and the benefits it provides overcome any ideological "oh my we are corrupting the pure and wonderful C++" feelings that I might have. It's really easy to integrate into CMake, and it doesn't matter with autotools, because everything is hard with autotools.
I also don't know where you got the idea that the VS plugin works only with paid versions. It works fine with the LGPL plugin for me.
While this can be a great thing, if you do this for the sake of separation, you'll do it wrong.
When separating your OS-dependent code, many people make a nice wrapper library for the various toolkits. This is a great way to reinvent the wheel yet again.
However, if you program is oriented around the GUI (a file manager, IRC client, etc), there is no good reason to separate GUI... you'll just end up with a poorly documented GUI abstraction layer. You'd be better off using any other portable GUI toolkit.
As much as the parent comment looks like an ad, I've used Qt and can say that my experience matches what the parent said.
I use Qt Creator as my IDE and it's great with the Designer integration. It's not quite as full-featured in some respects to Visual Studio or KDevelop (Qt works with VS as well), but the integration with the documentation and preprocessor makes up for it.
And the key is of course the documentation. Qt's documentation is possibly the best example of what a doxygen-based documentation can look like. Every class has a multi-paragraph and in-depth description, and most even have one or two code examples.
OpenGL? "Lightweight"? Sure, I suppose because it's all implemented in the system, you don't have to redistribute much, but have you actually ever written anything remotely complicated in raw OpenGL? For anything resembling a GUI, the poster is going to spend months of writing low-level code that's been done a thousand times already.
Qt is heavy, but it's heavy for a reason - it includes a very nice set of tried-and-true widgets, with all the nice features and weird corner cases thought of already. It's also fairly speedy, and even more so if you use QGraphicsView, which can be optionally accelerated via OpenGL for even more speed.
Qt also has nice support for custom widgets. You can subclass any widget, or QWidget, and make anything you want. You can even integrate your custom widgets with Qt Designer, either by promoting a placeholder widget, or writing a Designer plugin so your widget is WYSIWYG.
OpenGL is so low level that everything I talked in the last two paragraphs is completely beyond its scope. Even font rendering is rather arduous, and good luck with nicely word-wrapped, formatted text.
Excuse me, slashdot ate my comment, but to finish the second sentence:
IBM's Blue Gene is made up of a huge pile of fairly low clocked (less than 2ghz) dual core powerpc chips optimized for vectorized floating point operations.
Since when are GPU's not a valid CPU design? In fact, many of the top 500 resemble a GPU much more than your favorite old x86. IBM's Blue Gene is made up of a huge pile of fairly low clocked (
The part of GPU's that is general purpose is pretty much the same thing - a big pile of vector processors and a fat memory pipe.
I would think that the risk of prolonged downtime in a factory that plows through millions of dollars a day would be enough of an incentive for any manager to tighten their security.
Why is AppArmor more user friendly? On Fedora, all the SELinux policies are automatically installed and updated. For non-Fedora apps, it also has a GUI that tells you when a program was blocked and has a button for you to grant permission to that program.
Lithium batteries don't "explode". The worst are lithium polymer, which vent highly toxic gas and burn uncontrollably... while this would be pretty bad, the forced ventilation system would take care of the gas within a few minutes, and a fire in the passenger area won't take down the plane with relatively modern designs.
Which is sad because a single VGA cable can handle that without thinking about it.
Ever tried 2560x1600 over VGA? Unless you have a really good cable and hardware, I guarantee it will make your eyes bleed. The ringing is pretty terrible on most highres VGA setups I've seen.
So for the last month ./ has been running stories about how we are quickly depleting our remaining helium supplies, and now we're floating a TV with 20,000 m^3 of it?
... I don't know what to say.
I mean, look at the most popular gaming handheld today... the nintendo DS! It does not run Linux, and so therefore requires no porting work on it at all! I can play portal and crysis on it no problem, as well as Minesweeper from Windows 95. And don't forget Chip's Challenge. Man, that game was awesome.
Seriously, the whole games-are-bad-on-Linux thing is taken out of context. The argument makes sense for desktop systems, not for a portable gaming platform that's for custom designed games. If something like that ran Windows 7, it would be a disaster. And the fact that TFA mentions how OS X would have been a better choice for Panasonic makes it even more laughable. For something like this, a custom API, architecture, and software distribution is what they are after, and it hardly matters how they implement it. There is little chance this will run the X window system, and if it does, I would hardly enjoy using openoffice with a d-pad.
Yeah, that might have been a bit on the extreme side - however, desktops are currently 32% of sales and falling.
Meh, maybe I'm just an embedded person who treasures ARM above all else and thinks that 640k ought to be enough for anyone.