You can encode GOPs independently. I think the only dependency between GOP encoding processes is bit allocation, which probably works well enough if you simply assign each process an equal share of the total bit budget.
People really need to cut the KDE developers some slack. The devs specifically said that the first releases will be lacking, it's a major rewrite after all. Keeping that in mind, they're doing a wonderful job. Would you rather the release schedule looked like e17's? Also, lots of the people flaming KDE4 sound like the KDE team owed them something... that's really so embarrassing for the open source community.
I was thinking about such a thing in relation to AMD for a while now. Since they have all the core technology required to make a console (cpu, gpu, chipset), they could introduce their own console and build a linux-based environment for it. As they'd be using the x64 arch and linux/opengl, there's no reason their platform couldn't allow for games targetting their console to run on PCs too. Sounds like you're developing a platform they could use for that, to mutual benefits.
Too bad they're bleeding cash right now and working furiously on other projects, so they probably don't have the resources to do so. But if they decided to, there's a high chance that they'd succeed in biting off a nice part of the console market as the next generation comes out.
"Our intention behind the original terms was genuinely geared toward combating piracy"
So paraphrasing one/. user's sig: If it ain't pirated... define "pirated" more broadly?
I might not understand this sophisticated masterplan, but looks to me like it could only make more running copies "pirated".
Stories such as this prove that there is a growing number of applications for massively parallel processors. Currently such consumer level processors require proprietary and often buggy drivers, which are written to render graphics. I could see those processors gaining much wider use if they were as standardized as the x86 instruction set. Audio and video stream processing, scientific simulations, even neural networks could all benefit from such a solution, not to mention multiplatform gaming. And then there'd be no reason for those processors to reside on a "video card".
I thought I didn't need to be more specific because this was a discussion about GPUs, but since you obviously missed the point...
I was referring to vector processing units with dozens of cores like those found in GPUs (shaders), I wish you luck running any "modern" game on a software SSE-based rendering engine.
So when are we going to see (x86/64) motherboards with a socket for a standard processor and a socket for a vector processor?
Couldn't we finally have graphics cards that only give output to the screen and separate vector processors with a standardized interface / instruction set?
This little application completely removed my need for an app launching menu, a run dialog or a graphical file browser.
It's a drop-down terminal supporting tabs, whenever I want to run something I just Win+` to bring it up and Shift+Up to open a new terminal tab.
I've made the step from 6.8 to 7.1 and installed the open source r300 driver from Mesa CVS instead. Glest stopped working, but Google Earth doesn't segfault (as with fglrx) and Tremulous works nice enough, so I'm happy with the driver.
While Linux in general runs quite well, all the good things don't. KDE, Gnome, Firefox, OpenOffice all require big amounts of RAM and CPU. Even Xfce will eat most of your 64MB of RAM, I had trouble installing Xubuntu on a machine with 128MB RAM because the installer deactivated swap and everything grinded to a halt.
Older machines require carefully selected applications and most of the time they will be limited in functionality and usability compared to their KDE or Gnome counterparts. It's hard to setup an environment that runs on old machines and is easy to use at the same time. Distros like DSL aren't friendly enough for a W98 user. Nevertheless it's worth putting all the work into selecting the right WM and applications, because of system stability.
My boss, the owner of the network made me in charge actually:P
But we don't do it for fun, rather because our links have less capacity than the traffic demand. If we didn't shape traffic the things most our clients need wouldn't work responsively. We route 100 users through a single 4Mbit/512kbit DSL in one location and a double such DSL in another location. I was employed because those networks were crawling without traffic shaping.
(Doesn't sound attractive, but we don't charge much, $16/month)
As the admin of a small ISP's Linux routers I'd welcome very much the ability to classify Skype traffic. We do aggressive traffic shaping to let VoIP and games work nicely when the links are saturated with other traffic (mostly P2P garbage). The current l7-filter protocol definition doesn't work for skypeout traffic and it's not very pretty in general. When Skype decides to offer a conntrack helper or at least l7-filter definitions for their convoluted encrypted protocols I might consider suggesting it to our clients. At the moment we advise them to use other VoIP solutions.
In fact I do know a better language, Ada95/2005.
It's simply meant for threading and unconventional compiler optimizations (through the enforcement of constraints), while still being imperative and having a familiar syntax. And it's meant to be compiled unlike Java.
Here's a site about Ada and here's another one.
A good (alas not perfect) Ada95 compiler is included in GCC 3.4.
Slashdot Mirror
http://en.wikipedia.org/wiki/Group_of_pictures
You can encode GOPs independently. I think the only dependency between GOP encoding processes is bit allocation, which probably works well enough if you simply assign each process an equal share of the total bit budget.
People really need to cut the KDE developers some slack. The devs specifically said that the first releases will be lacking, it's a major rewrite after all. Keeping that in mind, they're doing a wonderful job. Would you rather the release schedule looked like e17's?
Also, lots of the people flaming KDE4 sound like the KDE team owed them something... that's really so embarrassing for the open source community.
Now we get the terrible syntax and unfamiliar semantics of Obj-C coupled with the implementation incompatibilities of JavaScript!
Your project looks pretty interesting.
I was thinking about such a thing in relation to AMD for a while now. Since they have all the core technology required to make a console (cpu, gpu, chipset), they could introduce their own console and build a linux-based environment for it. As they'd be using the x64 arch and linux/opengl, there's no reason their platform couldn't allow for games targetting their console to run on PCs too. Sounds like you're developing a platform they could use for that, to mutual benefits.
Too bad they're bleeding cash right now and working furiously on other projects, so they probably don't have the resources to do so. But if they decided to, there's a high chance that they'd succeed in biting off a nice part of the console market as the next generation comes out.
"Our intention behind the original terms was genuinely geared toward combating piracy" /. user's sig: If it ain't pirated... define "pirated" more broadly?
So paraphrasing one
I might not understand this sophisticated masterplan, but looks to me like it could only make more running copies "pirated".
Stories such as this prove that there is a growing number of applications for massively parallel processors. Currently such consumer level processors require proprietary and often buggy drivers, which are written to render graphics. I could see those processors gaining much wider use if they were as standardized as the x86 instruction set. Audio and video stream processing, scientific simulations, even neural networks could all benefit from such a solution, not to mention multiplatform gaming. And then there'd be no reason for those processors to reside on a "video card".
I thought I didn't need to be more specific because this was a discussion about GPUs, but since you obviously missed the point...
I was referring to vector processing units with dozens of cores like those found in GPUs (shaders), I wish you luck running any "modern" game on a software SSE-based rendering engine.
Not quite.
I was thinking of the no-vendor-provided-drivers-needed kind of "standardized".
So when are we going to see (x86/64) motherboards with a socket for a standard processor and a socket for a vector processor?
Couldn't we finally have graphics cards that only give output to the screen and separate vector processors with a standardized interface / instruction set?
This little application completely removed my need for an app launching menu, a run dialog or a graphical file browser.
It's a drop-down terminal supporting tabs, whenever I want to run something I just Win+` to bring it up and Shift+Up to open a new terminal tab.
I've made the step from 6.8 to 7.1 and installed the open source r300 driver from Mesa CVS instead. Glest stopped working, but Google Earth doesn't segfault (as with fglrx) and Tremulous works nice enough, so I'm happy with the driver.
While Linux in general runs quite well, all the good things don't. KDE, Gnome, Firefox, OpenOffice all require big amounts of RAM and CPU. Even Xfce will eat most of your 64MB of RAM, I had trouble installing Xubuntu on a machine with 128MB RAM because the installer deactivated swap and everything grinded to a halt. Older machines require carefully selected applications and most of the time they will be limited in functionality and usability compared to their KDE or Gnome counterparts. It's hard to setup an environment that runs on old machines and is easy to use at the same time. Distros like DSL aren't friendly enough for a W98 user. Nevertheless it's worth putting all the work into selecting the right WM and applications, because of system stability.
My boss, the owner of the network made me in charge actually :P
But we don't do it for fun, rather because our links have less capacity than the traffic demand. If we didn't shape traffic the things most our clients need wouldn't work responsively. We route 100 users through a single 4Mbit/512kbit DSL in one location and a double such DSL in another location. I was employed because those networks were crawling without traffic shaping.
(Doesn't sound attractive, but we don't charge much, $16/month)
As the admin of a small ISP's Linux routers I'd welcome very much the ability to classify Skype traffic. We do aggressive traffic shaping to let VoIP and games work nicely when the links are saturated with other traffic (mostly P2P garbage). The current l7-filter protocol definition doesn't work for skypeout traffic and it's not very pretty in general. When Skype decides to offer a conntrack helper or at least l7-filter definitions for their convoluted encrypted protocols I might consider suggesting it to our clients. At the moment we advise them to use other VoIP solutions.
In fact I do know a better language, Ada95/2005.
It's simply meant for threading and unconventional compiler optimizations (through the enforcement of constraints), while still being imperative and having a familiar syntax. And it's meant to be compiled unlike Java.
Here's a site about Ada and here's another one.
A good (alas not perfect) Ada95 compiler is included in GCC 3.4.
So aye, we are ready for the CMT systems.