Re: [LAD] Kim did the switch to Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a funny story to this: Some weeks ago I jammed with a friend, a convinced osx user, at home. My all purpose notebook was running with openoffice firefox and thunderbird and eclipse as I worked with it before, so there was a first strange look from my friend: Won't you close these for your audio session? Nah why should I do that? I then started Zyn, Timemachine and Jamin to record the stuff which came out of our Synths and connected my midi-keyboard via usb to zyn. During the jam we came to the idea to connect the keyboard directly to his spectralis for better note entry. So he just removed it from its USB port to connect it to the spectralis and got really pale and shocked. I asked What happend? Well, doesn't removing the midi device crash the application? In OSX I often have to disconnect it before because otherwise the app will sometimes crash... Just had to grin :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp70FAACgkQVC26eJ+o0+0TXgCfS7FB2AFaQ1e16k2thl4qQI4M mBgAoJ2ToIenUbdkW1coTOQcY32FQEDs =/xIp -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
David Robillard: Let's just fix the interaction between pulse and jack and be done with it. That is one solution. It's harmful to suggest that it things are less than they are Read the user posts in this thread, or ths post that started it. Things are as they are. Pretending everything is fantastic when it's not doesn't help either. Well, in my opinion, everything really is fantastic right now. Pulseaudio interacts perfectly with jack, pulseaudio doesn't screw up jack in any way (as far as I can remember observing), and all programs using jack, alsa or pulseaudio make sound, simultaneously, without any notable latencies issues with alsa programs. Maybe I was lucky, and I'm probably not a newbie either, but at least I'm not _pretending_ everything is fantastic: it really is. A person coming directly from win/mac probably wouldn't have succeeded though, since jack needed to be configured and I had to manually install the pulseaudio jack sink, edit various files in /etc/, plus perhaps doing other stuff I don't remember anymore. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Running pulseaudio with jack
Patrick Shirkey: Hi, For those of you who are not subscribed to LAU, yesterday I had time to run a test to see how easy and stable it was to run pulseaudio with jack on Fedora 11. I had a few problems at first but after upgrading to pulseaudio-0.9.16 (latest dev version) I was able to successfully connect Pulseaudio to Jack and play tracks with Totem. It was still a little unstable as I was able to bring pulse down a few times while using the gnome-volume-control applet. However jack was not affected by pulse dying. I did this on a standard Fedora kernel with a 2 core intel and 4 GB RAM. My system load without any audio playing it was around 10%. While playing a track with Totem through PA into Jack was around 20%. This could be due to the visuals that were running at the same time. I was able to listen to a complete 30 minute dj mix without any dropouts while still using my system as usual. I am going to run a full day test of audio playback today. Which kernel are you running, and are you using a 32 or 64 bit distribution? I'm using the 32 bit distribution of fedora 11 with the latest fedora PAE kernel. The cpu is a 4 core intel i7, 6 GB ram. I haven't had any problems at all with pulseaudio/jack (only using the packages provided by fedora), and I'm a bit surprised about your post. But I haven't tried totem, I'll do when I get home. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Thu, Aug 6, 2009 at 6:30 PM, Ralf Mardorfralf.mard...@alice-dsl.net wrote: Chris Cannam wrote: On Thu, Aug 6, 2009 at 7:46 PM, Raymond Martinlase...@gmail.com wrote: What possible counter-argument can there be left? http://lwn.net/Articles/61292/ (same guy you just cited, explaining why you're wrong) Chris The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 06:51:08 Paul Davis wrote: On Thu, Aug 6, 2009 at 6:30 PM, Ralf Mardorfralf.mard...@alice-dsl.net wrote: Chris Cannam wrote: On Thu, Aug 6, 2009 at 7:46 PM, Raymond Martinlase...@gmail.com wrote: What possible counter-argument can there be left? http://lwn.net/Articles/61292/ (same guy you just cited, explaining why you're wrong) Chris The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. That's nice, but I would like for someone to show me how this pertains to the current line of discussion. The fact is that code does become GPL once you mix it with other GPL code. Whether you choose to break the promise you are making when you distribute it is another thing. That promise is something that is made with the license automatically whenever the application is distributed, just one thing a license can do that a contract would need a bilateral agreement for. Perhaps you should read that paragraph again in the context of how this whole discussion came about. Known free software, with a history of being free, distributed under the GPL with the source code in the past, was not being distributed with the source code at a point by the very same people. So where would the altered terms be if the binary was decompiled and source distributed for the application under consideration? The terms would be the same as they were in the past. Thus, there is nothing stopping the distribution of the code regardless of how it is obtained in this one particular case. It can be forced open in this case because it would result in code that was intended to be under the GPL in the first place, not some other license. There is a whole trail of evidence that can easily show it was and is GPL. The code could hardly be considered proprietary. An extensive look at license vs. contract for the GPL is found in Enforcing the GPL - http://www.sapnakumar.org/EnfGPL.pdf Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Fri, Aug 07, 2009 at 06:51:08AM -0400, Paul Davis wrote: For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. Which makes perfect sense. In a civilised society even a convicted thief retains all the rights to his legally acquired property. If any of it has to be seized, for example to compensate his victims, that action can be taken only by a court. Not by his victims or some self- appointed vigilante. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rui Nuno Capela wrote:
Robin Gareus wrote:
Hi Rui et al,
I just found that recent kernel development (merging IRQ threads into
mainline) breaks the rtirq setup script. Basically rtirq does nothing.
[..]
It looks like a new set of regexps for rtirq is in order ;)
of course. it happens all the time the rt-preempt devs make their way it
happened before it will happen again. world is turning :)
LOL.
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
[..]
Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that
those are a result of a suspend/resume cycle; and I'll check later if
the chrt settings do persist after a suspend/resume.
It looks like the guess was correct. The PIDs change after
suspend/resume and the chrt settings are retained here.
Take your time, and enjoy the holiday.
cheers,
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp8JZwACgkQeVUk8U+VK0JOJgCfQzlByX1wdCIuaOO9QtNc+Zh+
9rUAnjrGfEO3rLDCkLMtcfyEWwGd323l
=KI14
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 08:56:30 Fons Adriaensen wrote: On Fri, Aug 07, 2009 at 06:51:08AM -0400, Paul Davis wrote: For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. Which makes perfect sense. In a civilised society even a convicted thief retains all the rights to his legally acquired property. If any of it has to be seized, for example to compensate his victims, that action can be taken only by a court. Not by his victims or some self- appointed vigilante. Wow, do you live in some sort of utopia? Law enforcement in numbers of countries routinely seize peoples property when they are involved in or allegedly involved in crimes when there are no real victims involved. People's cars and other belonging are routinely seized at border crossings if someone is attempting to enter a country illegally. They never get their things back. No courts involved. So much for legal property rights. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Raymond Martin wrote: That's nice, but I would like for someone to show me how this pertains to the current line of discussion. The fact is that code does become GPL once you mix it with other GPL code. Hi Raymond :) I searched the web and discussed this also off-list. Today in the early morning I sent this to Paul: [snip] There's another sentence, with an interesting issue in Germany. It can become impossible to claim one's due, e.g. it's forbidden to decompile software that's not GPL'd but be suspected to use GPL'd code. The one who file a claim against the company that was violating the GPL allegedly didn't decompile the software, but watched the booting. If he would have decompiled the software, the court were not allowed to pronounce the sentence against the company that violated the GPL. [snip] Oops, after sending something on broken English I can see mistakes I made, but I won't correct them, but I'll add that this was at Oktober/04/2006, http://de.wikipedia.org/wiki/GNU_General_Public_License). There's no file reference of the court, but for another example there is a file reference, I don't guess this German Wiki is publishing a fake, even if I didn't verify it extensive enough. There are a lot of links on English saying the same. If you violate the GPL, you're still the copyright holder of your own code and it's not allowed to decompile it by others and it won't become GPL'd automatically, in addition in Germany you are even not allowed to decompile code in order to prove that there was GPL'd code stolen. You are wrong, or German courts are wrong and lawyers, maybe faked lawyers, are liars. There are a lot of translations of the GPL's legal terminology in the web. I don't think this will be a big conspiracy, so I won't verify all those links. A lot of links to this topic were posted before. Cheers, Ralf Whether you choose to break the promise you are making when you distribute it is another thing. That promise is something that is made with the license automatically whenever the application is distributed, just one thing a license can do that a contract would need a bilateral agreement for. Perhaps you should read that paragraph again in the context of how this whole discussion came about. Known free software, with a history of being free, distributed under the GPL with the source code in the past, was not being distributed with the source code at a point by the very same people. So where would the altered terms be if the binary was decompiled and source distributed for the application under consideration? The terms would be the same as they were in the past. Thus, there is nothing stopping the distribution of the code regardless of how it is obtained in this one particular case. It can be forced open in this case because it would result in code that was intended to be under the GPL in the first place, not some other license. There is a whole trail of evidence that can easily show it was and is GPL. The code could hardly be considered proprietary. An extensive look at license vs. contract for the GPL is found in Enforcing the GPL - http://www.sapnakumar.org/EnfGPL.pdf Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GPL Violation Alert! - Sorry if this is a duplicate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 04, 2009 at 03:45:13PM +0100, Dr Nicholas J Bailey wrote: On Tuesday 04 Aug 2009 09:10:21 Fons Adriaensen wrote: On Tue, Aug 04, 2009 at 08:33:22AM +0100, Nick Bailey wrote: Well, calling it your own is out of order, but as long as they release their source code as required by the GPL, then selling it is a Good Thing (TM). I hope the LADs agree with me. I would certainly be delighted if my GPL'd stuff (which isn't directly related to LAD) got sold. It would mean more GPL'd applications. Two question arise: - Is a program that loads LADSPA plugins (at run time) a 'derived work' ? Note that anyone can create a 'clean' version of ladpsa.h, as some people did with the VST headers. My understanding is Yes. If it's linked, it's GPL'd. You can run a separate process and communicate through sockets etc, that'd be separate. But AFAIK, same memory space = derived work. i guess your understanding is correct. in a past thread (feb. 2004) on the piksel list regarding licensing of video plugins, i've asked the FSF regarding this issue and got this reply: Legally speaking, there's never been a case which discussed this. FSF believes that dlopen operates the same way as compile-time linking. Dave Turner GPL Compliance Engineer ciao - -- jaromil, dyne.org developer, http://jaromil.dyne.org GPG: 779F E8B5 47C7 3A89 4112 64D0 7B64 3184 B534 0B5E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp8K/wACgkQe2QxhLU0C152dACgpcieOzJcSM79DKwZ4jDamK28 sQ0An14n5WVLQ1fthbvaaGeq3DUIVdr8 =Xdi6 -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
Robin Gareus wrote:
Rui Nuno Capela wrote:
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
which is the exact and old behavior of rtirq for kernel-rt 2.6.31-rt.
this time however it looks that you can actually improve things when
several device drivers are hanging on a irq line. that is, one can tune
up the one and only the one actually intended (eg. snd = irq/17-HDA
Inte and nothing else)
not just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...
[..]
Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that
those are a result of a suspend/resume cycle; and I'll check later if
the chrt settings do persist after a suspend/resume.
It looks like the guess was correct. The PIDs change after
suspend/resume and the chrt settings are retained here.
Take your time, and enjoy the holiday.
sure, tks
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On 7 Aug 2009, at 12:55, Raymond Martin wrote: On Friday 07 August 2009 06:51:08 Paul Davis wrote: On Thu, Aug 6, 2009 at 6:30 PM, Ralf Mardorfralf.mard...@alice-dsl.net wrote: Chris Cannam wrote: On Thu, Aug 6, 2009 at 7:46 PM, Raymond Martinlase...@gmail.com wrote: What possible counter-argument can there be left? http://lwn.net/Articles/61292/ (same guy you just cited, explaining why you're wrong) Chris The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. [...] Perhaps you should read that paragraph again in the context of how this whole discussion came about. Known free software, with a history of being free, distributed under the GPL with the source code in the past, was not being distributed with the source code at a point by the very same people. So where would the altered terms be if the binary was decompiled and source distributed for the application under consideration? This whole strand of the discussion came about because you had threatened to release a decompilation of Bob's ***MODIFIED*** preview release and I said: Until and unless you have Bob's preview source files with GPL headers all present and correct, you don't have a license for the mods in that code. I wrote that sentence quite carefully but here it is again with some emphasis on the pertinent words: Until and unless you have Bob's ***PREVIEW*** source files with GPL headers all present and correct, you don't have a license for ***THE MODS*** in that code. [...] An extensive look at license vs. contract for the GPL is found in Enforcing the GPL - http://www.sapnakumar.org/EnfGPL.pdf Yes. The Moglen quote we're now discussing appears on page 15. (And yes that document discusses the possibility that one day someone might persuade a court that the GPL is actually a contract, but walk before you try to run eh?) ~ Simon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
Rui Nuno Capela wrote:
Robin Gareus wrote:
Rui Nuno Capela wrote:
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
which is the exact and old behavior of rtirq for kernel-rt 2.6.31-rt.
this time however it looks that you can actually improve things when
several device drivers are hanging on a irq line. that is, one can tune
up the one and only the one actually intended (eg. snd = irq/17-HDA
Inte and nothing else)
not just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...
not so deeper, more than a simple regex fix but some bash trickery now
added: please, try the attached patch (rtirq-20090807-1.diff) and tell ;)
cheers
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
--- rtirq-20090626/rtirq.sh 2009-06-25 23:52:29.0 +0100
+++ rtirq-20090807/rtirq.sh 2009-08-07 14:48:48.0 +0100
@@ -117,7 +117,7 @@ function rtirq_exec_num ()
# And now do the proper threading prioritization...
if [ -z `echo ${RTIRQ_TRAIL} | grep :${IRQ}:` ]
then
- PIDS=`ps -eo pid,comm | egrep IRQ.${IRQ}\$ | awk '{print $1}'`
+ PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq/${IRQ}-${NAME2:0:8})\$ | awk '{print $1}'`
for PID in ${PIDS}
do
PREPEND=Setting IRQ priorities: ${ACTION} [${NAME2}] irq=${IRQ} pid=${PID}
@@ -224,10 +224,11 @@ function rtirq_exec ()
case ${NAME} in
snd)
PRI1=${PRI0}
- IRQS=`grep irq /proc/asound/cards | tac | sed 's/.* irq \(.*\)/\1/'`
- for IRQ in ${IRQS}
+ grep irq /proc/asound/cards | tac | \
+ sed 's/\(.*\) at .* irq \(.*\)/\2 \1/' | \
+ while read IRQ NAME2
do
-rtirq_exec_num ${ACTION} ${NAME} ${NAME} ${PRI1} ${IRQ}
+rtirq_exec_num ${ACTION} ${NAME} ${NAME2} ${PRI1} ${IRQ}
PRI1=$((${PRI1} - 1))
done
;;
@@ -238,7 +239,7 @@ function rtirq_exec ()
;;
*)
rtirq_exec_name ${ACTION} ${NAME} ${NAME} ${PRI0}
- ;;
+ ;;
esac
[ ${PRI0} -gt ${DECR} ] PRI0=$((${PRI0} - ${DECR}))
done
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Fri, Aug 07, 2009 at 09:14:23AM -0400, Raymond Martin wrote: On Friday 07 August 2009 08:56:30 Fons Adriaensen wrote: Which makes perfect sense. In a civilised society even a convicted thief retains all the rights to his legally acquired property. If any of it has to be seized, for example to compensate his victims, that action can be taken only by a court. Not by his victims or some self- appointed vigilante. Wow, do you live in some sort of utopia? Law enforcement in numbers of countries routinely seize peoples property when they are involved in or allegedly involved in crimes when there are no real victims involved. People's cars and other belonging are routinely seized at border crossings if someone is attempting to enter a country illegally. They never get their things back. No courts involved. So much for legal property rights. The cases you mention such as border crossings are all related to security and not to civil justice. There are other special cases, if you drive drunk and kill someone the car you used will be seized as well, even if it's not your property. But even this requires a court order, which can be retroactive. Regardless of all this: a private person or group can't ever do this. Only law enforcement or the justice system can, and in the case of the first it is temporary (for securtiy or investigation), and if not it needs confirmation by a court. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Fons Adriaensen wrote: On Fri, Aug 07, 2009 at 09:14:23AM -0400, Raymond Martin wrote: On Friday 07 August 2009 08:56:30 Fons Adriaensen wrote: Which makes perfect sense. In a civilised society even a convicted thief retains all the rights to his legally acquired property. If any of it has to be seized, for example to compensate his victims, that action can be taken only by a court. Not by his victims or some self- appointed vigilante. Wow, do you live in some sort of utopia? Law enforcement in numbers of countries routinely seize peoples property when they are involved in or allegedly involved in crimes when there are no real victims involved. People's cars and other belonging are routinely seized at border crossings if someone is attempting to enter a country illegally. They never get their things back. No courts involved. So much for legal property rights. The cases you mention such as border crossings are all related to security and not to civil justice. There are other special cases, if you drive drunk and kill someone the car you used will be seized as well, even if it's not your property. But even this requires a court order, which can be retroactive. Regardless of all this: a private person or group can't ever do this. Only law enforcement or the justice system can, and in the case of the first it is temporary (for securtiy or investigation), and if not it needs confirmation by a court. Ciao, IANAL, you might be right with he words of the GPL Raymond, e.g. in Germany the courts needed to interpret the GPL to fit it to the German law, they were willing it to do and they did. The GPL is capable in Germany, but not word by word. The western civilization's courts say that you are wrong, he GPL might say that you are right. Outlaws, so called terrorists in history often were right, but wrong by the law, but I guess that the western civilisation's courts are more on the side of FLOSS than on the proprietary side today. When someone came and argued that gratis software under the GPL is a forbidden price-fixing-agreement, forbidden monopoly and what ever they tried to blame FLOSS, the courts always were on the side of FLOSS. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 10:07:31 Fons Adriaensen wrote: On Fri, Aug 07, 2009 at 09:14:23AM -0400, Raymond Martin wrote: On Friday 07 August 2009 08:56:30 Fons Adriaensen wrote: Which makes perfect sense. In a civilised society even a convicted thief retains all the rights to his legally acquired property. If any of it has to be seized, for example to compensate his victims, that action can be taken only by a court. Not by his victims or some self- appointed vigilante. Wow, do you live in some sort of utopia? Law enforcement in numbers of countries routinely seize peoples property when they are involved in or allegedly involved in crimes when there are no real victims involved. People's cars and other belonging are routinely seized at border crossings if someone is attempting to enter a country illegally. They never get their things back. No courts involved. So much for legal property rights. The cases you mention such as border crossings are all related to security and not to civil justice. Splitting hairs. The fact that it is security and not justice makes these cases even more extreme in their betrayal of justice. There are cases in the US, for instance, where people growing marijuana for their medical conditions have had their homes seized and never returned. No justice there. That's real police stuff. Regardless of all this: a private person or group can't ever do this. Only law enforcement or the justice system can, and in the case of the first it is temporary (for securtiy or investigation), and if not it needs confirmation by a court. Not so. In most cases of seizure at borders (e.g., US/Canada, US/Mexico) the property is never returned, ever. The people who loose their property never get a day in court, ever. Look it up, it is a fact. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rui Nuno Capela wrote:
Rui Nuno Capela wrote:
Robin Gareus wrote:
Rui Nuno Capela wrote:
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
which is the exact and old behavior of rtirq for kernel-rt 2.6.31-rt.
this time however it looks that you can actually improve things when
several device drivers are hanging on a irq line. that is, one can tune
up the one and only the one actually intended (eg. snd = irq/17-HDA
Inte and nothing else)
not just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...
not so deeper, more than a simple regex fix but some bash trickery now
added: please, try the attached patch (rtirq-20090807-1.diff) and tell ;)
Almost - it fails because HDA Inte has a space in it. So
${NAME2} is only HDA instead of HDA Intel.
I've added quotation marks around ${NAME2} to the rtirq_exec_num and
rtirq_exec_name function calls (line 167 and line 231) and then it works.
However, there's still an issue with RTIRQ_TRAIL. If one wants to raise
two drivers on the same IRQ line. For example
HDA Intel and ohci1394 but not uhci_hcd:usb3 (all on IRQ 17 here)
rtirq will only do the first device and skip the remaining.
Thanks for your help, it must be fun to code on the beach ;)
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp8PMgACgkQeVUk8U+VK0JZLQCglDnGMW+a08JISJQ2h3cGWd+O
KtMAoK/0bjsKxCI+S0OqHvqHU73YkznN
=/rpF
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
There are cases in the US, for instance, where people growing marijuana for their medical conditions have had their homes seized and never returned. No justice there. That's real police stuff. Sometimes western civilization behaves like the Third Reich did, but for FLOSS I never read or heard about such iniquities. The GPL is accepted and in addition the copyright of a thief also is accepted. We can have another attitude because of this, but the law says that a rip-off GPL'd code won't result in confiscation of the thief's copyright. Any dispute only can be about ethics, but not about the law. By ethics you might or might not be right, but by law you're wrong. I guess the sense of this discussion is to know about the law. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 09:51:05 you wrote: On 7 Aug 2009, at 12:55, Raymond Martin wrote: On Friday 07 August 2009 06:51:08 Paul Davis wrote: On Thu, Aug 6, 2009 at 6:30 PM, Ralf Mardorfralf.mard...@alice-dsl.net For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. [...] Perhaps you should read that paragraph again in the context of how this whole discussion came about. Known free software, with a history of being free, distributed under the GPL with the source code in the past, was not being distributed with the source code at a point by the very same people. So where would the altered terms be if the binary was decompiled and source distributed for the application under consideration? This whole strand of the discussion came about because you had threatened to release a decompilation of Bob's ***MODIFIED*** preview release and I said: Which was so obviously GPL to begin with. And was obviously intended to be completely under the GPL in any release. Until and unless you have Bob's preview source files with GPL headers all present and correct, you don't have a license for the mods in that code. Previous actions on his part show it was GPL already. I wrote that sentence quite carefully but here it is again with some emphasis on the pertinent words: Until and unless you have Bob's ***PREVIEW*** source files with GPL headers all present and correct, you don't have a license for ***THE MODS*** in that code. You would be very hard pressed to prove in a court that the code wasn't intended to be under GPL in the first place. This is a very important point you are jumping over. There was a definite intention for ALL the code to be GPL, not just the old portion that was already out. There was NO intention for the MODS to be proprietary. There is a trail of public evidence of this. So this idea that you cannot decompile something INTENDED to be GPL in the first place is moot. In law it is called circumstances. They must be considered. Eben Moglen, attorney for the FSF says: But most proprietary software companies want more power than copyright alone gives them. These companies say their software is ``licensed'' to consumers, but the license contains obligations that copyright law knows nothing about. Software you're not allowed to understand, for example, often requires you to agree not to decompile it. Copyright law doesn't prohibit decompilation, the prohibition is just a contract term you agree to as a condition of getting the software when you buy the product under shrink wrap in a store, or accept a ``clickwrap license'' on line. Copyright is just leverage for taking even more away from users. Indicates right there that there is nothing prohibiting decompilation, unless you agree in a contract not to do it. GPL is a license and there is no agreement to not decompile GPL programs because there is no contractual agreement not to do so. Thus, in the present case, decompilation does not result in any violation at all. All the code was and is GPL, decompiling a fully GPL program cannot result in any wrongdoing. Distributing it neither. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] linux audio standards base?
I'm not a developer, just interested in Linux audio development because I use Linux audio software almost daily, and as such I've been lurking on this list for awhile. So this is just a practical suggestion / brainstorming idea, not meant to incur flames (I wish I could heat my studio by the flames this list generates). One complaint I've seen raised a number of times is that in the world of Linux, especially the audio realm, there are too many choices and not enough decisions made. In the wider scope, The Linux Foundation is trying to address this by maintaining a standards base to help promote open standards across mainstream distros... So here's the idea: why not make one of the responsibilities of the Linux Audio Consortium be establishing and maintaining a standards base? As far as I can tell from http://linuxaudio.org/about , it's not currently one of the Consortium's roles. I.e., there could be a formal document that says in a nutshell, If you want your Linux audio application to integrate seamlessly on most audio-centric distros, here's what it should support. And, if you want your pro-audio-centric distro to be seamlessly compatible with all these great apps, here's what it should include and how it should work. Of course it would be a voluntary standards base, and every developer / distro team can still do whatever they like, so that innovation can continue... but as protocols/interfaces/frameworks/whatever are developed and show their merit, they can be included in the standards base, and old/deprecated/redundant things removed, so that people aren't wasting their time supporting old code. So to sum it up, *someone* needs to make some tough decisions, or Linux audio will continue to stagnate... why not the Consortium? It's the only real Linux audio authority or central point of contact that I know of. I'm sure there are many reasons this is a silly idea -- lack of time, disagreements on what should be standardized, etc. -- but as I said it's just an idea. I'd love some constructive criticism, even if it just leads to a completely different idea getting implemented. By the way, I apologize that this is basically just another here's my idea about what everyone else should do kind of e-mails. I could maintain a website and/or provide free hosting for the standards document(s), if need be. -Sean Corbett blacktownsound.com (- pardon the shameless spam) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Raymond Martin wrote: On Friday 07 August 2009 09:51:05 you wrote: On 7 Aug 2009, at 12:55, Raymond Martin wrote: On Friday 07 August 2009 06:51:08 Paul Davis wrote: On Thu, Aug 6, 2009 at 6:30 PM, Ralf Mardorfralf.mard...@alice-dsl.net For emphasis, I just want to paste that sentence (and the following one) again for Raymond, with attribution: Eben Moglen, attorney for the FSF: The claim that a GPL violation could lead to the forcing open of proprietary code that has wrongfully included GPL'd components is simply wrong. There is no provision in the Copyright Act to require distribution of infringing work on altered terms. [...] Perhaps you should read that paragraph again in the context of how this whole discussion came about. Known free software, with a history of being free, distributed under the GPL with the source code in the past, was not being distributed with the source code at a point by the very same people. So where would the altered terms be if the binary was decompiled and source distributed for the application under consideration? This whole strand of the discussion came about because you had threatened to release a decompilation of Bob's ***MODIFIED*** preview release and I said: Which was so obviously GPL to begin with. And was obviously intended to be completely under the GPL in any release. That's true, Bob always said he only had no time to open the source, because of his journeys, but as far as I remember he accepted the GPL ... a funny situation :D. So Raymond was allowed to decompile the software. Anyway, this didn't change the fact about the law we were discussing ;). Until and unless you have Bob's preview source files with GPL headers all present and correct, you don't have a license for the mods in that code. Previous actions on his part show it was GPL already. I wrote that sentence quite carefully but here it is again with some emphasis on the pertinent words: Until and unless you have Bob's ***PREVIEW*** source files with GPL headers all present and correct, you don't have a license for ***THE MODS*** in that code. You would be very hard pressed to prove in a court that the code wasn't intended to be under GPL in the first place. This is a very important point you are jumping over. There was a definite intention for ALL the code to be GPL, not just the old portion that was already out. There was NO intention for the MODS to be proprietary. There is a trail of public evidence of this. So this idea that you cannot decompile something INTENDED to be GPL in the first place is moot. In law it is called circumstances. They must be considered. Eben Moglen, attorney for the FSF says: But most proprietary software companies want more power than copyright alone gives them. These companies say their software is ``licensed'' to consumers, but the license contains obligations that copyright law knows nothing about. Software you're not allowed to understand, for example, often requires you to agree not to decompile it. Copyright law doesn't prohibit decompilation, the prohibition is just a contract term you agree to as a condition of getting the software when you buy the product under shrink wrap in a store, or accept a ``clickwrap license'' on line. Copyright is just leverage for taking even more away from users. Indicates right there that there is nothing prohibiting decompilation, unless you agree in a contract not to do it. GPL is a license and there is no agreement to not decompile GPL programs because there is no contractual agreement not to do so. Thus, in the present case, decompilation does not result in any violation at all. All the code was and is GPL, decompiling a fully GPL program cannot result in any wrongdoing. Distributing it neither. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg Gromit bit me says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] how i think the gpl works under german jurisdiction
On Friday 07 August 2009, Jens M Andreasen wrote: On Fri, 2009-08-07 at 00:44 +0200, Jörn Nettingsmeier wrote: at the risk of starting another zillion-mail thread, Pamela Jones wrote that You won't get shot at dawn for not understanding the GPL .. This needs fixing!!! So you are in favor of that? Humm, it does have a certain attraction. :) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. https://www.nrahq.org/nrabonus/accept-membership.asp Never underestimate the power of human stupidity. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
On Fri, 2009-08-07 at 11:02 +0200, Kjetil S. Matheussen wrote: Well, in my opinion, everything really is fantastic right now. [...] A person coming directly from win/mac probably wouldn't have succeeded though, since jack needed to be configured and I had to manually install the pulseaudio jack sink, edit various files in /etc/, plus perhaps doing other stuff I don't remember anymore. Mmhmm... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Fri, Aug 07, 2009 at 10:39:44AM -0400, Raymond Martin wrote: Regardless of all this: a private person or group can't ever do this. Only law enforcement or the justice system can, and in the case of the first it is temporary (for securtiy or investigation), and if not it needs confirmation by a court. Not so. In most cases of seizure at borders (e.g., US/Canada, US/Mexico) the property is never returned, ever. The people who loose their property never get a day in court, ever. Look it up, it is a fact. You are completely missing the point, which is: *You*, as a private person, can not seize anything, ever. And if you think it's immoral for the law to do it, then it is even more so if someone takes the law into his own hands and appoints himself to be cop, judge and executioner. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
Robin Gareus wrote:
Rui Nuno Capela wrote:
Rui Nuno Capela wrote:
Robin Gareus wrote:
Rui Nuno Capela wrote:
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
which is the exact and old behavior of rtirq for kernel-rt 2.6.31-rt.
this time however it looks that you can actually improve things when
several device drivers are hanging on a irq line. that is, one can tune
up the one and only the one actually intended (eg. snd = irq/17-HDA
Inte and nothing else)
not just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...
not so deeper, more than a simple regex fix but some bash trickery now
added: please, try the attached patch (rtirq-20090807-1.diff) and tell ;)
Almost - it fails because HDA Inte has a space in it. So
${NAME2} is only HDA instead of HDA Intel.
I've added quotation marks around ${NAME2} to the rtirq_exec_num and
rtirq_exec_name function calls (line 167 and line 231) and then it works.
However, there's still an issue with RTIRQ_TRAIL. If one wants to raise
two drivers on the same IRQ line. For example
HDA Intel and ohci1394 but not uhci_hcd:usb3 (all on IRQ 17 here)
rtirq will only do the first device and skip the remaining.
Thanks for your help, it must be fun to code on the beach ;)
beach support is fine ;)
here goes another one (rtirq-20090807-2.diff), with your quotation marks
in place and RTIRQ_TRAIL issue probably tamed ... please try as i don't
have the right kernel to make proper testing.
byee--off to snorkeling now 8)
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
--- rtirq-20090626/rtirq.sh 2009-06-25 23:52:29.0 +0100
+++ rtirq-20090807/rtirq.sh 2009-08-07 17:42:51.0 +0100
@@ -116,8 +116,16 @@ function rtirq_exec_num ()
fi
# And now do the proper threading prioritization...
if [ -z `echo ${RTIRQ_TRAIL} | grep :${IRQ}:` ]
- then
- PIDS=`ps -eo pid,comm | egrep IRQ.${IRQ}\$ | awk '{print $1}'`
+ then
+ # Special for kernel-rt = 2.6.31, where one can
+ # prioritize shared IRQs by device driver (NAME2)...
+ PIDS=`ps -eo pid,comm | egrep irq/${IRQ}-${NAME2:0:8}\$ | awk '{print $1}'`
+ if [ -z ${PIDS} ]
+ then
+ # Backward compability for older kernel-rt 2.6.31...
+ PIDS=`ps -eo pid,comm | egrep IRQ.${IRQ}\$ | awk '{print $1}'`
+ RTIRQ_TRAIL=:${IRQ}${RTIRQ_TRAIL}
+ fi
for PID in ${PIDS}
do
PREPEND=Setting IRQ priorities: ${ACTION} [${NAME2}] irq=${IRQ} pid=${PID}
@@ -148,7 +156,6 @@ function rtirq_exec_num ()
esac
PRI2=$((${PRI2} - 1))
done
- RTIRQ_TRAIL=:${IRQ}${RTIRQ_TRAIL}
fi
}
@@ -164,7 +171,7 @@ function rtirq_exec_name ()
IRQS=`grep ${NAME2} /proc/interrupts | awk -F: '{print $1}'`
for IRQ in ${IRQS}
do
- rtirq_exec_num ${ACTION} ${NAME1} ${NAME2} ${PRI1} ${IRQ}
+ rtirq_exec_num ${ACTION} ${NAME1} ${NAME2} ${PRI1} ${IRQ}
PRI1=$((${PRI1} - 1))
done
}
@@ -224,21 +231,22 @@ function rtirq_exec ()
case ${NAME} in
snd)
PRI1=${PRI0}
- IRQS=`grep irq /proc/asound/cards | tac | sed 's/.* irq \(.*\)/\1/'`
- for IRQ in ${IRQS}
+ grep irq /proc/asound/cards | tac | \
+ sed 's/\(.*\) at .* irq \(.*\)/\2 \1/' | \
+ while read IRQ NAME2
do
-rtirq_exec_num ${ACTION} ${NAME} ${NAME} ${PRI1} ${IRQ}
+rtirq_exec_num ${ACTION} ${NAME} ${NAME2} ${PRI1} ${IRQ}
PRI1=$((${PRI1} - 1))
done
;;
usb)
- rtirq_exec_name ${ACTION} ${NAME} ohci_hcd ${PRI0}
- rtirq_exec_name ${ACTION} ${NAME} uhci_hcd ${PRI0}
- rtirq_exec_name ${ACTION} ${NAME} ehci_hcd ${PRI0}
+ rtirq_exec_name ${ACTION} ${NAME} ohci_hcd ${PRI0}
+ rtirq_exec_name ${ACTION} ${NAME} uhci_hcd ${PRI0}
+ rtirq_exec_name
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 12:40:44 Fons Adriaensen wrote: On Fri, Aug 07, 2009 at 10:39:44AM -0400, Raymond Martin wrote: Regardless of all this: a private person or group can't ever do this. Only law enforcement or the justice system can, and in the case of the first it is temporary (for securtiy or investigation), and if not it needs confirmation by a court. Not so. In most cases of seizure at borders (e.g., US/Canada, US/Mexico) the property is never returned, ever. The people who loose their property never get a day in court, ever. Look it up, it is a fact. You are completely missing the point, which is: *You*, as a private person, can not seize anything, ever. And if you think it's immoral for the law to do it, then it is even more so if someone takes the law into his own hands and appoints himself to be cop, judge and executioner. Show me where I have done something wrong. I am not seizing anything by taking what is freely given. Make sense. I showed in another post that there is nothing wrong with decompilation under GPL. If there is nothing wrong with decompilation and the code is 100% GPL then there would be nothing wrong with distribution either. That's not taking the law into your own hands, that exercising your rights. And by the way, it is not more immoral for a single person to take the law into there own hands than a government power. That is just ridiculous. Governments are immensely more evil when they wield tyranny over countless lives than what a single person could ever do. Do the math. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
2009/8/6 Grammostola Rosea rosea.grammost...@gmail.com: I don't know if I can really recommend Linux for pro audio to normal human beings... at least I should say, you need a lot of time, not easy give up on things and a lot of patience... How much do normal human beings need pro audio production tools? -Chuckk -- http://www.badmuthahubbard.com -- http://www.badmuthahubbard.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
Just two observations, only generally related: If you have an OSX system without the installation discs, and you want to install a free C/C++ compiler, the *only* way I have found is with a download of several hundred MB from the official OSX website with *lots* of extra stuff, examples, docs, developer's tools, for many different languages. Surely won't matter for the majority of people who would even consider Mac, but *why*? Why on earth would anyone make that decision?? Especially considering that it's actually GPL software created by someone else! On whether Windows or Mac is more important in pro audio, I haven't gotten so close to the professional audio world, but I went to a pretty modern university, University of the Arts in Philadelphia, and right as I was graduating they announced the decision to require ALL students to purchase MacBooks with their own money. Not just music students, but theater, dance, sculpture, etc., everyone! I don't know if such a decision reflects a wide market trend in the art world (in my mind that's impossible, the trend is towards Linux), but it indicates some kind of power over Windows. -Chuckk On Wed, Aug 5, 2009 at 11:41 AM, Frank Barknechtf...@footils.org wrote: Hallo, here's an excellent read about Kim Casone (of .microsound and this list, too) switching from Mac to Linux: http://createdigitalmusic.com/2009/08/04/linux-music-workflow-switching-from-mac-os-x-to-ubuntu-with-kim-cascone/ (URL in one line) Great work, Kim! Ciao -- Frank ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- http://www.badmuthahubbard.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] rtirq script is broken with 2.6.31
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rui Nuno Capela wrote:
Robin Gareus wrote:
Rui Nuno Capela wrote:
Rui Nuno Capela wrote:
Robin Gareus wrote:
Rui Nuno Capela wrote:
this issue on 2.6.31-rt has been already reported privately and i'll get
to it as soon i get back home from vacation. meanwhile, it really looks
like a regex trickery is all that's needed,
I'm not so sure, Since 2.6.31 it is also possible to raise the priority
not by IRQ number but by /device-driver/.
ie:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
9092 FF 89 - 129 0.4 S irq/17-HDA Inte
1447 FF 50 - 90 0.1 S irq/17-uhci_hcd
9093 FF 50 - 90 0.0 S irq/17-ohci1394
..but of course that's also just regexp trickery ;)
Note that the kernel limits the IRQ process name to 15 chars.
HDA Inte won't read HDA Intel even when using `ps -w..`
But '/proc/interrupts' says:
17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
ohci1394
keeping in mind that
backward compability with pre-2.6.31-rt kernels is in order (eg. i do
still run on 2.56.29.5-rt22 for which the current rtirq script is
perfect, of course)
as a quick suggestion, try this for instance (re. line 120):
PIDS=`ps -eo pid,comm | egrep (IRQ.${IRQ}|irq\/${IRQ}\-.+)\$ | awk
'{print $1}'`
That works, but raises all devices on a given IRQ-line and results in:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
1447 FF 88 - 128 0.1 S irq/17-uhci_hcd
9092 FF 87 - 127 0.4 S irq/17-HDA Inte
9093 FF 86 - 126 0.0 S irq/17-ohci1394
which is the exact and old behavior of rtirq for kernel-rt 2.6.31-rt.
this time however it looks that you can actually improve things when
several device drivers are hanging on a irq line. that is, one can tune
up the one and only the one actually intended (eg. snd = irq/17-HDA
Inte and nothing else)
not just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...
not so deeper, more than a simple regex fix but some bash trickery now
added: please, try the attached patch (rtirq-20090807-1.diff) and tell ;)
Almost - it fails because HDA Inte has a space in it. So
${NAME2} is only HDA instead of HDA Intel.
I've added quotation marks around ${NAME2} to the rtirq_exec_num and
rtirq_exec_name function calls (line 167 and line 231) and then it works.
However, there's still an issue with RTIRQ_TRAIL. If one wants to raise
two drivers on the same IRQ line. For example
HDA Intel and ohci1394 but not uhci_hcd:usb3 (all on IRQ 17 here)
rtirq will only do the first device and skip the remaining.
Thanks for your help, it must be fun to code on the beach ;)
beach support is fine ;)
here goes another one (rtirq-20090807-2.diff), with your quotation marks
in place and RTIRQ_TRAIL issue probably tamed ... please try as i don't
have the right kernel to make proper testing.
Yes, you tamed it. This one is a winner!
One last thing: For `rtirq status`
please add 'irq\/' to the regexp list in line 291:
| egrep '(^[[:blank:]]*PID|IRQ|irq\/|softirq)' \
I'm not interested in seeing softirq's there but if you want to include
them for completeness: the pattern is /sirq\-/ for 2.6.29 and 2.6.31.
BTW. the awk script to add extra info from /proc/interrupts to the
output of `ps` for `rtirq status` does nothing on 2.6.31. OTOH it's not
needed there since the process-name includes this information (at least
the first 15chars of it).
For = 2.6.29-rt replace PIC with (PIC|MSI) in the gsub-regexp when
parsing IRQSplit[2]. PCI-MSI-edge is a also a legal value.
And last but not least: Some distros (here: 64studio on a netbook)
install mawk instead of gawk. mawk-1.3.3 does not seem to support the
POSIX regexp pattern /[:blank:]/ . I've replaced it with /( |\t)/ and
it works for 2.6.29.1-multimedia with either mawk or gawk.
byee--off to snorkeling now 8)
..and you're probably just having at BBQ close to the beach now.
I'm getting jealous.
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp8eHEACgkQeVUk8U+VK0KwSQCgwVWzj1H6nrqS8SX4Oh6EwdRJ
nMEAoJhPbuLtitZMB8VagegiRTwH6/Lt
=zxQY
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
On Fri, 2009-08-07 at 20:10 +0300, Chuckk Hubbard wrote: How much do normal human beings need pro audio production tools? According to Apple marketing research, about 10% of perfectly normal human beings plays an instrument - mostly either guitar or keyboard - and would also like to use their PC as a home or portable recording studio. This is the story behind why GarageBand is included in their default application suite. You could argue that that application is not pro or something, but it is still the same infrastructure that ticks behind it as it is for other audio applications, which is what is the point in this context. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 13:10:50 Raymond Martin wrote: Show me where I have done something wrong. I am not seizing anything by taking what is freely given. Make sense. I showed in another post that there is nothing wrong with decompilation under GPL I don't see you as having done something wrong in the case you lay out, just maintaining that it is ok to do something similar which people are saying is wrong. That is in a similar case but where there is no intent to make a program GPL but linking that program with GPL code. Saying that that resulting program is automatically under the GPL despite author claims to the contrary and then, by logic, that it is OK to decompile that and put the source up under the GPL. From what I see, if I release a binary and claim it is GPL but fail to release the source, it is OK to decompile that binary and put up the source. Naturally, forking a GPL project is OK. There does seem to be a good amount of dug in in the mix now though. all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Aug 7, 2009, at 2:07 PM, drew Roberts wrote: Naturally, forking a GPL project is OK. Forking a project and calling it something nearly identical (removing a dash) cannot help but generate confusion and is an example of hostile fork. Here are some guidelines for forking, which seem sensible to me: http://jamesdixon.wordpress.com/2009/05/07/forking-protocol-why-when-and-how-to-fork-an-open-source-project/ But none of these was followed in the case in question. Don't bother to reply. I leave this group with a fair amount of bitterness and disappointment in the way one of your members has conducted himself. To those who seemed to understand my position along the way, I thank you for your support. Bob Keller Robert Keller Csilla Walt Foley Professor Computer Science Harvey Mudd College ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Fri, Aug 7, 2009 at 10:31 PM, Robert Kellerkel...@cs.hmc.edu wrote: Don't bother to reply. I leave this group with a fair amount of bitterness and disappointment in the way one of your members has conducted himself. One of our members? Nobody else on this list had ever heard of him either, until this thread blew up. I do take your point, though. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Fri, Aug 07, 2009 at 10:46:42PM +0100, Chris Cannam wrote: On Fri, Aug 7, 2009 at 10:31 PM, Robert Kellerkel...@cs.hmc.edu wrote: Don't bother to reply. I leave this group with a fair amount of bitterness and disappointment in the way one of your members has conducted himself. One of our members? Nobody else on this list had ever heard of him either, until this thread blew up. True. And he's not a developer of anything Linux Audio either. Claims to be a full-time developer of omega-t+, which is another forked project (originally omega-t, computer assisted translation). Bob's project is not Linux Audio either, but at least it's about music and computing which is a related subject, and which fits IMHO better to this list than GPL vigilantes. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
On Friday 07 August 2009 17:31:36 Robert Keller wrote: On Aug 7, 2009, at 2:07 PM, drew Roberts wrote: Naturally, forking a GPL project is OK. Forking a project and calling it something nearly identical (removing a dash) cannot help but generate confusion and is an example of hostile fork. Not at all. There is even evidence in the FSF documentation somewhere exactly about this point and they vehemently disagree with any attitude like that. We all know very well the situation of Emacs, Xemacs, and various other forks. So it is just too bad that he does not understand the benefits to his own project by having similarly named forks, but this is no surprise given his other misunderstandings about the GPL and free software. Here are some guidelines for forking, which seem sensible to me: Some of that is nonsense. Don't bother to reply. I leave this group with a fair amount of bitterness and disappointment in the way one of your members has conducted himself. To those who seemed to understand my position along the way, I thank you for your support. No, he is leaving because he realized that not everyone is going to automatically side with him on these matters. And in case you all do not realize it yet, there is no fork. So all this crap he is blasting out is stupid. There is only an SF project that hosts code for the exact same program, with no real changes to them. This is the typical behavior that I saw in the person, jumping to conclusions without checking the facts. See for yourself. There is a possibility of a fork, but no such thing exists at present. Raymond ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Forgot to send to the list. On Fri, Aug 7, 2009 at 6:10 PM, Thomas Vecchione seabla...@gmail.comwrote: On Fri, Aug 7, 2009 at 5:34 PM, Raymond Martin lase...@gmail.com wrote: Not at all. There is even evidence in the FSF documentation somewhere exactly about this point and they vehemently disagree with any attitude like that. We all know very well the situation of Emacs, Xemacs, and various other forks. The FSF is not the law. I suggest you look up Trademark Law to realize why you are wrong, and why you are subject to a lawsuit for knowingly creating a product that is infringing on an already existing trademark(Regeristered or Unregeristered would make a small, but only small, difference in this case), and can easily be confused as such. In fact the case against forcing you to change it is rather strong because not only is your product nearly identical in name, it is nearly identical in function and can be easily confused with the original. Standard disclaimer of I am not a lawyer of course applies. Seablade ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
On Fri, Aug 7, 2009 at 11:24 PM, Jens M Andreasenjens.andrea...@comhem.se wrote: On Fri, 2009-08-07 at 20:10 +0300, Chuckk Hubbard wrote: How much do normal human beings need pro audio production tools? According to Apple marketing research, about 10% of perfectly normal human beings plays an instrument - mostly either guitar or keyboard - and would also like to use their PC as a home or portable recording studio. This is the story behind why GarageBand is included in their default application suite. You could argue that that application is not pro or something, but it is still the same infrastructure that ticks behind it as it is for other audio applications, which is what is the point in this context. I guess my thought was that people who want to use audio professionally are less likely to make decisions based on what requires the least effort, which seems to be the main bragging point for OSX as well as the main complaint about Linux. -Chuckk -- http://www.badmuthahubbard.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Thomas Vecchione wrote: Forgot to send to the list. On Fri, Aug 7, 2009 at 6:10 PM, Thomas Vecchione seabla...@gmail.com mailto:seabla...@gmail.com wrote: On Fri, Aug 7, 2009 at 5:34 PM, Raymond Martin lase...@gmail.com mailto:lase...@gmail.com wrote: Not at all. There is even evidence in the FSF documentation somewhere exactly about this point and they vehemently disagree with any attitude like that. We all know very well the situation of Emacs, Xemacs, and various other forks. The FSF is not the law. I suggest you look up Trademark Law to realize why you are wrong, and why you are subject to a lawsuit for knowingly creating a product that is infringing on an already existing trademark(Regeristered or Unregeristered would make a small, but only small, difference in this case), and can easily be confused as such. In fact the case against forcing you to change it is rather strong because not only is your product nearly identical in name, it is nearly identical in function and can be easily confused with the original. Standard disclaimer of I am not a lawyer of course applies. Seablade I'm not interested to take sides, I only want to learn about the GPL. Assumed that Miss B. forks a GPL'd project, as far as I understand the GPL, Miss R. is allowed to fork a project with a similar name, similar function, based on the open source code of Miss B. and if Miss B. had no time to open the source code, because she was in the manicure salon, but Miss B. accepted the GPL, e.g. a mailing list for manicure software can witness this, than Miss R. is allowed to decompile the software of Miss B.. Am I wrong? If Miss B. would use GPL'd code and won't agree to the GPL, than Miss B. is violating the GPL, but Miss R. isn't allowed to decompile the software of Miss B., because of copyright laws. Am I wrong? But again, Miss B. accepted the GPL, but while the nail polish needs to dry, she wasn't able to distribute the source code, she only had time to distribute the binary. She wrote exactly this to the manicure developers mailing list, that's why Miss R. decided to decompile the code. The situation is a little bit tricky and Miss R. is less liked by the manicure developers list, while Miss B. is liked by the list. And that's why little differences are easily overlooked. Justizia should be blindfolded ;) and even take care of little differences. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Once again forgot to hit Reply-All. On Fri, Aug 7, 2009 at 6:41 PM, Ralf Mardorf ralf.mard...@alice-dsl.netwrote: I'm not interested to take sides, I only want to learn about the GPL. Assumed that Miss B. forks a GPL'd project, as far as I understand the GPL, Miss R. is allowed to fork a project with a similar name, similar function, based on the open source code of Miss B. and if Miss B. had no time to open the source code, because she was in the manicure salon, but Miss B. accepted the GPL, e.g. a mailing list for manicure software can witness this, than Miss R. is allowed to decompile the software of Miss B.. Am I wrong? You are confusing Copyright and Trademark Law. Copyright law says that yes they can fork the project. Trademark Law however says that Miss B. is allowed to follow up legally to prevent a trademark, which can be registered or unregistered, from being confused by another similar trademark that might be confused with it. The fact that the trademark is similar, and the product is similar, is doubly damning in that case. So while a fork is certainly allowed by copyright, the original owner is completely within their rights to make sure that the fork is not in any way confusing with the original product. If Miss B. would use GPL'd code and won't agree to the GPL, than Miss B. is violating the GPL, but Miss R. isn't allowed to decompile the software of Miss B., because of copyright laws. Am I wrong? This is correct, so long as Miss B is distributing the code. The legal process can mean that either Miss B either must cease distribution of the product, or come into compliance with the GPL copyright. However that also means that it is the choice of Miss B. and not of Miss R. to force the second option. But again, Miss B. accepted the GPL, but while the nail polish needs to dry, she wasn't able to distribute the source code, she only had time to distribute the binary. She wrote exactly this to the manicure developers mailing list, that's why Miss R. decided to decompile the code. This is much greyer area to tell the truth, and one I won't touch. But if you look at the SFLC's cases in the past about the GPL, you will notice a theme of them giving ample time to come into compliance with the terms of the GPL before taking the product to court. However those are all slightly different due to none of those products to my knowledge, being GPLd software that wasn't already availiable form another source. So I suspect there will be no final answer on this until a judge(Or more likely multiple) are forced to answer it in a courtroom. Seablade ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Kim did the switch to Linux
Damn Reply-To-All, yet again. On Fri, Aug 7, 2009 at 6:56 PM, Thomas Vecchione seabla...@gmail.comwrote: On Fri, Aug 7, 2009 at 6:40 PM, Chuckk Hubbard badmuthahubb...@gmail.comwrote: I guess my thought was that people who want to use audio professionally are less likely to make decisions based on what requires the least effort, which seems to be the main bragging point for OSX as well as the main complaint about Linux. They are more likely to choose what works for them. Which for many people OS X works for them out of the box. Linux doesn't even come close at this point to doing so out of the box for most people. So lets say I am an audio professional about to upgrade, ignoring financial things for the moment for various reasons. I have a choice. I can either go with OS X and get an experience that works out of the box for what I need it to. Or I can go with Linux and spend hours learning a new OS and tinkering with the commandline, before I can even start to work professionally. For many people there isn't much choice there. Seablade ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Impro-Visor created on sourceforge
Thomas Vecchione wrote: Once again forgot to hit Reply-All. It's weekend :D. You are confusing Copyright and Trademark Law. Copyright law says that yes they can fork the project. Trademark Law however says that Miss B. is allowed to follow up legally to prevent a trademark, which can be registered or unregistered, from being confused by another similar trademark that might be confused with it. Okay, I guess you're right, because I have two web browsers, one is called Firefox and the other is called Iceweasel, for me, as a user they only differ by the name and logo and there seems to be a reason for this ;). Icevamp or Hotvamp instead of Improvisor might be an alternative. But again, Miss B. accepted the GPL, but while the nail polish needs to dry, she wasn't able to distribute the source code, she only had time to distribute the binary. She wrote exactly this to the manicure developers mailing list, that's why Miss R. decided to decompile the code. This is much greyer area to tell the truth, and one I won't touch. I agree, that's why laws are construable, have some margin. It's impossible to factor in every devisable situation. Everybody seems to understand the GPL and the law after that long discussion for this basic issues. Here is a basic issue, with an unusual exception. I guess even two judges could pronounce two different sentences, in the same town, at the same court. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAU] Kim did the switch to Linux
On Fri, Aug 7, 2009 at 7:21 PM, James Cameron qu...@us.netrek.org wrote: The installation discs for Mac OS X already contain software licensed under the GNU GPL (e.g. bash), so the additional obligations under the GPL would not have been the reason to exclude a compiler. It seems much more likely that it was the size. Several hundred megabytes that aren't required by most users should always be omitted from the installation discs, so that more room is made for what most users require. The same is done with Ubuntu and Debian installation images. Most of the tools needed to build Ubuntu are not included in the installation image, and require downloading apt-get build-dep $packagename. You misunderstood what he was saying. The GCC compiler IS included on the installation disks as part of the XCode program. You can also download this program off of the internet(The download is over a gig by the way last I looked). The complaint is that Apple only bundles gcc with the XCode program and a lot of useless stuff that aren't necessarily used by people like us. But they are used by most Mac developers, and Apple I am sure wants to encourage their use and 'their' way of doing things. Seablade ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
