To me, this had a lot of Apocalypse Now and The Last Samurai to it. The racial themes were supposed to run deep, but in my opinion, fell somewhat flat. It ended up being a movie about war and Stockholm syndrome, not about racial prejudice. Sure, there are racist characters, but they're not there to be racist; they're there to make an entrepreneurial living, or to enjoy the smell of napalm in the morning.
The term "gone native" actually shows up in this movie, which I found fascinating. Here, we're given a chance to show Kurtz's side of the story; we can see a little bit of his reasoning as well as an understanding of his insanity and defection. Just like Kurtz, our heroes decided to defect for reasons stronger than might ever have been apparent, but which are never strongly touched upon within the actual movie.
Also keep in mind that a lack of technology was not important or emphasized in the final scenes; in fact, I could point to quite a few spots where human technology was required for the day to be saved. Without spoilers, I can't elaborate, but anybody else who has seen it knows what I'm referring to.
There is no LLVM backend for AMD/ATI cards. Of the few of us that actually understand ATI hardware, most of us are working on other things besides GPGPU. Sorry.
Nouveau's KMS is in Fedora, and behaves much better than even just a few months ago with respect to suspend and resume. Also that was written by marcheu, whose attitude is very different from darktama, the Redhat guy that actually made KMS happen.
Xrandr support for nouveau sees the occasional bug, but nothing surprising. Since the kernel modules aren't upstream, the Mesa/Gallium code isn't officially supported, but it's fairly usable too.
And of course they have no idea what they're doing; these chipsets have never been documented outside of this project and they've been running blind for the past few years.
Works fine. Compiz doesn't enjoy multicard terribly well, since it only does one GLX context, but yeah, it works.
The magic incantation to get your cards detected is Xorg -configure, and you should be aware that both fglrx and nvidia are broken rather hard on multicard, so use open drivers.
How is X not documented? For users, xorg.conf and all of the X servers have man pages, as well as pages for each in-tree server module. GLX is the only one where documentation doesn't really correlate to what the module's actually used for, and we normally refer people to the Red Book for that.
For programmers, a fair amount of Xlib is documented, and XCB is fully documented.
Also, patches welcome, if you actually have things you can point to in X that you'd like fixed.
I'll leave it up to you to deduce my SSN; it's not terribly difficult. I'm not posting it because I'd like to hold on to what little cash I've got, although if you're going to defraud a college student with empty pockets...
Data is unlimited, tethering's capped at 5GiB, as many people noted. Also my Droid seems to do exactly what it was advertised as being able to do; it's Android-based and fairly unlocked, although you've still gotta do Android mods if you want things like overclocking or non-Verizon-based tethering.
Anyway, yeah, Verizon's sometimes underhanded, but I put the screws to the salespeople to make sure they weren't shitting me, and it turns out that this really is as good of a deal as it appears. It's a legit phone with a legit contract, it really does play back Vorbis audio, it really is DRM-free, etc.
Also tethering is quite overrated and if you really really really need it, you should have your employer shell out the cash for a tethering dongle instead of abusing your cell phone. Or, y'know, learn to live without Internets while you're driving through deserts in the middle of nowhere.
Talking to a couple guys learning ELF and Linux' SO loader, I got the impression that ELF already supports these multiple code segments, and that adding in headers to denote the arch is really simple. I'll see if I can get more evidence for this.
We're way ahead of fglrx and nvidia in terms of 2D performance. You can talk up the blobs all you want, but we're definitely making good progress and we have some features the blobs just don't have. There's a good reason that AMD's deprecated their blob for older chipsets now.
Also, there are three AMD people, two Red Hat people, two from TG/VMare, and about five independent coders (including myself) working on Radeon-related code. Hardly an AMD-led project. Go ahead, check the copyright on mesa/src/gallium/drivers/r300. I dare you. While you're at it, check the copyright on the classic driver in mesa/src/mesa/drivers/dri/r300 and note how nearly all of it was written by non-AMD people.
Don't use threads. Use multiprocessing for concurrency and Twisted for asynchronous I/O.
If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.
PyPy is far from dead. They've got a JIT working for x86 assembly that matches NumPy in some tests.
Learning Twisted is so much easier than rolling your own networking mini-library. Sure, a lot of people are kicking and screaming in the beginning, but once they actually sit down and start coding, they usually say something like, "Oh, hey, this is nice."
Actually, for tight loops, CPython (the main implementation) is a whopping 200x slower than C.
Reasons why tight loop speed doesn't matter: - This isn't the kernel. Tight loops don't occur much. If you're polling or spinlocking, stop it and go read up on select, or switch up to a high-performance async library like Twisted. If you're doing number-crunching, use things like comprehensions or multiprocessing.Pool.map to accelerate your math. (Or use both; the former gets a speed boost in implementation, while the latter is concurrent across multiple processors.) - Programs are usually not CPU-bound. Profilers tell all, really. Games are usually GPU-bound, unless they're written without a separate sound thread, in which case they get I/O-bound. Webservers are usually I/O-bound, and spend most of their time in select/epoll/etc. waiting for connections. - Implementations can and will get fast, eventually. Unladen Swallow is one thing being talked about, but PyPy is also worth mentioning. The former is a bunch of CPython improvments, the latter is a JIT Python interpreter that matches C code for tight loop speed.
I know this is not a popular idea with a lot of people, particularly those working in places where "OMG speed is critical," but Python's execution speed just doesn't matter compared to its readability and time/LOCs required to get up off the ground and running.
EXA is the backend acceleration we use right now in X. It works.
Full EXA is provided for radeon, nouveau, and intel, the Big Three. A lot of esoteric chips are supported too. They might not be super-fast, but they're still fast enough to do nearly anything. (Getting that vaunted 1m glyphs/sec is tough though.)
Flash is a piece of shit. I most certainly can and will blame Adobe for not putting more than one person on the Linux Flash team, and I can point to the incomplete, buggy, largely hacked-up Gnash as an example of a software rasterizer that moves much faster than Flash despite also being lame.
Oh, yes. The pain of an extra $60 in my wallet! I don't know how I'll possibly be able to carry around that kind of weight! I might actually have to eat food that I purchase from the market! I might have to attract a female mate and take her on a date! The possibilities are paralyzingly endless!
Moreover, I don't know what I'll do with my spare time! How will I ever be able to spend my nights slaughtering Zealots with my armies of 'Lings and Hydras without StarCraft II at my side? The feeling of excitement as I build my economy up, the mix of anger and anticipation as I hear the monotone voice in my ear declaring, "Nuclear launch detected." How will I ever have the StarCraft experience without StarCraft II?
Seriously, you're going to complain about shaders? Shaders can be written by hand by anybody that knows basic algebra. It's not that hard.
Or, if you're a big bad gaming company, you can probably afford a license for AMD and nVidia's shader compilers, which do all the maths for you and do some optimizing too.
AMD/ATI only offers GPU-accelerated decoding and presentation through the XvBA API, which is only available to their enterprise and embedded customers. People seem to always forget that fglrx is for enterprise (FireGL) people first.
Wait for the officially supported open-source radeon drivers to get support for GPU-accelerated decoding, or (God forbid!) contribute some code. In particular, if somebody would write a VDPAU frontend for Gallium3D...
Slashdot Mirror
To me, this had a lot of Apocalypse Now and The Last Samurai to it. The racial themes were supposed to run deep, but in my opinion, fell somewhat flat. It ended up being a movie about war and Stockholm syndrome, not about racial prejudice. Sure, there are racist characters, but they're not there to be racist; they're there to make an entrepreneurial living, or to enjoy the smell of napalm in the morning.
The term "gone native" actually shows up in this movie, which I found fascinating. Here, we're given a chance to show Kurtz's side of the story; we can see a little bit of his reasoning as well as an understanding of his insanity and defection. Just like Kurtz, our heroes decided to defect for reasons stronger than might ever have been apparent, but which are never strongly touched upon within the actual movie.
Also keep in mind that a lack of technology was not important or emphasized in the final scenes; in fact, I could point to quite a few spots where human technology was required for the day to be saved. Without spoilers, I can't elaborate, but anybody else who has seen it knows what I'm referring to.
There is no LLVM backend for AMD/ATI cards. Of the few of us that actually understand ATI hardware, most of us are working on other things besides GPGPU. Sorry.
Nouveau's KMS is in Fedora, and behaves much better than even just a few months ago with respect to suspend and resume. Also that was written by marcheu, whose attitude is very different from darktama, the Redhat guy that actually made KMS happen.
Xrandr support for nouveau sees the occasional bug, but nothing surprising. Since the kernel modules aren't upstream, the Mesa/Gallium code isn't officially supported, but it's fairly usable too.
And of course they have no idea what they're doing; these chipsets have never been documented outside of this project and they've been running blind for the past few years.
1) You had an i915, or maybe an r200. Lots of turn-of-the-millennium chipsets couldn't deal with total framebuffers larger than 2048x2048.
2) NOTOURBUG. Blame KDE. Or blame us for not shoving the xrandr manual down their throats; whichever.
3) fglrx and nvidia are *not* our fault or our problem. Go bitch at nVidia for a while instead.
Works fine. Compiz doesn't enjoy multicard terribly well, since it only does one GLX context, but yeah, it works.
The magic incantation to get your cards detected is Xorg -configure, and you should be aware that both fglrx and nvidia are broken rather hard on multicard, so use open drivers.
Use nouveau instead of nvidia, and do Xorg -configure, and you should be golden. The big thing is that nvidia won't do multicard with non-nV hardware.
I have two ATI chipsets in my current work box, and everything works just great.
How is X not documented? For users, xorg.conf and all of the X servers have man pages, as well as pages for each in-tree server module. GLX is the only one where documentation doesn't really correlate to what the module's actually used for, and we normally refer people to the Red Book for that.
For programmers, a fair amount of Xlib is documented, and XCB is fully documented.
Also, patches welcome, if you actually have things you can point to in X that you'd like fixed.
DF also requires patience, luck, and a penchant for dealing with elephants.
Corbin D. Simpson
975 NW Garfield, Corvallis, OR 97330
I'll leave it up to you to deduce my SSN; it's not terribly difficult. I'm not posting it because I'd like to hold on to what little cash I've got, although if you're going to defraud a college student with empty pockets...
Data is unlimited, tethering's capped at 5GiB, as many people noted. Also my Droid seems to do exactly what it was advertised as being able to do; it's Android-based and fairly unlocked, although you've still gotta do Android mods if you want things like overclocking or non-Verizon-based tethering.
Anyway, yeah, Verizon's sometimes underhanded, but I put the screws to the salespeople to make sure they weren't shitting me, and it turns out that this really is as good of a deal as it appears. It's a legit phone with a legit contract, it really does play back Vorbis audio, it really is DRM-free, etc.
Also tethering is quite overrated and if you really really really need it, you should have your employer shell out the cash for a tethering dongle instead of abusing your cell phone. Or, y'know, learn to live without Internets while you're driving through deserts in the middle of nowhere.
Hey, whatever gets us more page views.
(If you haven't been to http://x.org/ , you might not get the joke.)
Talking to a couple guys learning ELF and Linux' SO loader, I got the impression that ELF already supports these multiple code segments, and that adding in headers to denote the arch is really simple. I'll see if I can get more evidence for this.
We're way ahead of fglrx and nvidia in terms of 2D performance. You can talk up the blobs all you want, but we're definitely making good progress and we have some features the blobs just don't have. There's a good reason that AMD's deprecated their blob for older chipsets now.
Also, there are three AMD people, two Red Hat people, two from TG/VMare, and about five independent coders (including myself) working on Radeon-related code. Hardly an AMD-led project. Go ahead, check the copyright on mesa/src/gallium/drivers/r300. I dare you. While you're at it, check the copyright on the classic driver in mesa/src/mesa/drivers/dri/r300 and note how nearly all of it was written by non-AMD people.
Note how they're also both slower than CPython.
Jython does it by using JVM for threading, IronPython uses one of the many GIL-less patchsets which degrade performance but still permit threading.
Don't use threads. Use multiprocessing for concurrency and Twisted for asynchronous I/O.
If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.
PyPy is far from dead. They've got a JIT working for x86 assembly that matches NumPy in some tests.
As we say in #python, "Programming is hard!"
Learning Twisted is so much easier than rolling your own networking mini-library. Sure, a lot of people are kicking and screaming in the beginning, but once they actually sit down and start coding, they usually say something like, "Oh, hey, this is nice."
There's a reason it's popular.
Actually, for tight loops, CPython (the main implementation) is a whopping 200x slower than C.
Reasons why tight loop speed doesn't matter:
- This isn't the kernel. Tight loops don't occur much. If you're polling or spinlocking, stop it and go read up on select, or switch up to a high-performance async library like Twisted. If you're doing number-crunching, use things like comprehensions or multiprocessing.Pool.map to accelerate your math. (Or use both; the former gets a speed boost in implementation, while the latter is concurrent across multiple processors.)
- Programs are usually not CPU-bound. Profilers tell all, really. Games are usually GPU-bound, unless they're written without a separate sound thread, in which case they get I/O-bound. Webservers are usually I/O-bound, and spend most of their time in select/epoll/etc. waiting for connections.
- Implementations can and will get fast, eventually. Unladen Swallow is one thing being talked about, but PyPy is also worth mentioning. The former is a bunch of CPython improvments, the latter is a JIT Python interpreter that matches C code for tight loop speed.
I know this is not a popular idea with a lot of people, particularly those working in places where "OMG speed is critical," but Python's execution speed just doesn't matter compared to its readability and time/LOCs required to get up off the ground and running.
~ C.
Write some code, then get back to us on that. 'k, thanks, bye.
[citations needed]
EXA is the backend acceleration we use right now in X. It works.
Full EXA is provided for radeon, nouveau, and intel, the Big Three. A lot of esoteric chips are supported too. They might not be super-fast, but they're still fast enough to do nearly anything. (Getting that vaunted 1m glyphs/sec is tough though.)
Flash is a piece of shit. I most certainly can and will blame Adobe for not putting more than one person on the Linux Flash team, and I can point to the incomplete, buggy, largely hacked-up Gnash as an example of a software rasterizer that moves much faster than Flash despite also being lame.
Don't even get me started on Flash Video.
Oh, yes. The pain of an extra $60 in my wallet! I don't know how I'll possibly be able to carry around that kind of weight! I might actually have to eat food that I purchase from the market! I might have to attract a female mate and take her on a date! The possibilities are paralyzingly endless!
Moreover, I don't know what I'll do with my spare time! How will I ever be able to spend my nights slaughtering Zealots with my armies of 'Lings and Hydras without StarCraft II at my side? The feeling of excitement as I build my economy up, the mix of anger and anticipation as I hear the monotone voice in my ear declaring, "Nuclear launch detected." How will I ever have the StarCraft experience without StarCraft II?
What's that, you say? Most people playing WoW have Internet connections? Unbelievable!
Seriously, though, I'm not putting down money for SC2. This is just not okay.
Seriously, you're going to complain about shaders? Shaders can be written by hand by anybody that knows basic algebra. It's not that hard.
Or, if you're a big bad gaming company, you can probably afford a license for AMD and nVidia's shader compilers, which do all the maths for you and do some optimizing too.
My favorite example is Red Hat, although I'm sure some people here are fully prepared to bash them.
AMD/ATI only offers GPU-accelerated decoding and presentation through the XvBA API, which is only available to their enterprise and embedded customers. People seem to always forget that fglrx is for enterprise (FireGL) people first.
Wait for the officially supported open-source radeon drivers to get support for GPU-accelerated decoding, or (God forbid!) contribute some code. In particular, if somebody would write a VDPAU frontend for Gallium3D...
AMD won't be releasing XvBA to the general public. Just wait for Gallium VDPAU. Or write it yourself. We've got all the docs.