First of all, the focus of the article was indeed multimedia, from the point of view of the average person who wants to use Linux to watch DVDs and videos off the net. These people really couldn't care less about perfect sample accuracy of their $10 sound card. Trying to force pro-audio qualities onto every machine is impossible, and highly counterproductive in the face of other more visible issues.
GStreamer is indeed an infrastructure for building multimedia apps. Absolutely everything it does is under the auspices of the elements that it loads and connects together. Claiming that GStreamer has no means of inter-application communication is false, as there are already numerous elements both for communication with sound servers and other applications (network source/sinks, etc.). A set of Jack elements are being written, as well.
GStreamer also has nothing to do with the GUI whatsoever. Elements are GObjects that have no GUI in them at all, they focus on doing what they're supposed to. Any GUI exists as a seperate entity on top of the processing pipeline as managed by GStreamer.
If your worry is that LADSPA won't be used, don't. LADSPA plugins are fully supported with a shim under GStreamer.
As for whether to sync to audio or video, you actually have it quite backwards. First of all, the most difficult situation is not with progressive video, but with field-based video (which both NTSC and PAL are, BTW), where the vertical rates are 50 or 59.95Hz. Compare this to a CRT, and you have significant problems finding a decent match between them.
As for the "content" business somehow making video more important than audio, you're ignoring the fact that video *is* more important than audio when both are present together in the same stream. There are several order of magnitude more bits in the video than than the audio, anyway.
Now, to the technical reasons it makes vastly more sense to absorb changes in the audio clock:
1) 90+% of computers have sound cards with clocks that can be best described as "kinda sorta correct". They vary wildly around the real 44.1k baseline. If anyone notices this, there's not much they can do about it. More fundamentally, how are you going to maintain any kind of stream clock when the audio rate is changing during the presentation (as it will when temperature and other things change in your computer, since the clock is susceptable to this)?
2) The quanta of video playout is much greater than that of audio, on the order of 500+ times larger. The goal of any good video playback is to synchronize the playout of a video frame (theoretical time unit) to a vertical refresh (physical time unit). If at any point those become desynchronized, you will have a discontinuity of at least one vertical retrace, or on average about one 75th of a second. Specifically, you'll have a video frame that is suddently displayed for between 50% and 100% longer than it's supposed to be, in the middle of a bunch of correct frames. This is *blatantly* noticable by anyone with a normal visual cortex.
Audio, and the human ear, is much more forgiving. If the program simply drops or duplicates a sample every once in a while to maintain minimal drift between the two (video and audio) clocks, it will be altering 1/44,100th of the samples in that second. If done wrong, it will cause a click. Doing it "less wrong" to avoid clicks is trivial.
So the decision is between locking to a highly variable audio clock (think 3.6 seconds per hour per 0.1% off) and having video that jerks and sputters whenever the theoretical and physical frame times disagree, or doing some resampling to the audio where necessary, with the possibility of some loss of quality that is undetectable by 99% of people watching videos on their computer with tinny speakers.
Me, I don't like video-induced headaches, I'll resample the audio.
Bootable CDs certainly are a problem. Remember, this is Windows, not Linux. You can't just put a kernel at the top of the disk and let it start. The boot sequence for a Windows CD is much more complicated than it is on a partition.
FYI, there is a significant difference between recovery CDs and a recovery partition. It is fundamentally impossible to "just burn the recovery partition to CDs". First, how do you get a bootable CD? Then, how do you split the files across the CDs? And tell the installer where to get the files it needs, etc, etc, etc.
As a lead GStreamer developer, and someone very interested in Tarkin, I must point out that what was added was a plugin to "w3d", a candidate technology for Tarkin. There is no Tarkin codec, yet, and won't be for some time, as there is still heavy research into what the best type of codec is for this task. w3d is just one of many attempts to make something workable, albeit the most successful so far. Unfortunately, my hint that the plugin should be called "w3d" was ignored;-(
No, when buying a new car, you ask how many pot-holes it will go over before a wheel falls off. Or in my case (see "Dell Inspiron 7500" cid 2923987), how many times you can open and close your laptop before the screen falls off.
I've had a PIII-500 for about 26 months now, and it's already been back twice, and about to go back a third time (as soon as I can part with it for a week). It has the 1400x1050 UXGA screen, which was basically duct-taped to the top of a smaller laptop body. As a result, the mounts for the two screen hinges are a joke. The cross-sectional area at the bottom is minimal, and the metal quality was pathetic, albeit from my minimal metalurgical knowledge.
First the left hinge-mount snapped. This rendered the laptop completely unusable. Sent it in for repair, they replaced the whole screen. Nice enough to transplant my stickers though.
Then, exactly two days (a weekend) before my trip to Europe for 2 weeks for GUADEC-2, the right hinge-mount snapped, same place, same ragged pot-metal edge, etc. Managed to borrow a laptop, just barely. Turns out that the geniuses at Dell figured that the right-hand mount would be fine after the whole screen dangled at odd angles for an extended duration (attempted workarounds, shipping, etc.), and left it. Fatally wounded.
Well, the current predicament is that now the left hinge-mount is still in one piece (not sure I can say the same for the right one for much longer...), but it's screwed into a completely detached section of the *FRAME*. That's right, the entire mass of some kind of metal to which the tiny little hinge-mount is screwed has totally sheared off. It's held in by the outer plastic shell. I've managed to limp along for a couple months now, but it's gonna get sent in in a week or two.
I *STRONGLY* recommend that any laptop you consider, you get your hands on one (a friend/coworker with one, even ask on a local newsgroup if you have to) and check it out for some of these brain-dead design flaws. I'm still considering Dell when replacing this one in another year or so, but I will be doing some heavy research on the 8[12]00 models available at the time, as far as structural integrity.
However, I've heard all sorts of bad things about the "feel" of Dells vs. other laptop brands, and I have to agree. For all the killer features and decent price they put into their laptops, it's almost universally agreed upon that the construction quality, as far as structural integrity and longevity, sucks.
Spend some time in the DellNet Forum, and probably the equivalent foraa for other manufacturers. You won't regret it.
The Ethernet frame header portion of the packet, below the IP header, is the only place there is a MAC address. This frame header is stripped of by each and every router, because it is only used for the local segment. When the router places the packet on a new network to send it upstream to the next router, it places its own MAC address in the source and the MAC address of the next hop router in the destination. This is how all ethernet/IP routing is done. Other mediums such as ATM have variations on this theme.
A NAT box is by definition a router, and a packet-mangling router at that. The MAC source address on every single packet coming *through* the NAT box is that of the NAT box.
No, MAC addresses never leave the network segment they're on. They are part of the Ethernet frame header, which is stripped by each and every router, including the NAT box.
What you really want is a regular laptop with a Firewire audio interface. There are several on the market now geared more towards multi-channel stuff, but I'm working on a hardware design that would make a high-quality (think 24bit, 192KHz) stereo output relatively cheap (say $100). Email me at omega at temple - baptist dot com for more info, but don't expect anything usable for a few months;-}
I built one while working at OGI a few years ago. I've got a copy of the pages on my current server, at http://www.temple-baptist.com/~omega/ogimabot2/, with a little info on it. I should see if the prof. I was working with still has the slides to convert to HTML...
They're supposedly going to be building a new one soon, and so my research into a next-gen robot may be put to use. I was looking very closely at the Cell Computing parts (http://www.cellcomputing.com/), which aren't cheap ($1k-$1.5k depending), but are the right size and somewhat designed for that kind of stuff. Put that in (instead of on top of, like the current bot) the car (thinking of using a monster-truck chassis) and you can do pretty good.
Email me if you have other questions, because I spent a huge amount of time on this project and its related issues.... nospam_omega@temple-nospambaptist. com
Indeed. I've played with one for a few minutes. Very cool device. The unit I used was somewhat slow for a reason that will be irrelevant once it's rolled out, and is already irrelevant in their labs IIRC. The processor is rather slow, but that's part of their business model. If they can rev the unit for 2nd gen with a much faster chip, it could be very cool. However, it does *not* act like a Palm, and would have a hard time doing so. But that's entirely software... I would imagine someone could put PalmOS on this hardware (with a touch screen added).
There's only one author of Broadcast 2000, going by the name 'Heroine Virtual'. He now works for Pioneer, and I'm wondering if he was told to stop work on the project and is finding some way to do so without making it obvious? Or if Pioneer is going to use the project somehow. This would worry me, because a lot of people, including myself (co-author of libdv) have code that is distributed in the b2k tarball. Since it's all [L]GPL'd, there's significant potential for Pioneer to make a mess.
I worked with several people who now work for RuleSpace, and they explained some of what they're doing. RuleSpace has defined a large number (several hundred) of very tightly defined categories. Their compute farm goes over pages and anaylzes them based on content and context, not keywords. They're assigned any number of categories as appropriate, and the user can then (if AOL exposes these small categories) turn on and off different sets of content. Humans go over a sample of the results and verify that the computer successfully assigned all the right catgories, and re-train the computers if they mess up. One question I have though: when they retrain the nets, do they queue up all the already analyzed pages for re-analysis?
Fine-grained categorization means that parents can then fine-tune what is blocked for their children. Libraries (if forced to use filtering) can know that they're blocking only things that are not allowed in their community. It's no longer a matter of "Do I trust what they think is acceptable?", but an excercise in deciding what is acceptable
No, I'm not a RuleSpace employee, I just believe that this technology (if it's done right) is the best solution by far. If they can't pull it off correctly, I'll be just as against using their filtering as anyone elses, but I think they're on the right track.
Score one for AOL (a very rare thing).
There *are* amateur rocketeers launching from Bend
on
To the Moon, Alice
·
· Score: 1
While this story may be fictional, there is a group from Portland, OR that are working on rockets to be fired from Bend, OR. Their website is at www.psas.pdx.edu. They're working on inertial navigation, and recently put out a call for volunteers to work on a port of [uC]Linux to the mpc555 chip, which is a PPC variant.
They are launching from Bend because they can get clearance there for the altitudes they expect to hit. When they want to go higher (say, the 100km mark), they'll have to go to Alaska, from what I hear. Alaska's got the only true spaceport that's not NASA controlled, and with (easier) FAA approval you can actually launch from there. Or try for a sea-launch and hope you don't flub the schedule <g>
Um, 21.5Mbps is pathetic for a DeCSS routine, if it takes all of the CPU. DeCSS should take less than 2% of a PIII 333, otherwise you don't have any time left over for actually *decoding* the MPEG2 video.
GStreamer is a project I and another person are currently working on pretty much full time (I'm between jobs and he's on vacation) at the moment. It's been around for a bit over a year, and has grown considerably since in that time. It's a pipeline-based architecture somewhat similar to M$'s DirectShow, allowing arbitrary graphs of plugin filters, processing just about any kind of streamable media you can think of.
This lends itself quite a bit to distributed processing, since you simply (for now) code up an element pair that will enable you to join two pipelines over the network, via TCP or somesuch. Eventually we plan to have CORBA interfaces wrapped around everything, which while slowing down data tranfers, has the potential to make everything even easier.
A release is planned for the beginning of next year (midnight, Jan 1st, Millennium Release), which should provide people with a stable enough API to start writing apps with it. There are still going to be some major changes like a shift to GObject (currently uses GtkObject, so it's tied to X, bleagh), and some major feature enhancements like the graphical pipeline editor. Changes to the system should affect plugin writers mostly, as the "user-level" API should remain basically the same.
The two of us are interested in audio and video respectively. I want to build a live mixing system, he wants to build an NLE. The two have much overlap even ignoring the GStreamer core, so things should get interesting. There are some other people with some pretty cool ideas that we'll try to incorporate, one of which is distributed processing.
Anyone interested in this project should head over to http://www.gstreamer.net/ and sign onto the mailing list (gstreamer-devel). We'll be busy coding through the end of the year, but we welcome anyone who would like to use the system. The scheduling system is currently being re-written for the 4th or 5th (and hopefully last) time, so anyone with specific use cases can help the process along by enumerating them to make sure the scheduler can deal with even the most bizarre cases.
As far as VST and other plugins, there's a project called LADSPA that's building a plugin interface similar to VST. Quite a few plugins are already available, including FreeVerb. The problem with VST is that it embeds the Windows-based GUI into the plugin. This might be shimmed with libwine or something, but is a tough problem. If someone would liket o tackle that, please, step right up, we'll help you as much as we possibly can.
The whole concept of Intellectual Property "rights" being held on a database of the Human Genome very much disturbs me. Last I checked, it was supposed to be impossible to obtain copyright or a patent on something that is *fact*, correct? Now, last I checked, the Human Genome was a *fact*. Celera didn't invent the Human Genome, *God* did. If there are any intellectual property rights to be upheld, they belong to God. At the very least claiming ownership of it is heretical.
I fully acknowledge that there was a significant amount of work required to actually sequence this fact, and there should be commercial reward. But it seems that there exists no system as of now to do this. What options are there that don't assert ownership of the facts of the Genome?
This country is simply property-happy, especially when something isn't ownable in the first place.
I went to a M$ XML conference a month or so ago (hey, work paid for it and I got a semi-decent XML book for free too), and what they spent the most time touting was their new BizTalk setup. Basically, there's a repository at biztalk.org or somesuch, where biztalk schemas live (they wrote their own DTD for the schemas, of course). Various companies are supposed to post their schemas here, and eventually any given industry is supposed to be able to develop a single schema. In the meantime, M$ provides the tools necessary (using "The Amazing msxml3.dll") to make conversion from format to format "easy".
There's nothing here that can't be done open-source, as far as I know. And even if you don't want to go BizTalk right away, definitely consider the implications of what they've done before going and implementing anything.
It must be said that every once in a while M$ does something actually kinda innovative. They are doing a lot of cool stuff with XML that no one else is doing, so you have to give them credit for that much. Their OS's, on the other hand...
I had this idea several years ago. My take on it is that over time, all programs should move over to a configuration library, something quite simple and based on XML. In the meantime, open(2) could be patched into to create fake files any time you open a config file, and it would generate a 'legacy' file. Yes, slow, but feasible.
The idea would be to store everything in XML, but with the ability to embed LDAP queries, and Perl source, etc. Think about an admin trying to set up a 10,000-node desktop network for pick-a-big-company. They don't want to have to set up this huge system to configure systems remotely via CORBA (though for tuning single machines that's a great idea, given lots and lots and lots of security). They want to be able to create ghost machines that can be installed by your favorite high-school intern support monkey (for the record I was a high-school intern test monkey).
With a proper, and relatively simple, XML DTD that includes LDAP and scripting, you simply generate a default config file with switchouts, for instance at the top of the config file it does a simple LDAP check to see if there's anything odd about the machine. If so, later on down the config file things get more interesting with more queries. Else, it just uses the defaults.
Also, includes and local queries can be done, so if you have things like a standardized network setup (at OGI the router is always x.y.z.54), a proper config file can actually derive things. resolv.conf can include a simple translation that creates the DNS IP from the host's IP (at OGI the dns is always x.y.z.2).
The potential power of a system like this, not just for large installations, but for single systems (specifically, an admin system becomes near child's play) is immense. Unfortunately, every Unix utility/daemon/program/game has its own config file format.
Good luck moving sendmail to an XML config file....
Keep in mind that even though MPEG-4 is an ISO standard, that doesn't mean it's free. MPEG-2 requires a $4 license every time anything MPEG-2 related is transfered to a consumer. That means no free players. We have no idea what MPEG-4 licensing is going to look like, but I'm not holding my breath. I ran across a document showing that all the big patent players explicitly objected to free implementations of BIFS, which AFAICT is the equivalent of Program/System Streams for MPEG-4. If we can't even get a free implementation of the transport stream code, how are we going to get a free implementation of the codec itself?
While anyone with a brain can plainly see that free decoders are critical to any kind of market share on the Internet, these are lawyers making these licensing decisions. We all know that lawyers live in their own little litigious world, and can't generally be counted on to have any connection to reality. I wouldn't at all be surprised to find MPEG-4 requires a $N license just to get a player.
Of course, the whole idea of International Standards that can't be used by anyone is patently (heh) ridiculous. How to deal with this, I have no idea, short of creating a new codec that rivals MPEG-4, which is no easy task. Perhaps we can find a way to make our voice heard to the various lawyers deciding licensing, but I'd rate that as a rather low chance of success.
Suggestions as to how we can deal with this problem would be welcome....
The GeForce 256 (and it's successor) was on my list of cards to consider when looking for a new video card. No longer. NVidia has made it plain that they will never release source for their driver, and I'm making it plain that they will never have my business. It's simple. For any device as complex as a 3D accelerated video card, I will not be held hostage by the schedules of a company who doesn't consider me, a customer, a priority.
I encourage everyone who feels this way to write directly to NVidia and tell them.
If you're willing to wait about a month and spend about $1000, get the Coolpix 990. According to every review I've read, it dropkicks even my 950 into the next county. 3.3 megapixels, so images of 2048x1536. More features, better features, etc (all reviews are of preproduction camers, so few real details yet). Has USB, but one major problem is that all the reviews say that it does not have a CF Type II slot. Big mistake, since all the big cards (224MB flash, 340MB microdrive, etc.) are in Type II format (which is a millimeter thicker), and you're going to be shooting 9.5MB raw images! (or 1.xMB high-quality JPEGs, better get that 8x CF card...)
I'd suggest that the profits from this book not be given to a traditional charity, but for something else: From the money gathered from the sale of this book, give a copy to each and every school Principal, Vice Principal, Counselor, and whoever else needs to hear. Get students from every school to make sure that these books get to the people who need read them, and make sure that they do. That is what will do the most good, by far.
The EFF definitely needs to get active in the press battle. Perhaps OpenDVD.org as well. I'm more than willing to spend time developing press kits, handouts, fliers, and camera-ready advertisements, etc. for this effort, though I imagine people may want me spending my time coding. I do have the tools (PageMaker) and the experience, however.
Also, I came up with a good title for a rebuttal:
"If You Can't Watch What You've Purchased, You've Been Ripped Off"
Slashdot Mirror
Of course, the military has a lot of firepower, and Stallman doesn't have any, so it is probably a moot point.
Isn't that why we have ESR?
First of all, the focus of the article was indeed multimedia, from the point of view of the average person who wants to use Linux to watch DVDs and videos off the net. These people really couldn't care less about perfect sample accuracy of their $10 sound card. Trying to force pro-audio qualities onto every machine is impossible, and highly counterproductive in the face of other more visible issues.
GStreamer is indeed an infrastructure for building multimedia apps. Absolutely everything it does is under the auspices of the elements that it loads and connects together. Claiming that GStreamer has no means of inter-application communication is false, as there are already numerous elements both for communication with sound servers and other applications (network source/sinks, etc.). A set of Jack elements are being written, as well.
GStreamer also has nothing to do with the GUI whatsoever. Elements are GObjects that have no GUI in them at all, they focus on doing what they're supposed to. Any GUI exists as a seperate entity on top of the processing pipeline as managed by GStreamer.
If your worry is that LADSPA won't be used, don't. LADSPA plugins are fully supported with a shim under GStreamer.
As for whether to sync to audio or video, you actually have it quite backwards. First of all, the most difficult situation is not with progressive video, but with field-based video (which both NTSC and PAL are, BTW), where the vertical rates are 50 or 59.95Hz. Compare this to a CRT, and you have significant problems finding a decent match between them.
As for the "content" business somehow making video more important than audio, you're ignoring the fact that video *is* more important than audio when both are present together in the same stream. There are several order of magnitude more bits in the video than than the audio, anyway.
Now, to the technical reasons it makes vastly more sense to absorb changes in the audio clock:
1) 90+% of computers have sound cards with clocks that can be best described as "kinda sorta correct". They vary wildly around the real 44.1k baseline. If anyone notices this, there's not much they can do about it. More fundamentally, how are you going to maintain any kind of stream clock when the audio rate is changing during the presentation (as it will when temperature and other things change in your computer, since the clock is susceptable to this)?
2) The quanta of video playout is much greater than that of audio, on the order of 500+ times larger. The goal of any good video playback is to synchronize the playout of a video frame (theoretical time unit) to a vertical refresh (physical time unit). If at any point those become desynchronized, you will have a discontinuity of at least one vertical retrace, or on average about one 75th of a second. Specifically, you'll have a video frame that is suddently displayed for between 50% and 100% longer than it's supposed to be, in the middle of a bunch of correct frames. This is *blatantly* noticable by anyone with a normal visual cortex.
Audio, and the human ear, is much more forgiving. If the program simply drops or duplicates a sample every once in a while to maintain minimal drift between the two (video and audio) clocks, it will be altering 1/44,100th of the samples in that second. If done wrong, it will cause a click. Doing it "less wrong" to avoid clicks is trivial.
So the decision is between locking to a highly variable audio clock (think 3.6 seconds per hour per 0.1% off) and having video that jerks and sputters whenever the theoretical and physical frame times disagree, or doing some resampling to the audio where necessary, with the possibility of some loss of quality that is undetectable by 99% of people watching videos on their computer with tinny speakers.
Me, I don't like video-induced headaches, I'll resample the audio.
Bootable CDs certainly are a problem. Remember, this is Windows, not Linux. You can't just put a kernel at the top of the disk and let it start. The boot sequence for a Windows CD is much more complicated than it is on a partition.
FYI, there is a significant difference between recovery CDs and a recovery partition. It is fundamentally impossible to "just burn the recovery partition to CDs". First, how do you get a bootable CD? Then, how do you split the files across the CDs? And tell the installer where to get the files it needs, etc, etc, etc.
As a lead GStreamer developer, and someone very interested in Tarkin, I must point out that what was added was a plugin to "w3d", a candidate technology for Tarkin. There is no Tarkin codec, yet, and won't be for some time, as there is still heavy research into what the best type of codec is for this task. w3d is just one of many attempts to make something workable, albeit the most successful so far. Unfortunately, my hint that the plugin should be called "w3d" was ignored ;-(
No, when buying a new car, you ask how many pot-holes it will go over before a wheel falls off. Or in my case (see "Dell Inspiron 7500" cid 2923987), how many times you can open and close your laptop before the screen falls off.
I've had a PIII-500 for about 26 months now, and it's already been back twice, and about to go back a third time (as soon as I can part with it for a week). It has the 1400x1050 UXGA screen, which was basically duct-taped to the top of a smaller laptop body. As a result, the mounts for the two screen hinges are a joke. The cross-sectional area at the bottom is minimal, and the metal quality was pathetic, albeit from my minimal metalurgical knowledge.
First the left hinge-mount snapped. This rendered the laptop completely unusable. Sent it in for repair, they replaced the whole screen. Nice enough to transplant my stickers though.
Then, exactly two days (a weekend) before my trip to Europe for 2 weeks for GUADEC-2, the right hinge-mount snapped, same place, same ragged pot-metal edge, etc. Managed to borrow a laptop, just barely. Turns out that the geniuses at Dell figured that the right-hand mount would be fine after the whole screen dangled at odd angles for an extended duration (attempted workarounds, shipping, etc.), and left it. Fatally wounded.
Well, the current predicament is that now the left hinge-mount is still in one piece (not sure I can say the same for the right one for much longer...), but it's screwed into a completely detached section of the *FRAME*. That's right, the entire mass of some kind of metal to which the tiny little hinge-mount is screwed has totally sheared off. It's held in by the outer plastic shell. I've managed to limp along for a couple months now, but it's gonna get sent in in a week or two.
I *STRONGLY* recommend that any laptop you consider, you get your hands on one (a friend/coworker with one, even ask on a local newsgroup if you have to) and check it out for some of these brain-dead design flaws. I'm still considering Dell when replacing this one in another year or so, but I will be doing some heavy research on the 8[12]00 models available at the time, as far as structural integrity.
However, I've heard all sorts of bad things about the "feel" of Dells vs. other laptop brands, and I have to agree. For all the killer features and decent price they put into their laptops, it's almost universally agreed upon that the construction quality, as far as structural integrity and longevity, sucks.
Spend some time in the DellNet Forum, and probably the equivalent foraa for other manufacturers. You won't regret it.
The Ethernet frame header portion of the packet, below the IP header, is the only place there is a MAC address. This frame header is stripped of by each and every router, because it is only used for the local segment. When the router places the packet on a new network to send it upstream to the next router, it places its own MAC address in the source and the MAC address of the next hop router in the destination. This is how all ethernet/IP routing is done. Other mediums such as ATM have variations on this theme.
A NAT box is by definition a router, and a packet-mangling router at that. The MAC source address on every single packet coming *through* the NAT box is that of the NAT box.
No, MAC addresses never leave the network segment they're on. They are part of the Ethernet frame header, which is stripped by each and every router, including the NAT box.
What you really want is a regular laptop with a Firewire audio interface. There are several on the market now geared more towards multi-channel stuff, but I'm working on a hardware design that would make a high-quality (think 24bit, 192KHz) stereo output relatively cheap (say $100). Email me at omega at temple - baptist dot com for more info, but don't expect anything usable for a few months ;-}
I built one while working at OGI a few years ago. I've got a copy of the pages on my current server, at http://www.temple-baptist.com/~omega/ogimabot2/, with a little info on it. I should see if the prof. I was working with still has the slides to convert to HTML...
They're supposedly going to be building a new one soon, and so my research into a next-gen robot may be put to use. I was looking very closely at the Cell Computing parts (http://www.cellcomputing.com/), which aren't cheap ($1k-$1.5k depending), but are the right size and somewhat designed for that kind of stuff. Put that in (instead of on top of, like the current bot) the car (thinking of using a monster-truck chassis) and you can do pretty good. Email me if you have other questions, because I spent a huge amount of time on this project and its related issues.... nospam_omega@temple-nospambaptist. com
Indeed. I've played with one for a few minutes. Very cool device. The unit I used was somewhat slow for a reason that will be irrelevant once it's rolled out, and is already irrelevant in their labs IIRC. The processor is rather slow, but that's part of their business model. If they can rev the unit for 2nd gen with a much faster chip, it could be very cool. However, it does *not* act like a Palm, and would have a hard time doing so. But that's entirely software... I would imagine someone could put PalmOS on this hardware (with a touch screen added).
There's only one author of Broadcast 2000, going by the name 'Heroine Virtual'. He now works for Pioneer, and I'm wondering if he was told to stop work on the project and is finding some way to do so without making it obvious? Or if Pioneer is going to use the project somehow. This would worry me, because a lot of people, including myself (co-author of libdv) have code that is distributed in the b2k tarball. Since it's all [L]GPL'd, there's significant potential for Pioneer to make a mess.
I worked with several people who now work for RuleSpace, and they explained some of what they're doing. RuleSpace has defined a large number (several hundred) of very tightly defined categories. Their compute farm goes over pages and anaylzes them based on content and context, not keywords. They're assigned any number of categories as appropriate, and the user can then (if AOL exposes these small categories) turn on and off different sets of content. Humans go over a sample of the results and verify that the computer successfully assigned all the right catgories, and re-train the computers if they mess up. One question I have though: when they retrain the nets, do they queue up all the already analyzed pages for re-analysis?
Fine-grained categorization means that parents can then fine-tune what is blocked for their children. Libraries (if forced to use filtering) can know that they're blocking only things that are not allowed in their community. It's no longer a matter of "Do I trust what they think is acceptable?", but an excercise in deciding what is acceptable
No, I'm not a RuleSpace employee, I just believe that this technology (if it's done right) is the best solution by far. If they can't pull it off correctly, I'll be just as against using their filtering as anyone elses, but I think they're on the right track.
Score one for AOL (a very rare thing).
While this story may be fictional, there is a group from Portland, OR that are working on rockets to be fired from Bend, OR. Their website is at www.psas.pdx.edu. They're working on inertial navigation, and recently put out a call for volunteers to work on a port of [uC]Linux to the mpc555 chip, which is a PPC variant.
They are launching from Bend because they can get clearance there for the altitudes they expect to hit. When they want to go higher (say, the 100km mark), they'll have to go to Alaska, from what I hear. Alaska's got the only true spaceport that's not NASA controlled, and with (easier) FAA approval you can actually launch from there. Or try for a sea-launch and hope you don't flub the schedule <g>
Um, 21.5Mbps is pathetic for a DeCSS routine, if it takes all of the CPU. DeCSS should take less than 2% of a PIII 333, otherwise you don't have any time left over for actually *decoding* the MPEG2 video.
GStreamer is a project I and another person are currently working on pretty much full time (I'm between jobs and he's on vacation) at the moment. It's been around for a bit over a year, and has grown considerably since in that time. It's a pipeline-based architecture somewhat similar to M$'s DirectShow, allowing arbitrary graphs of plugin filters, processing just about any kind of streamable media you can think of.
This lends itself quite a bit to distributed processing, since you simply (for now) code up an element pair that will enable you to join two pipelines over the network, via TCP or somesuch. Eventually we plan to have CORBA interfaces wrapped around everything, which while slowing down data tranfers, has the potential to make everything even easier.
A release is planned for the beginning of next year (midnight, Jan 1st, Millennium Release), which should provide people with a stable enough API to start writing apps with it. There are still going to be some major changes like a shift to GObject (currently uses GtkObject, so it's tied to X, bleagh), and some major feature enhancements like the graphical pipeline editor. Changes to the system should affect plugin writers mostly, as the "user-level" API should remain basically the same.
The two of us are interested in audio and video respectively. I want to build a live mixing system, he wants to build an NLE. The two have much overlap even ignoring the GStreamer core, so things should get interesting. There are some other people with some pretty cool ideas that we'll try to incorporate, one of which is distributed processing.
Anyone interested in this project should head over to http://www.gstreamer.net/ and sign onto the mailing list (gstreamer-devel). We'll be busy coding through the end of the year, but we welcome anyone who would like to use the system. The scheduling system is currently being re-written for the 4th or 5th (and hopefully last) time, so anyone with specific use cases can help the process along by enumerating them to make sure the scheduler can deal with even the most bizarre cases.
As far as VST and other plugins, there's a project called LADSPA that's building a plugin interface similar to VST. Quite a few plugins are already available, including FreeVerb. The problem with VST is that it embeds the Windows-based GUI into the plugin. This might be shimmed with libwine or something, but is a tough problem. If someone would liket o tackle that, please, step right up, we'll help you as much as we possibly can.
The whole concept of Intellectual Property "rights" being held on a database of the Human Genome very much disturbs me. Last I checked, it was supposed to be impossible to obtain copyright or a patent on something that is *fact*, correct? Now, last I checked, the Human Genome was a *fact*. Celera didn't invent the Human Genome, *God* did. If there are any intellectual property rights to be upheld, they belong to God. At the very least claiming ownership of it is heretical.
I fully acknowledge that there was a significant amount of work required to actually sequence this fact, and there should be commercial reward. But it seems that there exists no system as of now to do this. What options are there that don't assert ownership of the facts of the Genome?
This country is simply property-happy, especially when something isn't ownable in the first place.
I went to a M$ XML conference a month or so ago (hey, work paid for it and I got a semi-decent XML book for free too), and what they spent the most time touting was their new BizTalk setup. Basically, there's a repository at biztalk.org or somesuch, where biztalk schemas live (they wrote their own DTD for the schemas, of course). Various companies are supposed to post their schemas here, and eventually any given industry is supposed to be able to develop a single schema. In the meantime, M$ provides the tools necessary (using "The Amazing msxml3.dll") to make conversion from format to format "easy".
There's nothing here that can't be done open-source, as far as I know. And even if you don't want to go BizTalk right away, definitely consider the implications of what they've done before going and implementing anything.
It must be said that every once in a while M$ does something actually kinda innovative. They are doing a lot of cool stuff with XML that no one else is doing, so you have to give them credit for that much. Their OS's, on the other hand...
I had this idea several years ago. My take on it is that over time, all programs should move over to a configuration library, something quite simple and based on XML. In the meantime, open(2) could be patched into to create fake files any time you open a config file, and it would generate a 'legacy' file. Yes, slow, but feasible.
The idea would be to store everything in XML, but with the ability to embed LDAP queries, and Perl source, etc. Think about an admin trying to set up a 10,000-node desktop network for pick-a-big-company. They don't want to have to set up this huge system to configure systems remotely via CORBA (though for tuning single machines that's a great idea, given lots and lots and lots of security). They want to be able to create ghost machines that can be installed by your favorite high-school intern support monkey (for the record I was a high-school intern test monkey).
With a proper, and relatively simple, XML DTD that includes LDAP and scripting, you simply generate a default config file with switchouts, for instance at the top of the config file it does a simple LDAP check to see if there's anything odd about the machine. If so, later on down the config file things get more interesting with more queries. Else, it just uses the defaults.
Also, includes and local queries can be done, so if you have things like a standardized network setup (at OGI the router is always x.y.z.54), a proper config file can actually derive things. resolv.conf can include a simple translation that creates the DNS IP from the host's IP (at OGI the dns is always x.y.z.2).
The potential power of a system like this, not just for large installations, but for single systems (specifically, an admin system becomes near child's play) is immense. Unfortunately, every Unix utility/daemon/program/game has its own config file format.
Good luck moving sendmail to an XML config file....
Keep in mind that even though MPEG-4 is an ISO standard, that doesn't mean it's free. MPEG-2 requires a $4 license every time anything MPEG-2 related is transfered to a consumer. That means no free players. We have no idea what MPEG-4 licensing is going to look like, but I'm not holding my breath. I ran across a document showing that all the big patent players explicitly objected to free implementations of BIFS, which AFAICT is the equivalent of Program/System Streams for MPEG-4. If we can't even get a free implementation of the transport stream code, how are we going to get a free implementation of the codec itself?
While anyone with a brain can plainly see that free decoders are critical to any kind of market share on the Internet, these are lawyers making these licensing decisions. We all know that lawyers live in their own little litigious world, and can't generally be counted on to have any connection to reality. I wouldn't at all be surprised to find MPEG-4 requires a $N license just to get a player.
Of course, the whole idea of International Standards that can't be used by anyone is patently (heh) ridiculous. How to deal with this, I have no idea, short of creating a new codec that rivals MPEG-4, which is no easy task. Perhaps we can find a way to make our voice heard to the various lawyers deciding licensing, but I'd rate that as a rather low chance of success.
Suggestions as to how we can deal with this problem would be welcome....
The GeForce 256 (and it's successor) was on my list of cards to consider when looking for a new video card. No longer. NVidia has made it plain that they will never release source for their driver, and I'm making it plain that they will never have my business. It's simple. For any device as complex as a 3D accelerated video card, I will not be held hostage by the schedules of a company who doesn't consider me, a customer, a priority.
I encourage everyone who feels this way to write directly to NVidia and tell them.
If you're willing to wait about a month and spend about $1000, get the Coolpix 990. According to every review I've read, it dropkicks even my 950 into the next county. 3.3 megapixels, so images of 2048x1536. More features, better features, etc (all reviews are of preproduction camers, so few real details yet). Has USB, but one major problem is that all the reviews say that it does not have a CF Type II slot. Big mistake, since all the big cards (224MB flash, 340MB microdrive, etc.) are in Type II format (which is a millimeter thicker), and you're going to be shooting 9.5MB raw images! (or 1.xMB high-quality JPEGs, better get that 8x CF card...)
Oh, and the Coolpix 9x0 just looks cool.
I'd suggest that the profits from this book not be given to a traditional charity, but for something else: From the money gathered from the sale of this book, give a copy to each and every school Principal, Vice Principal, Counselor, and whoever else needs to hear. Get students from every school to make sure that these books get to the people who need read them, and make sure that they do. That is what will do the most good, by far.
The EFF definitely needs to get active in the press battle. Perhaps OpenDVD.org as well. I'm more than willing to spend time developing press kits, handouts, fliers, and camera-ready advertisements, etc. for this effort, though I imagine people may want me spending my time coding. I do have the tools (PageMaker) and the experience, however.
Also, I came up with a good title for a rebuttal:
"If You Can't Watch What You've Purchased, You've Been Ripped Off"