"Oh come off it, you're full of it. If you don't support the idea, then perhaps you can explain why you hold the software patents at all?"
Because it's a business requirement in my area. People without patents are sued out of existence. I don't like it, but that's life.
"Guys like you spout off on this tip that you'd "rather lose more sales than lose more freedoms" as though it were that cut and dried. All of you would sing a different tune if you lost all or most of your sales, and were suddenly trying to pay your bills."
That has happened to me once - my company produced a plugin for a Big Proprietary System which one day made my plugin obsolete by providing the same functionality natively. We had to retarget our efforts in a short time.
Now my business is diversified, so it shouldn't happen again.
"I mean the liability that comes from someone using my product improperly. My product undergoes many safety tests. Someone who steals it winds up bypassing some of my advice. I'm still liable for it exploding in their face."
That's fair. However, I don't think that you are not liable in that case even now.
"Fair use rights extend quite far -- because they exist by accident."
Uhm. No, you're wrong. Copyright exists by accident. In fact, not long ago copyright was quite limited.
"And defensive patents are exactly that. But since not having them would put you in the position to fight for your work, and having them puts others in the position of not being able to fight for theirs, you most certainly are supporting the patents. You're stopping other people from doing similar work."
I know for a fact that there are works that infringe my patent. Hell, I have direct competitors with the similar functionality. So no, my patent doesn't stop anyone. Almost no one does patent searches before starting the work.
"I'd certainly say you're supporting software patents by holding some. The alternative is obviously to fight them having not protected yourself."
That's the theory. But in practice having a defensive patent helps. I'd happily burn my patent when/if software patents become invalid. I also won't use it offensively.
"I'm worried about someone benefitting from my work, and to a lesser extent, my being liable for what they do with it."
??? I'm writing software with the sole purpose that its users will benefit from it.
Do you mean 'benefit without paying me $$$$$$'?
Well, that doesn't concern me. Fair use rights are fair. I'm not worried that some professors might distribute my software to their students. I might lose a sale or two that way, but my children won't need to live in the Stallman's 'Right to Read' world.
"I'm agreeing with most of the intent, and certainly all of the purpose. Supporting copyright is far more importantto me than supporting fair-use, and I'd certainly sacrifice the latter entirely in order to improve the former."
Sorry. You are a minority. A corporate drone without creativity and/or life. Please, move along. Don't let the door hit you.
And yes, I'm a corporate owner with intellectual property to protect. No, I do not support neither software patents (even though I hold some), nor this treaty. My software is sold as a service and as a product, I do lose some sales due to pirates (not much, really). But I would rather lose more sales than lose more freedoms.
"However these same folks maintain superior control of their vehicles and never get into accidents unless they are caused by another driver's lack of control."
Do you realize that traffic rules were designed _specifically_ to minimize the impact of drivers' mistakes? And that if your 'best drivers' actually obeyed the laws, they'd have most probably avoided accidents. Even the ones caused by other drivers.
If you make Bob the Janitor to be the CEO, then he gets the full authority of the CEO. He can easily ruin the company and no amount of external consultants will help.
Besides, only large companies will have enough resources for such schemes (they are very complicated legally).
The TPM chip authenticates the CPU and BIOS as the first step.
And you can't "hardcore the answer into the new chip", TPM chips are supposed to be _physically_ secure on the hardware circuit level. It might be possible if you're the NSA.
There's one _real_ attack - gain control just after the startup even before TPM is initialized. You can protect against this by carefully designing your chipset, but there were several demonstrated attacks of this kind.
"The remaining hole is that the TPM does not verify itself to the user and so you can't really believe that it is doing what it should be doing once it has left your possession."
Oh, but it does. Just ask TPM to sign its serial number. Then check it using a public key.
OK. Mixing in the kernel is right for special purposes when you care only about squeezing extra 15% of performance sacrificing security, isolation and sanity.
"What does your 386 have to do with the discussion?" It works, doesn't it?
"You're just feeling argumentative, and you feel the need to put down OSS4 - which works? OSS4 is flawed, it has a design from the previous millennium. That's why.
"The kernel has exception handling tables. This is used for a variety of things, primarily access to user space memory. My day is not ruined."
The current treatment of FPU exceptions is 'panic'. Go on, try to persuade kernel people to change it.
"No. Look, I could eliminate userspace entirely if I wanted to. (it's just a trivial change to not exec init) I can throw pretty much anything into the kernel. The kernel rules all."
Go on. Try to read config files from the kernel space, for example. Let's see how far you'll fly when Linus Torvalds kicks you.
"Um??? They sure are, and I'm not limited to threads. I can use tasklets, softirqs, regular old interrupt handlers, or my own evil invention. I can even disable interrupts if I please."
And I can set realtime priority for a thread, which in practice is more than enough.
"I didn't suggest it required the X server. I said it was the same sort of thing. It's a userspace program that is unable to create hooks for SE Linux policy or get capability bit allocations. Sure, I can use SE Linux as a big hammer, but I can't ask SE Linux to control the internals of non-kernel code."
Uhm. But it can. You can't use capability bits, but nobody uses them anyway. Besides, PulseAudio can use _userspace_ authorization system (DBUS + rtkit) which is right now much more usable than anything SELinux people can come up with.
But it will be VERY hard to avoid floating point exceptions in complex audio mixing code.
For example, graphics folks had to improvise by using fixed-point arithmetic which is translated to floating point at the very last moment (without using floating point instructions at all).
"Thats the underlying problem here - the creator may indeed be correct when he says that 'such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people', but those people are outweighed by the non-technical masses suffering a bad experience."
The problem is, Linux audio is broken and it HAS to be fixed. PulseAudio just exposes the problems in it. And you can't fix these bugs without user input.
Uhm. No, it doesn't. The first floating point exception will ruin your whole day.
"The same goes for pretty much anything else, Bluetooth included if you actually care."
Again, no. You need support from the userspace for Bluetooth.
"Even better, in the kernel I can get the ultimate in real-time performance."
Wrong. Kernel threads are not any different from the userspace threads.
"I can get working fine-grained security like SE Linux instead of crap like that offered by the X server."
Wrong, as usual. PulseAudio does not depend on the X-server and you can use SELinux just fine. In fact, PulseAudio works under a non-privileged account, so a flaw somewhere in the mixer code won't give the attacker the instant system-level access.
Slashdot Mirror
"Oh come off it, you're full of it. If you don't support the idea, then perhaps you can explain why you hold the software patents at all?"
Because it's a business requirement in my area. People without patents are sued out of existence. I don't like it, but that's life.
"Guys like you spout off on this tip that you'd "rather lose more sales than lose more freedoms" as though it were that cut and dried. All of you would sing a different tune if you lost all or most of your sales, and were suddenly trying to pay your bills."
That has happened to me once - my company produced a plugin for a Big Proprietary System which one day made my plugin obsolete by providing the same functionality natively. We had to retarget our efforts in a short time.
Now my business is diversified, so it shouldn't happen again.
"I mean the liability that comes from someone using my product improperly. My product undergoes many safety tests. Someone who steals it winds up bypassing some of my advice. I'm still liable for it exploding in their face."
That's fair. However, I don't think that you are not liable in that case even now.
"Fair use rights extend quite far -- because they exist by accident."
Uhm. No, you're wrong. Copyright exists by accident. In fact, not long ago copyright was quite limited.
"And defensive patents are exactly that. But since not having them would put you in the position to fight for your work, and having them puts others in the position of not being able to fight for theirs, you most certainly are supporting the patents. You're stopping other people from doing similar work."
I know for a fact that there are works that infringe my patent. Hell, I have direct competitors with the similar functionality. So no, my patent doesn't stop anyone. Almost no one does patent searches before starting the work.
"I'd certainly say you're supporting software patents by holding some. The alternative is obviously to fight them having not protected yourself."
That's the theory. But in practice having a defensive patent helps. I'd happily burn my patent when/if software patents become invalid. I also won't use it offensively.
"I'm worried about someone benefitting from my work, and to a lesser extent, my being liable for what they do with it."
??? I'm writing software with the sole purpose that its users will benefit from it.
Do you mean 'benefit without paying me $$$$$$'?
Well, that doesn't concern me. Fair use rights are fair. I'm not worried that some professors might distribute my software to their students. I might lose a sale or two that way, but my children won't need to live in the Stallman's 'Right to Read' world.
"I'm agreeing with most of the intent, and certainly all of the purpose. Supporting copyright is far more importantto me than supporting fair-use, and I'd certainly sacrifice the latter entirely in order to improve the former."
Sorry. You are a minority. A corporate drone without creativity and/or life. Please, move along. Don't let the door hit you.
And yes, I'm a corporate owner with intellectual property to protect. No, I do not support neither software patents (even though I hold some), nor this treaty. My software is sold as a service and as a product, I do lose some sales due to pirates (not much, really). But I would rather lose more sales than lose more freedoms.
"However these same folks maintain superior control of their vehicles and never get into accidents unless they are caused by another driver's lack of control."
Do you realize that traffic rules were designed _specifically_ to minimize the impact of drivers' mistakes? And that if your 'best drivers' actually obeyed the laws, they'd have most probably avoided accidents. Even the ones caused by other drivers.
If you make Bob the Janitor to be the CEO, then he gets the full authority of the CEO. He can easily ruin the company and no amount of external consultants will help.
Besides, only large companies will have enough resources for such schemes (they are very complicated legally).
The TPM chip authenticates the CPU and BIOS as the first step.
And you can't "hardcore the answer into the new chip", TPM chips are supposed to be _physically_ secure on the hardware circuit level. It might be possible if you're the NSA.
There's one _real_ attack - gain control just after the startup even before TPM is initialized. You can protect against this by carefully designing your chipset, but there were several demonstrated attacks of this kind.
However, this is definitely not a trivial task.
Yes, toy rockets won't be reliable. Yes, they'll often fail. Yes, it's hard to scale the production.
But they're more than enough for one-off operations like assassinations or terror acts.
"The remaining hole is that the TPM does not verify itself to the user and so you can't really believe that it is doing what it should be doing once it has left your possession."
Oh, but it does. Just ask TPM to sign its serial number. Then check it using a public key.
This check will fail if TPM has been replaced.
Yes. You can have almost perfect _physical_ security with TPM.
Alas, most of developers are allergic to it, even if it has good uses.
Vista _has_ a similar architecture:
http://blogs.technet.com/photos/blog_photo_gallery/images/450100/original.aspx
(from http://windowsteamblog.com/blogs/windowsvista/articles/450038.aspx )
I.e. mixing and processing is done in userspace.
Such architecture is great, because you can do a lot more tasks sanely in userspace than in kernel.
OK. Mixing in the kernel is right for special purposes when you care only about squeezing extra 15% of performance sacrificing security, isolation and sanity.
No, I really hate them. I have a real headset with mic and stereo headphones.
Nope. PulseAudio has a very sane architecture.
In fact, OS X and Windows 7 have similar architectures.
Of course, FP in kernel exists and is used. Hell, I have seen even kernel modules in Fortran (!!!). But that doesn't make it right.
Latency of about 10 microseconds might actually be possible with the -rt kernel: http://www.densan.co.jp/pdf/realtime-en.pdf
"Bluetooth has no place in my house."
Ok. But it has a place in my house.
"What does your 386 have to do with the discussion?"
It works, doesn't it?
"You're just feeling argumentative, and you feel the need to put down OSS4 - which works?
OSS4 is flawed, it has a design from the previous millennium. That's why.
I use it for speaking. I just hate holding the phone for tens of minutes at a time.
"So, what you're saying is, OSS4 doesn't work? I sure hope you don't tell my computers that - they seem to think that it DOES WORK."
So? My old 80386 does work too.
"Seriously - try it, you'll like it."
I tried it and don't like it.
"Oh - bluetooth? Don't own it, can't see the point in it. USB seems to do everything that bluetooth claims to do."
How can I connect my wireless headset to USB _and_ to my cell phone?
"The kernel has exception handling tables. This is used for a variety of things, primarily access to user space memory. My day is not ruined."
The current treatment of FPU exceptions is 'panic'. Go on, try to persuade kernel people to change it.
"No. Look, I could eliminate userspace entirely if I wanted to. (it's just a trivial change to not exec init) I can throw pretty much anything into the kernel. The kernel rules all."
Go on. Try to read config files from the kernel space, for example. Let's see how far you'll fly when Linus Torvalds kicks you.
"Um??? They sure are, and I'm not limited to threads. I can use tasklets, softirqs, regular old interrupt handlers, or my own evil invention. I can even disable interrupts if I please."
And I can set realtime priority for a thread, which in practice is more than enough.
"I didn't suggest it required the X server. I said it was the same sort of thing. It's a userspace program that is unable to create hooks for SE Linux policy or get capability bit allocations. Sure, I can use SE Linux as a big hammer, but I can't ask SE Linux to control the internals of non-kernel code."
Uhm. But it can. You can't use capability bits, but nobody uses them anyway. Besides, PulseAudio can use _userspace_ authorization system (DBUS + rtkit) which is right now much more usable than anything SELinux people can come up with.
Avoiding divide by zero is easy.
But it will be VERY hard to avoid floating point exceptions in complex audio mixing code.
For example, graphics folks had to improvise by using fixed-point arithmetic which is translated to floating point at the very last moment (without using floating point instructions at all).
"Thats the underlying problem here - the creator may indeed be correct when he says that 'such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people', but those people are outweighed by the non-technical masses suffering a bad experience."
The problem is, Linux audio is broken and it HAS to be fixed. PulseAudio just exposes the problems in it. And you can't fix these bugs without user input.
"The FPU works perfectly fine in a Linux kernel."
Uhm. No, it doesn't. The first floating point exception will ruin your whole day.
"The same goes for pretty much anything else, Bluetooth included if you actually care."
Again, no. You need support from the userspace for Bluetooth.
"Even better, in the kernel I can get the ultimate in real-time performance."
Wrong. Kernel threads are not any different from the userspace threads.
"I can get working fine-grained security like SE Linux instead of crap like that offered by the X server."
Wrong, as usual. PulseAudio does not depend on the X-server and you can use SELinux just fine. In fact, PulseAudio works under a non-privileged account, so a flaw somewhere in the mixer code won't give the attacker the instant system-level access.
Yeah, sure.
How does floating point works for you in the kernel? And what about Bluetooth?
Well, thought so.
PulseAudio is NOT unneeded.
First, Bluetooth audio _sucks_ without PulseAudio.
Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.
Third, ALSA's volume controls are horrible and PulseAudio really helps here.
Fourth, PulseAudio has a ton of other nice features: streams tagging and automatic volume control, joined devices, mic boost, etc.
Actually no. This graph looks more like a cliff, than like a hockey stick.