Has there ever been a format that hasn't been quickly cracked and put on P2P? That it will appear on P2P isn't a good reason to use DRM, because it will anyway. Hint: fair use == less money, thus DRM.
Fair enough: legal MP3 encoders aren't free, you pay for them either directly (buying the software) or indirectly (adware, buying a Mac, etc.
And I'm not entirely sure that LAME is illegal in the US, but it wouldn't surprise me, and it's enough to make me use Vorbis, even if it means re-encoding when I get a portable player. (There will be portable Vorbis players soon, though.)
CDex uses LAME. LAME's site links here . The answer seems to be a big fat maybe. Also, try here, and click on News. Notice BladeEnc was discontinued for reasons including legal hassles. Also, note that RedHat wussed out and pulled MP3 support from RedHat Linux 8.
It really is just using the best tool. For the purely textual parts of notes, typing is faster by far, and the result is notes you can search. For math or diagrams, use paper.
I suppose lawyers are singled out because asshole lawyers have the worst effect on the technology industry. No, it's not right.
I guess what we need is for all, not just most, lawyers to know when to say "No, that's stupid." If a client says "Hmm, I have this patent, lets sue eBay," all the lawyers must say "No, the patent is stupid and it's an abuse of the system." If your client says "Hmm, we kinda have this IP, lets sue IBM over Linux," all the lawyers must say "No, we may not have the IP, it didn't help Linux, the whole thing's a lie, and besides, you'll turn the entire industry against yourself." Granted most lawyers would say that, but they all should.
I still think that's making it too complex. Yeah, CD seek time is horrible, so just write the library so you only ever spawn one cdparanoia per drive. If you read from a file while the drive's busy, you wait your turn (or return EAGAIN if opened nonblocking). Consider the CD-ROM filesystem: it's a filesystem, but concurrent access is unbelieveably slow.
Devices have space for the major and minor numbers, but many "devices" which aren't controlled by the character device layer look like regular files. (Everything in/proc). I don't think that being a file has a guarantee of seekability, efficent concurrent access, etc.
For the CD, just don't support seeking, and return ESPIPE. Many filesystems don't support writing, truncating, updating, and locking. And it wouldn't be too kludgy to support seeking for wav files. (My CD drive actually is perfect: two cdparanoia rips often have the same md5sums! I know this is rare, and the spec says you can be off a little.) Yes, because of lack of error correction and seeking problems, it won't be perfect, but it will be good enough for XMMS.
The implementation would be: when the directory is searched, scan the TOC to get length info. Just estimate for the Ogg files. When a file is opened, spawn a pipeline with cdparanoia and any encoders, and on each read, get the data from that pipeline. On seek in a wav file, restart cdparanoia with a different range. For everything else, return an error.
Frankly, making everything a file is just plain cool, as well as being part of the unix philosophy. If you think audio CDs are bad for files, check out/dev and/proc! Your mouse is a file! None of the character devices support seeking, truncating, or locking; they're more similar to pipes or sockets (also files).
I agree, some things like CD buring aren't right for LUFS. CD burning is bad because how do you decide when to actually write the files? (Packet burning, I think, will and should be implemented in kernel.) I think that mounting audio CDs would be a perfect application for LUFS, though. Some would say "cp/mnt/audiocd/ogg-q5/* ~/music" is the perfect interface.
Digital camera browsing, however, should at least be LUFS. My camera uses compactflash cards that you can just mount, and IHMO that's the best interface. Treat the camera like a drive, because stored pictures and configuration fit perfectly with the file paradigm.
AFAIK, LUFS doesn't support protocol in the path, but it should be simple to write a LUFS module that does just that, mounting other LUFS modules. This could make it very useful.
Btw, can't Linux just sign the NDA and then -- if he finds anything -- remove it from Linux?
Knowing SCO, the NDA contract would keep signers from touching Linux code in any way. Then they'd issue a press release saying Linus must know about the code, because he's scared to look at the evidence (and give up maintainership of Linux).
I agree the gnet filesystem is a big stretch, and automount is somewhat ugly. I think it's an issue of the right tool: LUFS should only be used for things which directly map to files. Meaning FTP, a subset of HTTP (just downloading, no caching, POST, etc.), Samba, scp, etc. And it's best for connection oriented things where mounting makes sense (otherwise, just use wget or your browser). Anyone who writes a web browser depending on LUFS should be shot, but writing one with IOSlaves or gnome-vfs is cool.
Mapping most urls to files isn't a great solution, but neither is mapping files to urls. How do you get a directory listing? How do you change permissions? Consider FTP: do you make a new connection for each URL, or do you keep the connection open for a while in hopes of getting another? Mounting makes sense when there's overhead in establishing a connection, be it parsing a filesystem or making a remote connection.
I guess what I'm saying is that a URL library (IOSlaves and gnome-vfs) is nice to have, and a file system (LUFS, FUSE) is nice, but they shouldn't be one and the same. The URL library can be used for browsers, downloaders, etc, but the filesystem and only the filesystem should be used for naive tools that want to run on a local filesystem.
LUFS or FUSE would be the module you're talking about, which allows you to do filesystems in userspace, and can let users mount them. So Linux can do all three: kernel modules for lean, fast, "real" filesystems, LUFS or FUSE for "exotic" filesystems that shouldn't be in the kernel, and kioslaves and gnome-vfs for those who like reinventing the wheel and want to further bloat their favorite GUI library.
With LUFS, once its module is in, you don't need any other modules, and the user can mount his own filesystems if he has permission to do so. Support is even more uinversal, because the app doesn't need to be KDE or GNOME, it doesn't even need to be dynamically linked (like it would for LD_PRELOAD hacks), absolutely anything can use it. LUFS has 1, 2, and 4 (Gnutellanet, even). I think 3 can be fixed with automount or similar (see my other post). It would be possible to do xmms ~/lufs/gnutella/*/*.
You're right, it would be difficult, though not impossible, to do this securely.
What you need is a very small, simple, well-written SUID process to do the mounting. You'd need to check permissions on the directory you mount. You'd want to be able to configure where a user can mount stuff. This has been done, look at smbmount and smbumount.
Then, as you say, the kernel module part of LUFS needs to be very careful, protecting the kernel from overly huge directory structures, malformed calls, indefinite blocking, etc.
Hmm, I kinda figured you'd had a lower UID, and I didn't expect people who don't use email to read Slashdot.
Besides, cce's right. The guy who wrote FTPFS now wants everyone to use his more general project, LUFS, which allows you to mount FTP, SSH, and even Gnutella filesystems. IMHO, something that makes a nice interface to bring exotic filesystems out of the kernel, allowing for a much more modular design, is much better than a single purpose kernel filesystem that needs to be insmod'ed and bloats the kernel.
That's what LUFS does. Someone just needs to either port the kioslaves and gnome-vfs libraries to LUFS or FUSE or rewrite them, whichever is easier. The only advantage of kioslaves and gnome-vfs is that they don't need mounting, so they are more convenient.
I think the same thing could be done with LUFS, though. Using either automount or a specifically designed LUFS filesystem, make a filesystem where references to a protocol name would cause it to be mounted. For example,
gqview ~/lufs/camera/pics
When gqview asked for that dir, lufs-automount would mount the camera filesystem first, and unmount it when done. ~/lufs would be mounted on login.
I think technically, I'd rather see LUFS add this caching and do better. I really think SSH isn't something that should be in the kernel, and it isn't really necessary for performance reasons.
I was getting a ton of linking errors; it seems the makefile was using cc to link wastesrv. I added CC=g++ to Makefile, and it worked. Mandrake 9.1 and GCC 3.2 don't like using cc to link C++ stuff. It compiles now, though I have yet to try it. Thanks.
I couldn't agree more. It would be interesting to take two large, totally unrelated OSS projects and analyze their code. Is there some way to compare code so that identifier names are irrelevant, but everything else counts? (machine code or parse trees might do the trick.) There are only so many meaningful algorithms. Even more so when written for a specific purpose.
I would hope that any judge would be sane enough to only ban distribution of contested code after telling everyone what code that is! How can you not distribute it until you know what not to distribute? And yes, as SCO has said, the code would be instantly rewritten. Which SCO shouldn't care about, unless their motive is to screw Linux, not to protect their IP.
If it's possible to copy it, it will find it's way onto P2P networks, and then however difficult it was won't matter, it will be as easy as P2P. So if the cost (money, time, bandwidth, risk, morality) of P2P is lower, people will use it. To use your analogy, if the first one with wire-cutters throws all the valuables onto the street, the fence doesn't matter.
P2P is inconvienent and immoral enough that it should be possible for record companies to compete with it and win. But in order to do this, they must realize that if they make their service inconvenient enough, people will use P2P, and they gain nothing. People won't buy music, try to copy it, fail, and then suddenly change their view as to whether they should copy it. They'll just try harder or go P2P.
In practice, iTunes is pretty close, but it's barriers are still a bit too high for me. As everyone tells me when I complain about iTunes, it's DRM is so neutered it's almost not there. I just hope iTunes will get the RIAA over it's mind-block that it needs to be there in the first place.
Seriously, as much as you'd like a totally unencumbered, perfect digital reproduction for a cheap price, that is not going to happen. Apple's deal is the most reasonable thing yet, and their sales numbers show that. They managed to get a system that is easy *enough*, cheap *enough*, user-friendly *enough* that people like it, while it is DRM'd *enough* for the record companies to deal with.
I'm being optimistic here: if they cut out the DRM, it would be even more easy and user-friendly, and they'd hit a wider audience (me, phear_the_penguin, et al).
If the DRM isn't perfect (and it never is), the music will appear on P2P, and once it does, you don't even have to bypass it. So you don't gain anything by doing DRM half-fast, except curtailing fair use. Since iTunes has shown that the RIAA doesn't have that big a problem with fair use, and even sharing CDs with realspace friends, I'm hopeful someone will convince them to drop DRM and just sell people cheap files and trust them.
Slashdot Mirror
Has there ever been a format that hasn't been quickly cracked and put on P2P? That it will appear on P2P isn't a good reason to use DRM, because it will anyway. Hint: fair use == less money, thus DRM.
And I'm not entirely sure that LAME is illegal in the US, but it wouldn't surprise me, and it's enough to make me use Vorbis, even if it means re-encoding when I get a portable player. (There will be portable Vorbis players soon, though.)
CDex uses LAME. LAME's site links here . The answer seems to be a big fat maybe. Also, try here, and click on News. Notice BladeEnc was discontinued for reasons including legal hassles. Also, note that RedHat wussed out and pulled MP3 support from RedHat Linux 8.
Did you ever notice that all legal MP3 encoders in the US are adware?
It really is just using the best tool. For the purely textual parts of notes, typing is faster by far, and the result is notes you can search. For math or diagrams, use paper.
I guess what we need is for all, not just most, lawyers to know when to say "No, that's stupid." If a client says "Hmm, I have this patent, lets sue eBay," all the lawyers must say "No, the patent is stupid and it's an abuse of the system." If your client says "Hmm, we kinda have this IP, lets sue IBM over Linux," all the lawyers must say "No, we may not have the IP, it didn't help Linux, the whole thing's a lie, and besides, you'll turn the entire industry against yourself." Granted most lawyers would say that, but they all should.
Devices have space for the major and minor numbers, but many "devices" which aren't controlled by the character device layer look like regular files. (Everything in /proc). I don't think that being a file has a guarantee of seekability, efficent concurrent access, etc.
The implementation would be: when the directory is searched, scan the TOC to get length info. Just estimate for the Ogg files. When a file is opened, spawn a pipeline with cdparanoia and any encoders, and on each read, get the data from that pipeline. On seek in a wav file, restart cdparanoia with a different range. For everything else, return an error.
Frankly, making everything a file is just plain cool, as well as being part of the unix philosophy. If you think audio CDs are bad for files, check out /dev and /proc! Your mouse is a file! None of the character devices support seeking, truncating, or locking; they're more similar to pipes or sockets (also files).
Digital camera browsing, however, should at least be LUFS. My camera uses compactflash cards that you can just mount, and IHMO that's the best interface. Treat the camera like a drive, because stored pictures and configuration fit perfectly with the file paradigm.
AFAIK, LUFS doesn't support protocol in the path, but it should be simple to write a LUFS module that does just that, mounting other LUFS modules. This could make it very useful.
Mapping most urls to files isn't a great solution, but neither is mapping files to urls. How do you get a directory listing? How do you change permissions? Consider FTP: do you make a new connection for each URL, or do you keep the connection open for a while in hopes of getting another? Mounting makes sense when there's overhead in establishing a connection, be it parsing a filesystem or making a remote connection.
I guess what I'm saying is that a URL library (IOSlaves and gnome-vfs) is nice to have, and a file system (LUFS, FUSE) is nice, but they shouldn't be one and the same. The URL library can be used for browsers, downloaders, etc, but the filesystem and only the filesystem should be used for naive tools that want to run on a local filesystem.
LUFS or FUSE would be the module you're talking about, which allows you to do filesystems in userspace, and can let users mount them. So Linux can do all three: kernel modules for lean, fast, "real" filesystems, LUFS or FUSE for "exotic" filesystems that shouldn't be in the kernel, and kioslaves and gnome-vfs for those who like reinventing the wheel and want to further bloat their favorite GUI library.
With LUFS, once its module is in, you don't need any other modules, and the user can mount his own filesystems if he has permission to do so. Support is even more uinversal, because the app doesn't need to be KDE or GNOME, it doesn't even need to be dynamically linked (like it would for LD_PRELOAD hacks), absolutely anything can use it. LUFS has 1, 2, and 4 (Gnutellanet, even). I think 3 can be fixed with automount or similar (see my other post). It would be possible to do xmms ~/lufs/gnutella/*/*.
What you need is a very small, simple, well-written SUID process to do the mounting. You'd need to check permissions on the directory you mount. You'd want to be able to configure where a user can mount stuff. This has been done, look at smbmount and smbumount.
Then, as you say, the kernel module part of LUFS needs to be very careful, protecting the kernel from overly huge directory structures, malformed calls, indefinite blocking, etc.
It's difficult, but it can be done.
Besides, cce's right. The guy who wrote FTPFS now wants everyone to use his more general project, LUFS, which allows you to mount FTP, SSH, and even Gnutella filesystems. IMHO, something that makes a nice interface to bring exotic filesystems out of the kernel, allowing for a much more modular design, is much better than a single purpose kernel filesystem that needs to be insmod'ed and bloats the kernel.
I think the same thing could be done with LUFS, though. Using either automount or a specifically designed LUFS filesystem, make a filesystem where references to a protocol name would cause it to be mounted. For example,
When gqview asked for that dir, lufs-automount would mount the camera filesystem first, and unmount it when done. ~/lufs would be mounted on login.I think technically, I'd rather see LUFS add this caching and do better. I really think SSH isn't something that should be in the kernel, and it isn't really necessary for performance reasons.
I was getting a ton of linking errors; it seems the makefile was using cc to link wastesrv. I added CC=g++ to Makefile, and it worked. Mandrake 9.1 and GCC 3.2 don't like using cc to link C++ stuff. It compiles now, though I have yet to try it. Thanks.
There already is one (though it doesn't cleanly compile for me). http://www.northarc.com/waste_web/
I couldn't agree more. It would be interesting to take two large, totally unrelated OSS projects and analyze their code. Is there some way to compare code so that identifier names are irrelevant, but everything else counts? (machine code or parse trees might do the trick.) There are only so many meaningful algorithms. Even more so when written for a specific purpose.
I would hope that any judge would be sane enough to only ban distribution of contested code after telling everyone what code that is! How can you not distribute it until you know what not to distribute? And yes, as SCO has said, the code would be instantly rewritten. Which SCO shouldn't care about, unless their motive is to screw Linux, not to protect their IP.
I'm just curious: How forthcoming was AT&T with the infringing code? How al-Sahaf-esque was it's press releases? What was the media coverage like?
That's against both K&R's and Linus's styles. SCO can keep it. Functions are the only blocks whose brackets start on the next line.
P2P is inconvienent and immoral enough that it should be possible for record companies to compete with it and win. But in order to do this, they must realize that if they make their service inconvenient enough, people will use P2P, and they gain nothing. People won't buy music, try to copy it, fail, and then suddenly change their view as to whether they should copy it. They'll just try harder or go P2P.
In practice, iTunes is pretty close, but it's barriers are still a bit too high for me. As everyone tells me when I complain about iTunes, it's DRM is so neutered it's almost not there. I just hope iTunes will get the RIAA over it's mind-block that it needs to be there in the first place.
I'm being optimistic here: if they cut out the DRM, it would be even more easy and user-friendly, and they'd hit a wider audience (me, phear_the_penguin, et al).
If the DRM isn't perfect (and it never is), the music will appear on P2P, and once it does, you don't even have to bypass it. So you don't gain anything by doing DRM half-fast, except curtailing fair use. Since iTunes has shown that the RIAA doesn't have that big a problem with fair use, and even sharing CDs with realspace friends, I'm hopeful someone will convince them to drop DRM and just sell people cheap files and trust them.