Sorry, you're right, it's not a ripper. But VirtualDub is often used in the edit/encode process.
But, my point remains valid. Look at the top 5. All P2P clients. If something like the INDUCE act were to pass then it sure looks like they could come after SourceForge.
Of the top 10, 7 are file sharing apps commonly associated with illegal trading of movies. Then you have VirtualDub and CDex, for ripping DVDs and CDs respectively. Rounding out the top 10 is gaim.
Is it only a matter of time before the MPAA comes after Sourceforge?
And does anyone else find it depressing that trading copyrighted works seems to be by far the most popular use for open source software?
I realise that this is probably going to get me beaten up, but why the hell is the city government planning on offering this service anyway? Surely the provision of broadband internet services for a fee is a job for a private company, not a job for the government.
If it worked this way then the service would be available now. It isn't. Therefore the free market has failed to meet this need, and the government should be free to do so. QED.
As a Linux audio developer I would have to agree with you. Very few people on LAD claim this stuff is ready for prime time yet. So, please don't jump to conclusions about Linux audio sucking, give it a year or so. The usability issues are universally acknowledged and people are working on it...
Come on, MontaVista, don't try to cock things up for the rest of Linux just because you're too lazy to patch the kernel yourself.
If you read MontaVista's original announcement, it was not posted for inclusion in the mainstream kernel, no one (including MontaVista) is claiming that it is ready. They merely posted their work to stimulate discussion and to avoid duplication of effort. So of course Linus is right, no one ever said it _should_ go in the kernel now or even anytime soon.
Why was this modded "Insightful", the poster clearly has not bothered to understand the situation.
Speaking as someone who actually downloaded and tested these patches, I would not worry too much. This stuff is all very rough around the edges, though it has amazing potential.
If the patches were mature and worked well, and Linus rejected them, it would be news. For now he is just saying "Show me the money". Nothing new, the burden of proof is on people who introduce new features like this to prove them stable, and it just hasn't happened, yet.
You can always come to slashdot for a good rehash of the week's stupidest LKML threads.
Re:I wonder if it's true real-time
on
RT Linux Patches
·
· Score: 2, Informative
Be aware that there has been some question weather or not Timesys is violoating the GPL. I don't have the links on me but if you search the LKML for "Timesys" you will find at least a couple of messages questioning their proprietary scheduler work.
This is BS. The Timesys people have posted lots of quality GPL'ed code to LKML. They have never been accused of violating the GPL by anyone credible.
Troll.
Re:What Real Time is and what you can do with it.
on
RT Linux Patches
·
· Score: 1
Mod parent up! I wish more Linux developers understood this. You would be surprised how many apps still don't support ALSA properly because the developers insist on the old "cat file.wav >/dev/dsp" model. This is a neat trick but it ignores the realtime nature of audio.
Not sure what you mean, it all looks fine on my machine.
Re:Soft real-time Vs Hard real-time
on
RT Linux Patches
·
· Score: 1
There are two types of real-time, soft and hard. This is how you distinguish the two:
Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".
There is actually a significant and interesting grey area in between. Operating the control rods in a nuclear plant would clearly be hard realtime. Desktop audio playback imposes a soft realtime constraint (because there will be gaps if you dont keep up). But what about the Mt. St. Helens example mentioned in the article? Or, what about audio playback/mixing where you are connected to a sound system loud enough that a pop or a click would damage people's hearing?
Re:Compare this to Ingo Molnar's 'Voluntary Preemp
on
RT Linux Patches
·
· Score: 3, Informative
Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?
From reading the I/O Kit docs (the driver writers guide for OSX, google for it) it looks like OSX does it the same way as Linux with Ingo's patches, they have a preemptible kernel and a realtime scheduling class for multimedia apps, and IRQs appear to be threaded, though the exact mechanism is unclear. The Mach ancestry helps in other areas, Mach ports on OSX are allegedly are a faster IPC mechanism than even Linux FIFOs.
Personally, I'd be satisfied if they (or someone) semaphored everything at a low enough granularity to allow multiple processes in kernel context at the same time.
RTFA. Or (god forbid) the code.
Linux has allowed multiple processes in kernel context at the same time for ages. It's called SMP and/or CONFIG_PREEMPT.
Re:Compare this to Ingo Molnar's 'Voluntary Preemp
on
RT Linux Patches
·
· Score: 5, Informative
This incorporates some aspects of Ingo's VP patches that are prerequisites for any kind of RT support the kernel. These include offloading all softirqs to ksoftirqd (normally softirqs run immediately unless the load gets too high in which case they hand off to koftirqd) and IRQ threading, which created a separate thread for each irq and offloads hardirqs (aka the "top half" of an interrupt handler) to that thread. If you stop here the latency is about as good as OSX.
This is where the two approaches diverge. The VP approach uses normal kernel preemption, with the addition of scheduling points with optional lock break inside spinlocked code. But you still cannot preempt code that is holding a spinlock. This becomes the lower bound on latency.
MontaVista goes even further, replacing spinlocks with priority inheriting mutexes, so you now can preempt code that would not be preemptible with VP.
In practice VP gives better latency right now by about half. But as another poster pointed out this is probably due to debugging overhead and probably a few bugs, the VP approach has reached the limit while this is capable of improving worst case response times by a few more orders of magnitude. This is a great development.
Too bad they didn't contract out these units to a manufacturer that added in built-in fans like the AC adaptors on the VIA Mini-ITX models...
Christ, you mean these "fanless" boards actually have a fan in the outboard power supply?!? What a rip! People buy fanless hardware because they *need* it to be quiet, say for sound recording. Thanks for warning me before I bought one!
So is there still no such thing as a truly fanless PC?
Christ, you mean these "fanless" boards actually have a fan in the outboard power supply?!? What a rip! People buy fanless hardware because they need it to be quiet. Thanks fot the tip, I will avoid these.
PS, you know what they said about Mussolini right? "At least he made the trains run on time" - that doesn't excuse all the other abusive things he did and getting even a portion of your mechanical royalties certainly does not excuse the RIAA from all the other terrible things they have done just because they were (and remain) in a position to get away with it.
Invoking Mussolini instead of Hitler to get around Godwin's Law. This is a new low.
The INDUCE act only seems to cover cases where the
P2P software companies make money from this alleged
inducement to infringe. I have yet to see anyone propose legislation that would make, say, gtk-gnutella illegal.
Seeing as how most of the commercial P2P software
developers' "ad revenue" seems to come from
installing spyware and trojans on unwitting folks'
machines, I can't say I will be sad to see them go.
Slashdot Mirror
Please, go back to fark.com.
The exceptions to this (guns, marijuana, and other things we've allowed to be banned) prove the rule
My ass. Guns are not banned.
What the fuck country do you live in?
Sorry, you're right, it's not a ripper. But VirtualDub is often used in the edit/encode process.
But, my point remains valid. Look at the top 5. All P2P clients. If something like the INDUCE act were to pass then it sure looks like they could come after SourceForge.
Check out the top sourceforge downloads for the week.
Of the top 10, 7 are file sharing apps commonly associated with illegal trading of movies. Then you have VirtualDub and CDex, for ripping DVDs and CDs respectively. Rounding out the top 10 is gaim.
Is it only a matter of time before the MPAA comes after Sourceforge?
And does anyone else find it depressing that trading copyrighted works seems to be by far the most popular use for open source software?
It's good to see they finally sped up yum, it was HORRIBLE in FC2... took 10x as long to do the same thing as apt-get upgrade.
What he said. The cool thing about Audacity is that it's small and self-contained, the Windows version runs great from a USB key drive.
As a Linux audio developer I would have to agree with you. Very few people on LAD claim this stuff is ready for prime time yet. So, please don't jump to conclusions about Linux audio sucking, give it a year or so. The usability issues are universally acknowledged and people are working on it...
Come on, MontaVista, don't try to cock things up for the rest of Linux just because you're too lazy to patch the kernel yourself.
If you read MontaVista's original announcement, it was not posted for inclusion in the mainstream kernel, no one (including MontaVista) is claiming that it is ready. They merely posted their work to stimulate discussion and to avoid duplication of effort. So of course Linus is right, no one ever said it _should_ go in the kernel now or even anytime soon.
Why was this modded "Insightful", the poster clearly has not bothered to understand the situation.
Speaking as someone who actually downloaded and tested these patches, I would not worry too much. This stuff is all very rough around the edges, though it has amazing potential.
If the patches were mature and worked well, and Linus rejected them, it would be news. For now he is just saying "Show me the money". Nothing new, the burden of proof is on people who introduce new features like this to prove them stable, and it just hasn't happened, yet.
You can always come to slashdot for a good rehash of the week's stupidest LKML threads.
Be aware that there has been some question weather or not Timesys is violoating the GPL. I don't have the links on me but if you search the LKML for "Timesys" you will find at least a couple of messages questioning their proprietary scheduler work.
This is BS. The Timesys people have posted lots of quality GPL'ed code to LKML. They have never been accused of violating the GPL by anyone credible.
Troll.
Mod parent up! I wish more Linux developers understood this. You would be surprised how many apps still don't support ALSA properly because the developers insist on the old "cat file.wav > /dev/dsp" model. This is a neat trick but it ignores the realtime nature of audio.
Not sure what you mean, it all looks fine on my machine.
There are two types of real-time, soft and hard. This is how you distinguish the two:
Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".
There is actually a significant and interesting grey area in between. Operating the control rods in a nuclear plant would clearly be hard realtime. Desktop audio playback imposes a soft realtime constraint (because there will be gaps if you dont keep up). But what about the Mt. St. Helens example mentioned in the article? Or, what about audio playback/mixing where you are connected to a sound system loud enough that a pop or a click would damage people's hearing?
Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?
From reading the I/O Kit docs (the driver writers guide for OSX, google for it) it looks like OSX does it the same way as Linux with Ingo's patches, they have a preemptible kernel and a realtime scheduling class for multimedia apps, and IRQs appear to be threaded, though the exact mechanism is unclear. The Mach ancestry helps in other areas, Mach ports on OSX are allegedly are a faster IPC mechanism than even Linux FIFOs.
Personally, I'd be satisfied if they (or someone) semaphored everything at a low enough granularity to allow multiple processes in kernel context at the same time.
RTFA. Or (god forbid) the code.
Linux has allowed multiple processes in kernel context at the same time for ages. It's called SMP and/or CONFIG_PREEMPT.
This incorporates some aspects of Ingo's VP patches that are prerequisites for any kind of RT support the kernel. These include offloading all softirqs to ksoftirqd (normally softirqs run immediately unless the load gets too high in which case they hand off to koftirqd) and IRQ threading, which created a separate thread for each irq and offloads hardirqs (aka the "top half" of an interrupt handler) to that thread. If you stop here the latency is about as good as OSX.
This is where the two approaches diverge. The VP approach uses normal kernel preemption, with the addition of scheduling points with optional lock break inside spinlocked code. But you still cannot preempt code that is holding a spinlock. This becomes the lower bound on latency.
MontaVista goes even further, replacing spinlocks with priority inheriting mutexes, so you now can preempt code that would not be preemptible with VP.
In practice VP gives better latency right now by about half. But as another poster pointed out this is probably due to debugging overhead and probably a few bugs, the VP approach has reached the limit while this is capable of improving worst case response times by a few more orders of magnitude. This is a great development.
Argh, fucking slashdot back-button bug.
If your web application breaks when users use the back button it is BROKEN!
Too bad they didn't contract out these units to a manufacturer that added in built-in fans like the AC adaptors on the VIA Mini-ITX models...
Christ, you mean these "fanless" boards actually have a fan in the outboard power supply?!? What a rip! People buy fanless hardware because they *need* it to be quiet, say for sound recording. Thanks for warning me before I bought one!
So is there still no such thing as a truly fanless PC?
Christ, you mean these "fanless" boards actually have a fan in the outboard power supply?!? What a rip! People buy fanless hardware because they need it to be quiet. Thanks fot the tip, I will avoid these.
Invoking Mussolini instead of Hitler to get around Godwin's Law. This is a new low.
Seeing as how most of the commercial P2P software developers' "ad revenue" seems to come from installing spyware and trojans on unwitting folks' machines, I can't say I will be sad to see them go.