Gotta love Microsoft
on
Gates on Spam
·
· Score: 2, Insightful
Typical Microsoft conduct: showing up late to the party (people have been inventing "solutions" to SPAM for years now), coming up with solutions other people have already proposed (domain-verified sending and "pay with cycles" have been thought of a million times), and claiming to own them (with patents).
I especially love:
"Since they're dedicating it to the public free of charge, (Microsoft) doesn't want to be the patsy who builds a foundation just so other people can come along and erect a building on it, then sell the building," he said.
In cooledit (I'm on a mac atm, so sadly, I cannot tell you specifically where to find this tool), you can whip out ce's analysis program, which will tell you the exact tuning of a given sound. So, you can figure out that the note is actually an F# rather than a C, and either work around it in buzz or reason, or you could change the pitch of the sample to adjust it to a C. In case you're curious, audacity's analysis doesn't support this. It'll run a freq analysis, but not actually tell you anything useful out of it.
That's simply not true. Open View->Plot Spectrum. You will see the spectrum, and it should peak at the pitch of the fundamental note. Now move the cursor over that peak. Now you see a display of the form "Cursor: 3239 Hz (G#7) = -41 dB."
Of course Audacity doesn't have everything, and we would love to have time to develop more features. But at least give us credit for the features we do have.
Have you tried 1.2? The audio i/o layer was completely rewritten to use a real-time threading model. You certainly shouldn't be getting latencies of half a second.
This program looks like it's off to a good start, but it's not gonna replace cooledit for me. Namely, it lacks a lot of basic plugins (ADSR, amplification envelopes, fade ins/outs that don't suck, spectrum analysis, etc). Hopefully, the VST enabler project will take care of most of this.
For spectrum analysis, go View->Plot Spectrum. There's also spectrum view mode, which you can select from any track's menu. Envelope editing is built in to the interface; just choose the envelope tool and start dragging points.
We definitely could use some more effects though. The most impressive ones right now are noise removal, and change pitch/tempo/speed.
Legally, you have agreed to the EULA and demonstrated your acceptance by that mouse click.
References, please? EULA's are just ludicrous, and if the courts uphold them in all their ridiculousness, things are worse than I thought. I don't see why pirate websites don't spring up that force you to go through a portal that says "by proceeding, you agree not to prosecute us for copyright infringement." Or why books don't put notices on the first page that says "by reading this book, you agree not to publish any unfavorable reviews.
Not only do EULA's attempt to establish a legally binding contract through something as informal as a mouse click, but they essentially allow producers to force arbitrary, legally binding terms on users of their products. Is something really yours if it is laid with legal booby-traps from whoever sold it to you?
Disagreeing with the GPL does not terminate your rights to distribute GPL software. Calling it unconstitutional does not terminate your rights to distribute GPL software. Being an asshole with the name "McBride" does not terminate your rights to distribute the GPL. The word "accept" in clause 4 has specific legal meaning. You "accept" the Microsoft EULA by clicking on a widget with a mouse cursor. Even if you shouted at the top of your lungs "I DISAGREE" while clicking that button, you have legally accepted that license.
Really? Just because Microsoft said so? I claim that by reading this message, you are agreeing to the end-user message agreement, whereby you must send me all of your assets. Do you feel bound by this agreement? Why not?
You indicate acceptance of the GPL by taking advantage of the rights it gives you that you would not otherwise have. "Agreements" of the form "By doing X you agree to Y" usually limit your rights. What gives authors of such agreements the right to arbitrarily declare that an action on your part that is already within your rights binds you to their agreement?
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
I think your confusion here is that you are confusing drivers with clients. A driver is an integral part of the JACK server that is responsible for providing a time source (so that the whole JACK system can run exactly in sync with a sound card). It can also provide ports like a client, but unlike a client it runs in-process, as part of the JACK server. There can only be one driver per JACK server process. Clients, on the other hand, are separate processes that talk to the JACK server using pipes and shared memory, and there can be many of them.
There was talk at one point of making it possible to create in-process clients. They would exist as an.so that the JACK server would load at runtime. I don't know if this ever materialized. These would make JACK resemble Gstreamer a bit more.
3. What do you mean by "with Gstreamer the whole graph is in-process"?
Imagine you are drawing a picture of sources and sinks and connections between them. With Gstreamer that whole picture, the whole network of data all lives inside one single application (one process). With JACK, each node of the network is a separate process, except the driver.
My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
If the only goal was low-latency for a single application talking to a sound card, then indeed JACK would not be necessary. But an even more fundamental goal of JACK is that applications be able to work together. JACK aims to provide the lowest possible latency, while also providing sample-accurate synchronization, for this inter-application communication.
It is similar to JACK in that you have a signal graph. However there is more different than the same. JACK is for communication between different processes. It allows applications to send data to each other so that you can have a toolbox of applications that all work together. With Gstreamer the whole graph is in-process; it is designed to give individual applications the capability to do complex media tasks. The two are complementary.
A number of the electronic organs used in 60's and 70's rock music are considered "modern classics" today, and had their own unique sounds that many people really like.
I was speaking to electronic organs that are trying to imitate pipe organs. Rock organs are to pipe organs as an electric guitar is to a lute. The former are new instruments that spring from the evolution of an instrument family.
I'd agree that the boomy, room-filling sound of a pipe organ is something that would be very tough to reproduce perfectly accurately with nothing but electronics -- but I think a pretty good approximation can be done.
I never said it wasn't possible, I was only commenting that the electronic organs that exist today (specifically, those that imitate pipe organs) do not sound nearly as good as real pipe organs (well, good pipe organs. there are a lot of crappy pipe organs around). Of course that is subjective; has anyone ever invented an objective standard of how "good" something sounds?
I love playing the organ, but playing an electronic organ does nothing for me.
Hate to point out the obvious, but without pipes it's not a pipe organ. In organ circles, these are known as "electronic" organs (crazy jargon, I know).
Looks like an interesting project though. Electronic organs have never sounded remotely as good as the real thing (and they've been making them since the 60s at least). For all the thought and work they've put into this, I wonder if it will sound significantly better.
The copyright holders of the songs decide what you can and can't do, which, honestly is they way it shoudl be.
Bullshit and bullshit.
Copyright holders have a specific set of exclusive rights, among them:
The right to make copies
The right to create derivative works
The right to publicly perform the work
This is not a complete list, but the point is that there is a specific, enumerated set of what rights copyright holders can deny to other people. They cannot decide "what you can and can't do." If a CD says on the packaging "you can only listen to this CD on Thursdays," you can give it the finger and say "I have legally obtained this CD, there is no law preventing me from listening to this CD whenever I please."
It's really, really disturbing to that people have this perception that copyright holders have some kind of blank check to institute whatever kind of regulations they want on the use of their works.
If the output of a process is producing unacceptable results, it doesn't require knowledge of the process to determine that it is a failure.
Regardless of how the patent system works, if inappropriate patents are being granted regularly (and worse, enforced) it means that something, somewhere is broken. No explanation can possibly contradict that.
As with the last story about project Gutenberg, I have the same comment. I love the philosophy of project Gutenberg, but the fact that they continue to use plain text as the canonical formatting makes the collection seriously less useful. Using XML would give only advantages.
What advantages? Advantages like indicating what words are actually part of a title, so that a reader could display titles in large print and provide a table of contents. Advantages like having real bold, italic, and underline. Advantages like being able to handle characters not in ASCII. Advantages like allowing a reader to break lines however makes most sense for that situation (for example, handhelds are going to have shorter lines than a large monitor). The list goes on.
Their argument for continuing to favor ASCII is to support the widest possible usability, now and in the future, since markup languages can come and go. This doesn't stand up to scrutiny though, for the simple reason that XML contains strictly more information than plain text. XML can be flawlessly converted to plain text by a program, but the opposite is not true: plain text cannot be converted to XML. Was that line break the end of a stanza, or simply a line of a paragraph? Is that single line in all-caps a title or is it a paragraph of shouting? This information simply cannot be extracted from plain text. Not to mention the problem of characters that aren't in ASCII.
Suppose that XML is just a fad, that it's a horrible joke being perpetuated by hordes of clueless professionals who love buzzwards. Suppose no one uses XML in 10 years. Even if this is true XML is still a better choice than plain text because XML has enough information to automatically convert the books into whatever superior format emerges in the future. Plain text does not.
This example just goes to show what a mess will be created if the govt. simply collects a pot of money from ISPs and then tries to divy it up to the recording inductry.
Who said this is what compulsory licensing will do?
As I understand it, compulsory licensing means just that: publishers are compelled to offer licenses at a predetermined rate. That means I can download any song from anywhere, and as long as I send the predetermined license cost to the owner of the copyright, that copy is legal.
What does this have to do with collecting money from ISPs?
Imagine how useful services like this or the iTunes store could be if they were more comprehensive in the titles they carry.
Imagine how easy it would be to make them comprehensive if the copyright holders were forced to offer you a license at a predetermined rate, instead of having to negotiate deals with everyone separately.
Imagine how much revenue filesharing could generate for copyright holders if it was easy to purchase legal licenses for the files being shared at a reasonable rate. On our own terms (for example; MP3 and AAC are not a formats I wish to purchase music in).
I haven't thought about this terribly much, but compulsory licensing seems like it could be a solution to the standoff that currently exists between filesharers who won't give up filesharing and the industry that refuses to make it easy to legally purchase digital content.
I have a couple to add to this. These are ways I have used mod_perl in my current job.
Hacks such as cleaning up after Microsoft's broken DAV implementation in Windows XP. If a Windows XP client types in a username and password to authenticate against a DAV share, Windows will prepend SOMEDOMAIN\ to the username. This screws up authentication on the server. However you can write a mod_perl handler that intercepts the request in its early stages and rewrites the authentication header to strip SOMEDOMAIN\. Here's the script I wrote to do this
Authorize users by arbitrary criteria. I wrote an authorization handler that will allow users to DAV into any URL of the form/theirusername/*.
Ummm, singers, like viola players, are notorius for a) shitty timing and b) a remarkable inability to hit an equally tempered note accurately.
There's no reason for a singer or a violist to submit to the imperfections of equal temperament. Keyboardists are forced to only because they can't re-tune on the fly.
Not only is there apt for rpms, but there's an even better utility called yum (yellow dog updater, modified). Yum makes it incredibly easy to set up your own software repository, making it easy to keep your machines updated. Not only are apt and yum available, but Red Hat recently announced support for yum and apt repositories in up2date, therefore eliminating the subscriptions and fees previously associated with up2date.
Excellent. Please direct me to the free APT-RedHat and Yum-RedHat archives of almost 10,000 packages that are continuously receiving security updates for their "stable" release and bleeding-edge updates for the more courageous users who opt for "unstable." And show me the bug tracking system that I can use to report bugs in those packages to the maintainers.
"There's apt for rpm" is a red herring, because apt is only part of the story. Debian is attractive because there is a world-wide group of volunteers who keeps it up to date, maintaining packages that they themselves use. And it is the most comprehensive binary archive out there, by far.
I use RedHat, and its out-of-the-box experience is light-years ahead of Debian. But as far as package archives there's no comparison.
The cases are quite clear on where the boundaries of "derivative work" are, and what is protected by copyright.
Has this ever been tested for software? If so, can you provide a reference?
The prevailing legal climate in the software industry seems to subscribe to a much more expansive notion of "derivative works" than you describe. "Clean room" reimplementations are attempted only under extreme caution. There seems to be a belief that a person who has ever seen copyright-encumbered code becomes "contaminated" and can never reimplement the same functionality without it being a derivative work. No one would dream of making a similar argument for music, art, or literature.
Slashdot Mirror
Typical Microsoft conduct: showing up late to the party (people have been inventing "solutions" to SPAM for years now), coming up with solutions other people have already proposed (domain-verified sending and "pay with cycles" have been thought of a million times), and claiming to own them (with patents).
I especially love:
"Since they're dedicating it to the public free of charge, (Microsoft) doesn't want to be the patsy who builds a foundation just so other people can come along and erect a building on it, then sell the building," he said.
Can you say "BSD Stack?"
In cooledit (I'm on a mac atm, so sadly, I cannot tell you specifically where to find this tool), you can whip out ce's analysis program, which will tell you the exact tuning of a given sound. So, you can figure out that the note is actually an F# rather than a C, and either work around it in buzz or reason, or you could change the pitch of the sample to adjust it to a C. In case you're curious, audacity's analysis doesn't support this. It'll run a freq analysis, but not actually tell you anything useful out of it.
That's simply not true. Open View->Plot Spectrum. You will see the spectrum, and it should peak at the pitch of the fundamental note. Now move the cursor over that peak. Now you see a display of the form "Cursor: 3239 Hz (G#7) = -41 dB."
Of course Audacity doesn't have everything, and we would love to have time to develop more features. But at least give us credit for the features we do have.
Have you tried 1.2? The audio i/o layer was completely rewritten to use a real-time threading model. You certainly shouldn't be getting latencies of half a second.
(I did a lot of the real-time audio work)
This program looks like it's off to a good start, but it's not gonna replace cooledit for me. Namely, it lacks a lot of basic plugins (ADSR, amplification envelopes, fade ins/outs that don't suck, spectrum analysis, etc). Hopefully, the VST enabler project will take care of most of this.
For spectrum analysis, go View->Plot Spectrum. There's also spectrum view mode, which you can select from any track's menu. Envelope editing is built in to the interface; just choose the envelope tool and start dragging points.
We definitely could use some more effects though. The most impressive ones right now are noise removal, and change pitch/tempo/speed.
Legally, you have agreed to the EULA and demonstrated your acceptance by that mouse click.
References, please? EULA's are just ludicrous, and if the courts uphold them in all their ridiculousness, things are worse than I thought. I don't see why pirate websites don't spring up that force you to go through a portal that says "by proceeding, you agree not to prosecute us for copyright infringement." Or why books don't put notices on the first page that says "by reading this book, you agree not to publish any unfavorable reviews.
Not only do EULA's attempt to establish a legally binding contract through something as informal as a mouse click, but they essentially allow producers to force arbitrary, legally binding terms on users of their products. Is something really yours if it is laid with legal booby-traps from whoever sold it to you?
Oh, the evil of "licensed, not sold."
Disagreeing with the GPL does not terminate your rights to distribute GPL software. Calling it unconstitutional does not terminate your rights to distribute GPL software. Being an asshole with the name "McBride" does not terminate your rights to distribute the GPL. The word "accept" in clause 4 has specific legal meaning. You "accept" the Microsoft EULA by clicking on a widget with a mouse cursor. Even if you shouted at the top of your lungs "I DISAGREE" while clicking that button, you have legally accepted that license.
Really? Just because Microsoft said so? I claim that by reading this message, you are agreeing to the end-user message agreement, whereby you must send me all of your assets. Do you feel bound by this agreement? Why not?
You indicate acceptance of the GPL by taking advantage of the rights it gives you that you would not otherwise have. "Agreements" of the form "By doing X you agree to Y" usually limit your rights. What gives authors of such agreements the right to arbitrarily declare that an action on your part that is already within your rights binds you to their agreement?
Just a few things to add to Paul's post.
.so that the JACK server would load at runtime. I don't know if this ever materialized. These would make JACK resemble Gstreamer a bit more.
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
I think your confusion here is that you are confusing drivers with clients. A driver is an integral part of the JACK server that is responsible for providing a time source (so that the whole JACK system can run exactly in sync with a sound card). It can also provide ports like a client, but unlike a client it runs in-process, as part of the JACK server. There can only be one driver per JACK server process. Clients, on the other hand, are separate processes that talk to the JACK server using pipes and shared memory, and there can be many of them.
There was talk at one point of making it possible to create in-process clients. They would exist as an
3. What do you mean by "with Gstreamer the whole graph is in-process"?
Imagine you are drawing a picture of sources and sinks and connections between them. With Gstreamer that whole picture, the whole network of data all lives inside one single application (one process). With JACK, each node of the network is a separate process, except the driver.
My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
If the only goal was low-latency for a single application talking to a sound card, then indeed JACK would not be necessary. But an even more fundamental goal of JACK is that applications be able to work together. JACK aims to provide the lowest possible latency, while also providing sample-accurate synchronization, for this inter-application communication.
It is similar to JACK in that you have a signal graph. However there is more different than the same. JACK is for communication between different processes. It allows applications to send data to each other so that you can have a toolbox of applications that all work together. With Gstreamer the whole graph is in-process; it is designed to give individual applications the capability to do complex media tasks. The two are complementary.
I just read my warranty document for my new PowerBook 12" and I couldn't find anything like that either. The closest I could find is:
This warranty does not apply [...] to damage caused by use with non-apple products
So if running Linux damaged your computer, that damage wouldn't be covered. But even that wouldn't exempt Yellow Dog Linux.
(This is of course my interpretation, and IANAL).
A number of the electronic organs used in 60's and 70's rock music are considered "modern classics" today, and had their own unique sounds that many people really like.
I was speaking to electronic organs that are trying to imitate pipe organs. Rock organs are to pipe organs as an electric guitar is to a lute. The former are new instruments that spring from the evolution of an instrument family.
I'd agree that the boomy, room-filling sound of a pipe organ is something that would be very tough to reproduce perfectly accurately with nothing but electronics -- but I think a pretty good approximation can be done.
I never said it wasn't possible, I was only commenting that the electronic organs that exist today (specifically, those that imitate pipe organs) do not sound nearly as good as real pipe organs (well, good pipe organs. there are a lot of crappy pipe organs around). Of course that is subjective; has anyone ever invented an objective standard of how "good" something sounds?
I love playing the organ, but playing an electronic organ does nothing for me.
Hate to point out the obvious, but without pipes it's not a pipe organ. In organ circles, these are known as "electronic" organs (crazy jargon, I know).
Looks like an interesting project though. Electronic organs have never sounded remotely as good as the real thing (and they've been making them since the 60s at least). For all the thought and work they've put into this, I wonder if it will sound significantly better.
Unix on Intel, probably.
"Samba isn't your IP. What gives you the right to sell the copyrighted work of others?"
What can SCO possibly answer, while maintaining that the GPL is illegitimate?
It looks like the article has been revised! The word "trademark" no longer appears, and the above statement has been replaced with
The lawsuit was bold, alleging violations of trade secrets and copyrights related to a hot market segment, Linux. (emphasis mine)
Bullshit and bullshit.
Copyright holders have a specific set of exclusive rights, among them:
This is not a complete list, but the point is that there is a specific, enumerated set of what rights copyright holders can deny to other people. They cannot decide "what you can and can't do." If a CD says on the packaging "you can only listen to this CD on Thursdays," you can give it the finger and say "I have legally obtained this CD, there is no law preventing me from listening to this CD whenever I please."
It's really, really disturbing to that people have this perception that copyright holders have some kind of blank check to institute whatever kind of regulations they want on the use of their works.
If the output of a process is producing unacceptable results, it doesn't require knowledge of the process to determine that it is a failure.
Regardless of how the patent system works, if inappropriate patents are being granted regularly (and worse, enforced) it means that something, somewhere is broken. No explanation can possibly contradict that.
As with the last story about project Gutenberg, I have the same comment. I love the philosophy of project Gutenberg, but the fact that they continue to use plain text as the canonical formatting makes the collection seriously less useful. Using XML would give only advantages.
What advantages? Advantages like indicating what words are actually part of a title, so that a reader could display titles in large print and provide a table of contents. Advantages like having real bold, italic, and underline. Advantages like being able to handle characters not in ASCII. Advantages like allowing a reader to break lines however makes most sense for that situation (for example, handhelds are going to have shorter lines than a large monitor). The list goes on.
Their argument for continuing to favor ASCII is to support the widest possible usability, now and in the future, since markup languages can come and go. This doesn't stand up to scrutiny though, for the simple reason that XML contains strictly more information than plain text. XML can be flawlessly converted to plain text by a program, but the opposite is not true: plain text cannot be converted to XML. Was that line break the end of a stanza, or simply a line of a paragraph? Is that single line in all-caps a title or is it a paragraph of shouting? This information simply cannot be extracted from plain text. Not to mention the problem of characters that aren't in ASCII.
Suppose that XML is just a fad, that it's a horrible joke being perpetuated by hordes of clueless professionals who love buzzwards. Suppose no one uses XML in 10 years. Even if this is true XML is still a better choice than plain text because XML has enough information to automatically convert the books into whatever superior format emerges in the future. Plain text does not.
Never consider going into public education.
This example just goes to show what a mess will be created if the govt. simply collects a pot of money from ISPs and then tries to divy it up to the recording inductry.
Who said this is what compulsory licensing will do?
As I understand it, compulsory licensing means just that: publishers are compelled to offer licenses at a predetermined rate. That means I can download any song from anywhere, and as long as I send the predetermined license cost to the owner of the copyright, that copy is legal.
What does this have to do with collecting money from ISPs?
Imagine how useful services like this or the iTunes store could be if they were more comprehensive in the titles they carry.
Imagine how easy it would be to make them comprehensive if the copyright holders were forced to offer you a license at a predetermined rate, instead of having to negotiate deals with everyone separately.
Imagine how much revenue filesharing could generate for copyright holders if it was easy to purchase legal licenses for the files being shared at a reasonable rate. On our own terms (for example; MP3 and AAC are not a formats I wish to purchase music in).
I haven't thought about this terribly much, but compulsory licensing seems like it could be a solution to the standoff that currently exists between filesharers who won't give up filesharing and the industry that refuses to make it easy to legally purchase digital content.
I have a couple to add to this. These are ways I have used mod_perl in my current job.
Ummm, singers, like viola players, are notorius for a) shitty timing and b) a remarkable inability to hit an equally tempered note accurately.
There's no reason for a singer or a violist to submit to the imperfections of equal temperament. Keyboardists are forced to only because they can't re-tune on the fly.
He also can give you a named note in just temperament if you prefer that to Well Tempered Clavier equal temperament.
The "Well-Tempered" in "Well-Tempered Clavier" does not refer to equal temperament.
Not only is there apt for rpms, but there's an even better utility called yum (yellow dog updater, modified). Yum makes it incredibly easy to set up your own software repository, making it easy to keep your machines updated. Not only are apt and yum available, but Red Hat recently announced support for yum and apt repositories in up2date, therefore eliminating the subscriptions and fees previously associated with up2date.
Excellent. Please direct me to the free APT-RedHat and Yum-RedHat archives of almost 10,000 packages that are continuously receiving security updates for their "stable" release and bleeding-edge updates for the more courageous users who opt for "unstable." And show me the bug tracking system that I can use to report bugs in those packages to the maintainers.
"There's apt for rpm" is a red herring, because apt is only part of the story. Debian is attractive because there is a world-wide group of volunteers who keeps it up to date, maintaining packages that they themselves use. And it is the most comprehensive binary archive out there, by far.
I use RedHat, and its out-of-the-box experience is light-years ahead of Debian. But as far as package archives there's no comparison.
The cases are quite clear on where the boundaries of "derivative work" are, and what is protected by copyright.
Has this ever been tested for software? If so, can you provide a reference?
The prevailing legal climate in the software industry seems to subscribe to a much more expansive notion of "derivative works" than you describe. "Clean room" reimplementations are attempted only under extreme caution. There seems to be a belief that a person who has ever seen copyright-encumbered code becomes "contaminated" and can never reimplement the same functionality without it being a derivative work. No one would dream of making a similar argument for music, art, or literature.