#1: big security no-no -- DNS spoofing is trivial, and all you have to do is redirect install.oeone.com to your IP and stick a webserver with some basic remote shellcode, and instant root. The least they could do is SSL.
Besides that, this looks like a very interesting system for novice end-users. I'd also be excited about the single-CD idea.
Ken
Re:alternative media api: OpenML
on
Whither OpenAL?
·
· Score: 1
(unless things have changed in the past month) Since someone here seems to know a thing or two about openml, I'll bring up a few questions I have here.
First, and probably most significantly, how does OpenML deal with seeking in a stream? In a degenerately-multiplexed stream (e.g. all data for one media type before the rest because that data can't interleave properly or one block of it covers a large time area e.g. lyrics / captions), seeking properly becomes very difficult, and even in normal multiplexed streams, sample-granularity streaming (or, in OpenML's case, probably UST(?)-granularity seeking) is a challenging problem. I searched the downloadable specs and didn't find the works 'seek' or 'seeking' once.
On a similar topic, how are multiplexed streams (e.g. MPEG program streams) dealt with? A demux transcoder feeding into codec transcoders? How would this work for seeking?
What about playing files? The specs discuss transcoding assuming that the transcoder can always handle the type of file given to it. So that either means one big monolithic transcoder, or some magical ability of any component to guess which transcoder to use for a given data stream (and for multiplexed streams that's a big guess). Insight on this?
Are the standards revised yet to allow for VBR codecs, where there is not a one-to-one correspondence between input and output buffers for a transcoder?
Finally, where can I get a fully compliant implementation? dmSDK uses dm[FUNC], which is in most cases equivalent to ml[FUNC], but that means renaming a ton of constants, functions, and types when compiling against a reference implementation, if one ever comes to be. And is there any example code whatsoever for transcoders, even if it's no more than reading in a WAV file with header and writing the PCM data from it with sampling rate and channels set? When I looked at trying to write a transcoder for decompressing Vorbis, I was bluntly discouraged by the sheer size of the null (pass-through) transcoder. Example code for a transcoder that actually does something with real-world streaming data would be immensely helpful.
Other than that, the standard looks quite well thought-out, including a well-done union-type message passing structure, the concept of which I stole almost exactly for my rework of the ogg123 internals as part of the major overhaul that should hopefully be complete before Ogg Vorbis RC3.
Don't use that link -- in the best case, Google's cache is old, and this is nowhere near best-case.
Re:Whoa, there; I think we missed a step
on
Ogg Vorbis Players?
·
· Score: 2
Though I admit that I have not done any real side-by-side double-blind tests (nor do I have the quality hardware to do it properly), I will have to say that I already consider Vorbis to be of better quality than MP3 (yes, lame included) at similar bitrates, and lame has had years of tuning and work while the Vorbis encoder is just reaching RC1. One of the things that should come in RC1 is channel coupling. Monty has already committed to his work branch a ~80k channel coupled mode for mode A encoding, i.e., what used to be 128k. If that holds up for higher bitrates, and I have no reason to think that it wouldn't, Vorbis will have a solid ~40k head on MP3, and -- unlike MP3pro -- the RC1 decoder, released a few weeks ago, can play the channel-coupled streams.
As for decoding CPU usage, ogg123 and mpg123 command line decoders are roughly equivalent -- the general rule is that Vorbis was designed to be little more computationally complex than MP3. Frontend implementions, as mentioned elsewhere in this thread, can have an impact on that.
As a complement to the parent's described behavior, I would encourage the reader to check out GNU pth, a very portable single-process non-preemptive threading library. With this you get the sort of benefits the parent describes, but the work is mostly done for you already.
About 3D -- if you use Debian's supplied XFree86 4.x deb's, you get the precompiled drivers for the video card. And I have no idea where you're getting the idea that the drivers are 0.01 -- DRI is maturing rapidly and is already very useful on out-of-the-box configurations. Yeah it will only get better, and I think they're still calling the results "beta", but it's very-usable beta. If you have a card that is not supported in a distributed X, like the ATI Radeon (which I have), getting the drivers is still quite easy -- go here. That's the Debian side of things (and will probably apply to Progeny etc. as well); talk to others about the Mandrake or whatever. The only driver really lacking in automated install at the moment is the nVidia Linux driver, but I'll bet somebody has packaged that up by now also, and it's not hard at all to install even without a package. I think that takes care of almost all mainstream video cards (see the DRI site for what cards they support (a lot)).
And what's this crap about the games being poorly ported! Loki has done an amazing job moving these highly complex games from one display platform to another and packaging the results. I have recently installed Descent 3 for Linux, and the only trouble I had was that I didn't want to install it as root (but most people would install anything as root) and had to change the permissions on the install directory, but that was simple.
As for business apps, having useful apps on Linux would be nice, but VMWare running Windows 2000 gets me all I could possibly want in that area without leaving the comfort of my KDE desktop.
Let's hear it for the good work already done in bringing Linux to the mainstream, and I'm not even getting into KDE vs. GNOME or any of that (they're both nice, usable environments; I happen to like KDE more).
The problem is, video, especially highly-compressed video, is riddled with patent issues and other junk like that, or else somebody would have written a nice low-bitrate encoder by now (I'm not counting OpenDivX here, because it isn't really open if you read the license, unless the situation has changed since I last checked). And doing proper streaming isn't as easy as one might think; especially for video there is a lot of data management to be taken care of, for example if you're coding the next frame by motion compensation, sending just a motion vector for an object instead of the whole object, the streaming format must ensure that the whole object has been sent sometime or else the viewer will probably see just a moving black blob.
If you want sorta-open streaming now, though, check out OpenDivX streaming.
SDL, at least on Linux, uses the OS's drivers; if your OS's drivers cannot talk to your hardware, SDL has no way either. Go on openprojects.net IRC and ask about your serial line discipline (or somebody on the SDL mailing list; even though it's not their responsibility they probably still know all that sort of stuff anyway); joystick support worked just fine for me after loading the modules so I can't draw on personal experience (but it's scarry how many things I do have experience messing up;)).
6 degrees of freedom -- cool. Joystick in Descent3 is quite difficult to get right (but I'm working on it; I'm getting better).
You wonder why X is taking up e.g. 70 MB of memory? Maybe because that includes one or even several mappings of your video card's memory! If you have a 64 MB card, mapping that memory into your process space is going to make it look like that process is taking up 64 MB of memory. And X is often assigned CPU usage that really would be designated to its clients, e.g. moving a window around causes (on poorly-accelerated chipsets) a large jump in CPU usage, even though you're really moving some client's window.
Granted, X isn't all that pretty, especially when you talk Xlib with it, but it has proven itself to be a highly capable (and well-documented) architecture for doing just about anything with graphics. It runs on an iPAQ with room to spare, is fast (with the appropriate acceleration extensions e.g. Xv), and has already done all the dirty work with direct hardware interaction for you.
But you forget that there are two sides to WINE (and, because of the close relationship, TrnasGaming) -- there's the binary emulation layer, which I consider an amazing feat of programming brilliance, and Winelib, the source compatible layer.
If porting a game to Linux required just recompiling your source, writing a quick little installer (or just use a deb / rpm package), and putting it in a box, how many game companies do you think would be doing it? Well that's where winelib is headed at least, and if my intuition serves me right, a program recompiled with Winelib on Linux should run better than a program compiled on Windows and run in Linux with binary emulation. Note how many games already work with WINE+transgaming with binary emulation. The future is bright.
>... how to turn that extra Pentium into a firewall running iptables
You people must be RICH! My iptables router is a 486/66 with 8 MB of RAM and very very horrid I/O performance (yes, Timothy, it's the short little box I showed you when you dropped by). Easily saturates a modem line, though, and I can wait the ~1 minute it takes to telnet in, su, and run iptables to open or close a port.
I have inherited a Pentium-120 now (though I had to trade parts of my desktop box for it) so unless I get a cable modem or DSL before I get around to changing it out, that 486 is going to take a very long rest soon. Might resurrect it someday for realtime 3D rendering and video compression.
> The DTC-100, like other first generation ATSC receivers, has severe problems dealing with multipath (ghosts on analog TV).
Second-generation receivers, though better, are still going to have problems with multipath because of inherent issues in the system being used. Future generations of receivers may very well work around the problem, but if you think about what ghosting really is and how it affects a signal, one really wide carrier isn't going to cut it. A frequency-division multiplexing system like Europe (and most of the rest of the world now) has, DVB-T, pretty well solves that issue by having multiple partially redundant carriers in a single channel, so if the receiver cannot recover the data in one of them due to ghosting, another one will likely have the needed data, so ghosting overall takes a smaller hit on the signal. That's not exactly how it works, but it's the general idea.
So the US is going with it's one-big-signal 8-VSB while almost every other country in the world except for 5 (and I think that number has gone down) uses OFDM. Why? Well maybe a portable COFDM receiver can receive a weak test signal from a transmitter in Long Island while driving down the streets of New York City (actually driving, not sitting in traffic) without a hitch, and you're lucky to get 8-VSB transmitted from towers on the top of the Empire State building if you stop, pull to the side of the road, and carefully move the antenna around until you get a signal, which drops out every time a car passes. It'll get better, yes... but do you really think that companies will innovate for the US and a few other islands of 8VSB, or the rest of the world with COFDM?
And for the on-topic portion of this comment, I watched the Superbowl on CBS in HDTV on a studio receiver -- talk about a better receiver! It has quite a few more outputs than I'd know what to do with (hint: component video is just the start), and among other things it has serial digial output, the studio standard. I think it's uncompressed or maybe slightly compressed, over a cable that really is a fat pipe. It's too bad I didn't have a card to connect it to my computer (not that I could really have had the means to record more than a few minutes of it). Firewire would have been much easier to deal with, especially if it was just Firewire-encapsulated MPEG2.
Woah! Give me a copy! That must have Radeon DRI support in it ("they" said it was going in for the next release). While you're at it, could I have a copy of Linux 2.5.35?
Sorry, just pointing out that, unless I missed something, it's XFree86 4.0.1, now 4.0.2.
The Radeon doesn't have 3D DRI yet (they're barely out for Linux, though, so I'm not suprised)
I successfully segfaulted the FreeBSD installer, twice, doing different things. No, I wasn't trying.
Nevertheless, I still would like to give it a try, so I'm going to put a little more effort into it next time and see if I can get it to work. btw, it doesn't want to install on a logical partition, so I'm having to use a second -- no, third -- drive for it. Then I'll boot it with grub:)
DRI works, and I get good 3D acceleration, so there's some hardware support done good for you. gatos has some support for Radeon, not sure how much, but I saw a bunch of commits going on in livid-cvs.
If you want DRI, check out the CVS tree from dri.sourceforge.net, main branch. But last I checked it minces all forms of 3D acceleration quite badly, but it worked like a charm on January 15th. So check out the main branch on January 15th. For a quick HOWTO, look at README.DRIcomp.gz in/usr/share/doc/xserver-xfree86 on a Debian system, or search around on x.org; it's there somewhere. It's best to be running X 4.0.[12] already to be able to link in the rest of the infrastructure easily. I've found that if you set ProjectRoot to/usr/<somewhere besides X11R6> and run/usr/there/bin/X -configure, modify/root/XF86Config.new as appropriate, and put it in/etc/X11/XF86Config-4 (or whereever it normally goes on your distro), you can use your normal (X 4.0.2) server and it'll just load the Radeon modules. Works fine for me, YMMV. Also make sure your Mesa (libGL) libs are the ones DRI built. Then startx (kdm doesn't like me now), run glxinfo, and have fun if it says "Direct Rendering: Yes". Email me privately (obvious modifications to email of course) if you have a Radeon and want Quake &c and can't figure it out from the above and other docs.
Now this of course doesn't relate to video capture, but shows that high-level Radeon support has already been done in one area, and from what I know about video cards (not much, mind you...), capturing features should be a lot simpler than good 3D acceleration. So grab gatos from LiViD and have fun.
InPhase won't be the only startup trying to turn HDS technology into commercial products. Rivals reportedly include Holoplex Technologies Inc. (Pasadena, Calif.), founded by Demetric Psaltis, a professor of electrical engineering at California Institute of Technology.
So rest assured that when they finally figure it out, there will be at least two other companies to immediately release similar technology, say they did it first, and apply for a patent or two on the subject, which will be granted regardless of Lucent's patent (industrial spying is real! no pipe dream is safe!). The competition will be firce, but by then 300 gigabits per square inch (but aren't holograms 3D?) won't seem like much. We have pushed magnetic technology beyond its limits and it's still going smaller; by the time this is commercialized it probably won't be such a big deal. cya in 20xx -- I'll bet 2010.
Re:playing games when booting?
on
GTK+ without X!
·
· Score: 1
Debian's console-apt has a console-based "captris" that you can enable while packages are downloading (not installing... yet... Debian does important configuration during the install, not after). In any case, I find watching packages get configured more interesting than Tetris(tm), and do _not_ like big downloads. Have sympathy for the one with phone lines so bad they can't even to 28.8kbps. And yet tracks Debian unstable.
Computers will continue to get faster and faster, and most of the general public will buy it, because the latest release of Microsoft Office requires loads of RAM and CPU for the 3D-rendered texture-mapped virtual reality paperclip. Or 3D-rendered badly-drawn cat, if you prefer.
Linux will succeed beyond all hopes and dreams (well, except this one <g>), then another, better operating system will overtake it. How something can be better than Linux's potential is beyond me at the moment, but let's not forget that it is not the future yet.
There will be stable Linux drivers for my Radeon (sorry, had to put that in there).
There will be no more wars, and everyone will have basic necessities... yeah right. Hope all you want, but we're only humans (AFAIK)
There will be a great technological advancement that will change world culture dramatically. Everyone will immediately say that they had been pondering that very idea twenty years ago. Too bad I can't put a finger on what it is.
Geeks will still be around, but their social status will change. No "suit" will ever care to admit how much of a role they play in the infrastructure they all come to rely on, but the line will continue to be blurred as the geeks take over a small sector of the world. Most of the general public won't care.
timothy will find lots more useful stories to post on Slashdot, but nobody will realize it, which is too bad because he's a cool person (he Slashdotted on my box once:)
Ken will add more to this list. Nevermind -- he'll probably forget he posted this by tomorrow morning.
That's all for now. Good night. And pretend that nothing happened, because besides from a few parties, nothing did.
Stream Vorbis! Once they get RTP/RTSP encapsulation working right (soon, some proof-of-concept has already been done), Vorbis is the free (and often higher-quality) alternative to MP3. After the new year, you'll have to pay for MP3. You have been warned.
Yes it all looks pretty at the highest brightness setting your monitor can muster, but it can really hurt one's eyes. I watch movies (Divx;) and DVD) with my brightness around 85, which was how the monitor shipped, but for normal work it goes down to 30 or 40. It looked quite unusual when I first got the suggestion to do this, but white does look more white, and it's much less of a strain on my eyes. I also set the color temperature down to 6500K, but I'm considering moving to 5000K. It's not about high technology. It's about the first controls a monitor ever had (the Power switch is also very useful; turn the monitor off and go walk around for a few minutes every once in a while).
Ambient lighting is also an issue; bright fluorenscent lights tend to glare a lot. If possible, turn off the light and use soft white incandescant lights, preferrably out of your direct field of view.
When I first tried what I describe here, each setting hurt my eyes more, but as I got used to it they hurt much less. So make your changes gradually to avoid headaches.
This has been discussed on the Vorbis list. The subject was dropped as it was judged that for MS to get that much improvement, it would require about a 10x improvement in codec quality over one release, which those discussion did not see as very plausable. Some also brought up problems in the current WMA codec (like background hiss "intentional"... heh), and the general consensus seems to be that WMA is useless at the moment because there are better and less restrictive codecs (MP3 less restrictive? what have I been ingesting lately?) than WMA at any bitrates where it is better than other codecs. Note that I did not contribute any of the points mentioned; this is simply an editorial comment.
These are a couple of nice things you learn from knowing timothy...
* Stories can be scheduled to come up at a certain time. This is how they still manage to come up with something to post while everybody is (supposed to be) sleeping. From what I gather, most Slashdot people sleep in the late morning after finishing up around 5 AM.
* There is a system in the admin page where posts can be tagged with comments / info by the admins. Maybe there were 200 some stories in the queue and most were already tagged with something like "wait till later". Also, if you have 200 detailed items to go through, do you start at the middle? Top? Bottom? The admins are human; > 20 submissions at any time is bound to stress anyone.
Wine on WIN32 -- yes people are trying with cygwin. It may work soon. Currently there's only linking problems left AFAIK.
Wine on OSX powerpc -- nope, it's a powerpc. But winelib yes -- there has been lots of talk and no action from reading the Wine lists, but it can and probably will happen. It might have to wait for the OSX (darwin) development platform to get a little more friendly (e.g. some important libraries are in different places or nonexistant in the public beta's developer CD). I'm sure help would be welcome if you want to try -- there are already OSX Xservers, so there a major stumbling block falls (though a native version would be nice and probably run faster, not to mention being more useful for developers porting over apps for users, not developers, to use).
Slashdot Mirror
#1: big security no-no -- DNS spoofing is trivial, and all you have to do is redirect install.oeone.com to your IP and stick a webserver with some basic remote shellcode, and instant root. The least they could do is SSL.
Besides that, this looks like a very interesting system for novice end-users. I'd also be excited about the single-CD idea.
Ken
(unless things have changed in the past month) Since someone here seems to know a thing or two about openml, I'll bring up a few questions I have here.
First, and probably most significantly, how does OpenML deal with seeking in a stream? In a degenerately-multiplexed stream (e.g. all data for one media type before the rest because that data can't interleave properly or one block of it covers a large time area e.g. lyrics / captions), seeking properly becomes very difficult, and even in normal multiplexed streams, sample-granularity streaming (or, in OpenML's case, probably UST(?)-granularity seeking) is a challenging problem. I searched the downloadable specs and didn't find the works 'seek' or 'seeking' once.
On a similar topic, how are multiplexed streams (e.g. MPEG program streams) dealt with? A demux transcoder feeding into codec transcoders? How would this work for seeking?
What about playing files? The specs discuss transcoding assuming that the transcoder can always handle the type of file given to it. So that either means one big monolithic transcoder, or some magical ability of any component to guess which transcoder to use for a given data stream (and for multiplexed streams that's a big guess). Insight on this?
Are the standards revised yet to allow for VBR codecs, where there is not a one-to-one correspondence between input and output buffers for a transcoder?
Finally, where can I get a fully compliant implementation? dmSDK uses dm[FUNC], which is in most cases equivalent to ml[FUNC], but that means renaming a ton of constants, functions, and types when compiling against a reference implementation, if one ever comes to be. And is there any example code whatsoever for transcoders, even if it's no more than reading in a WAV file with header and writing the PCM data from it with sampling rate and channels set? When I looked at trying to write a transcoder for decompressing Vorbis, I was bluntly discouraged by the sheer size of the null (pass-through) transcoder. Example code for a transcoder that actually does something with real-world streaming data would be immensely helpful.
Other than that, the standard looks quite well thought-out, including a well-done union-type message passing structure, the concept of which I stole almost exactly for my rework of the ogg123 internals as part of the major overhaul that should hopefully be complete before Ogg Vorbis RC3.
Thanks for the input.
--Kenneth Arnold
oggenc (vorbis-tools) has a WAV reader you can use for input. libao has a WAV writer you can use for output. So yes the answer can be ogg.
Don't use that link -- in the best case, Google's cache is old, and this is nowhere near best-case.
As for decoding CPU usage, ogg123 and mpg123 command line decoders are roughly equivalent -- the general rule is that Vorbis was designed to be little more computationally complex than MP3. Frontend implementions, as mentioned elsewhere in this thread, can have an impact on that.
As a complement to the parent's described behavior, I would encourage the reader to check out GNU pth, a very portable single-process non-preemptive threading library. With this you get the sort of benefits the parent describes, but the work is mostly done for you already.
About 3D -- if you use Debian's supplied XFree86 4.x deb's, you get the precompiled drivers for the video card. And I have no idea where you're getting the idea that the drivers are 0.01 -- DRI is maturing rapidly and is already very useful on out-of-the-box configurations. Yeah it will only get better, and I think they're still calling the results "beta", but it's very-usable beta. If you have a card that is not supported in a distributed X, like the ATI Radeon (which I have), getting the drivers is still quite easy -- go here. That's the Debian side of things (and will probably apply to Progeny etc. as well); talk to others about the Mandrake or whatever. The only driver really lacking in automated install at the moment is the nVidia Linux driver, but I'll bet somebody has packaged that up by now also, and it's not hard at all to install even without a package. I think that takes care of almost all mainstream video cards (see the DRI site for what cards they support (a lot)).
And what's this crap about the games being poorly ported! Loki has done an amazing job moving these highly complex games from one display platform to another and packaging the results. I have recently installed Descent 3 for Linux, and the only trouble I had was that I didn't want to install it as root (but most people would install anything as root) and had to change the permissions on the install directory, but that was simple.
As for business apps, having useful apps on Linux would be nice, but VMWare running Windows 2000 gets me all I could possibly want in that area without leaving the comfort of my KDE desktop.
Let's hear it for the good work already done in bringing Linux to the mainstream, and I'm not even getting into KDE vs. GNOME or any of that (they're both nice, usable environments; I happen to like KDE more).
If you want sorta-open streaming now, though, check out OpenDivX streaming.
6 degrees of freedom -- cool. Joystick in Descent3 is quite difficult to get right (but I'm working on it; I'm getting better).
You wonder why X is taking up e.g. 70 MB of memory? Maybe because that includes one or even several mappings of your video card's memory! If you have a 64 MB card, mapping that memory into your process space is going to make it look like that process is taking up 64 MB of memory. And X is often assigned CPU usage that really would be designated to its clients, e.g. moving a window around causes (on poorly-accelerated chipsets) a large jump in CPU usage, even though you're really moving some client's window.
Granted, X isn't all that pretty, especially when you talk Xlib with it, but it has proven itself to be a highly capable (and well-documented) architecture for doing just about anything with graphics. It runs on an iPAQ with room to spare, is fast (with the appropriate acceleration extensions e.g. Xv), and has already done all the dirty work with direct hardware interaction for you.
If porting a game to Linux required just recompiling your source, writing a quick little installer (or just use a deb / rpm package), and putting it in a box, how many game companies do you think would be doing it? Well that's where winelib is headed at least, and if my intuition serves me right, a program recompiled with Winelib on Linux should run better than a program compiled on Windows and run in Linux with binary emulation. Note how many games already work with WINE+transgaming with binary emulation. The future is bright.
You people must be RICH! My iptables router is a 486/66 with 8 MB of RAM and very very horrid I/O performance (yes, Timothy, it's the short little box I showed you when you dropped by). Easily saturates a modem line, though, and I can wait the ~1 minute it takes to telnet in, su, and run iptables to open or close a port.
I have inherited a Pentium-120 now (though I had to trade parts of my desktop box for it) so unless I get a cable modem or DSL before I get around to changing it out, that 486 is going to take a very long rest soon. Might resurrect it someday for realtime 3D rendering and video compression.
Second-generation receivers, though better, are still going to have problems with multipath because of inherent issues in the system being used. Future generations of receivers may very well work around the problem, but if you think about what ghosting really is and how it affects a signal, one really wide carrier isn't going to cut it. A frequency-division multiplexing system like Europe (and most of the rest of the world now) has, DVB-T, pretty well solves that issue by having multiple partially redundant carriers in a single channel, so if the receiver cannot recover the data in one of them due to ghosting, another one will likely have the needed data, so ghosting overall takes a smaller hit on the signal. That's not exactly how it works, but it's the general idea.
So the US is going with it's one-big-signal 8-VSB while almost every other country in the world except for 5 (and I think that number has gone down) uses OFDM. Why? Well maybe a portable COFDM receiver can receive a weak test signal from a transmitter in Long Island while driving down the streets of New York City (actually driving, not sitting in traffic) without a hitch, and you're lucky to get 8-VSB transmitted from towers on the top of the Empire State building if you stop, pull to the side of the road, and carefully move the antenna around until you get a signal, which drops out every time a car passes. It'll get better, yes... but do you really think that companies will innovate for the US and a few other islands of 8VSB, or the rest of the world with COFDM?
And for the on-topic portion of this comment, I watched the Superbowl on CBS in HDTV on a studio receiver -- talk about a better receiver! It has quite a few more outputs than I'd know what to do with (hint: component video is just the start), and among other things it has serial digial output, the studio standard. I think it's uncompressed or maybe slightly compressed, over a cable that really is a fat pipe. It's too bad I didn't have a card to connect it to my computer (not that I could really have had the means to record more than a few minutes of it). Firewire would have been much easier to deal with, especially if it was just Firewire-encapsulated MPEG2.
Sorry, just pointing out that, unless I missed something, it's XFree86 4.0.1, now 4.0.2.
Nevertheless, I still would like to give it a try, so I'm going to put a little more effort into it next time and see if I can get it to work. btw, it doesn't want to install on a logical partition, so I'm having to use a second -- no, third -- drive for it. Then I'll boot it with grub :)
DRI works, and I get good 3D acceleration, so there's some hardware support done good for you. gatos has some support for Radeon, not sure how much, but I saw a bunch of commits going on in livid-cvs.
If you want DRI, check out the CVS tree from dri.sourceforge.net, main branch. But last I checked it minces all forms of 3D acceleration quite badly, but it worked like a charm on January 15th. So check out the main branch on January 15th. For a quick HOWTO, look at README.DRIcomp.gz in /usr/share/doc/xserver-xfree86 on a Debian system, or search around on x.org; it's there somewhere. It's best to be running X 4.0.[12] already to be able to link in the rest of the infrastructure easily. I've found that if you set ProjectRoot to /usr/<somewhere besides X11R6> and run /usr/there/bin/X -configure, modify /root/XF86Config.new as appropriate, and put it in /etc/X11/XF86Config-4 (or whereever it normally goes on your distro), you can use your normal (X 4.0.2) server and it'll just load the Radeon modules. Works fine for me, YMMV. Also make sure your Mesa (libGL) libs are the ones DRI built. Then startx (kdm doesn't like me now), run glxinfo, and have fun if it says "Direct Rendering: Yes". Email me privately (obvious modifications to email of course) if you have a Radeon and want Quake &c and can't figure it out from the above and other docs.
Now this of course doesn't relate to video capture, but shows that high-level Radeon support has already been done in one area, and from what I know about video cards (not much, mind you...), capturing features should be a lot simpler than good 3D acceleration. So grab gatos from LiViD and have fun.
So rest assured that when they finally figure it out, there will be at least two other companies to immediately release similar technology, say they did it first, and apply for a patent or two on the subject, which will be granted regardless of Lucent's patent (industrial spying is real! no pipe dream is safe!). The competition will be firce, but by then 300 gigabits per square inch (but aren't holograms 3D?) won't seem like much. We have pushed magnetic technology beyond its limits and it's still going smaller; by the time this is commercialized it probably won't be such a big deal. cya in 20xx -- I'll bet 2010.
Debian's console-apt has a console-based "captris" that you can enable while packages are downloading (not installing ... yet ... Debian does important configuration during the install, not after). In any case, I find watching packages get configured more interesting than Tetris(tm), and do _not_ like big downloads. Have sympathy for the one with phone lines so bad they can't even to 28.8kbps. And yet tracks Debian unstable.
That's all for now. Good night. And pretend that nothing happened, because besides from a few parties, nothing did.
Stream Vorbis! Once they get RTP/RTSP encapsulation working right (soon, some proof-of-concept has already been done), Vorbis is the free (and often higher-quality) alternative to MP3. After the new year, you'll have to pay for MP3. You have been warned.
Ambient lighting is also an issue; bright fluorenscent lights tend to glare a lot. If possible, turn off the light and use soft white incandescant lights, preferrably out of your direct field of view.
When I first tried what I describe here, each setting hurt my eyes more, but as I got used to it they hurt much less. So make your changes gradually to avoid headaches.
This has been discussed on the Vorbis list. The subject was dropped as it was judged that for MS to get that much improvement, it would require about a 10x improvement in codec quality over one release, which those discussion did not see as very plausable. Some also brought up problems in the current WMA codec (like background hiss "intentional"... heh), and the general consensus seems to be that WMA is useless at the moment because there are better and less restrictive codecs (MP3 less restrictive? what have I been ingesting lately?) than WMA at any bitrates where it is better than other codecs. Note that I did not contribute any of the points mentioned; this is simply an editorial comment.
* Stories can be scheduled to come up at a certain time. This is how they still manage to come up with something to post while everybody is (supposed to be) sleeping. From what I gather, most Slashdot people sleep in the late morning after finishing up around 5 AM.
* There is a system in the admin page where posts can be tagged with comments / info by the admins. Maybe there were 200 some stories in the queue and most were already tagged with something like "wait till later". Also, if you have 200 detailed items to go through, do you start at the middle? Top? Bottom? The admins are human; > 20 submissions at any time is bound to stress anyone.
Ok is that off-topic enough for you?
nope, sorry.
Wine on OSX powerpc -- nope, it's a powerpc. But winelib yes -- there has been lots of talk and no action from reading the Wine lists, but it can and probably will happen. It might have to wait for the OSX (darwin) development platform to get a little more friendly (e.g. some important libraries are in different places or nonexistant in the public beta's developer CD). I'm sure help would be welcome if you want to try -- there are already OSX Xservers, so there a major stumbling block falls (though a native version would be nice and probably run faster, not to mention being more useful for developers porting over apps for users, not developers, to use).