The RIAA should start a suit against Micro$soft, sun, etc as well. They're distributing software like IIS and ftpd that allows users to easily download copyright protected content from a machine. Combined with Altavista, who should also be sued for providing an easily searchable index of illicit material, these products make it too easy to distribute and exchange copyrighted materials.
The whole problem is that in the past few years the bandwidth available to universities has been increasing rapidly. Internet2 has spurred this to an all time high. However, since the standard pricing model is based on the bandwidth used these same universities are now throwing up their hands saying "We can't pay for what we have". There are really only a few options to universities that are having their bandwidth consumed by it's users:
Block sites that require heavy bandwidth, as has been done recently by universities dealing with napster, ipad, etc.
Continue to pay the bills regardless of what is used and proclaim that students (and staff!) should have absolute freedom. Most likely this will result in higher tuition charges to cover the cost.
Start charging each student on a per byte basis for the bandwidth they use.
I'm betting that #3 will win in the long run. It's the only fair solution when you break it down, as it charges the people that use it. As unfair as it seems to the people that want to use the most bandwidth, it simply puts the charges on the people that use it. Option #2 is certainly the way it should be, but if the cost is spread out to the students that aren't making use of it then its not really fair to them. What we need is free bandwidth, and since that'll never happen we're stuck with charging someone. The only sensible solution is to charge the people that are using the bandwidth. However, the biggest problem with this is that universities are not set up to handle this kind of recharge service. There is a whole new wave of infrastructure that is required to put a per-byte pricing model in place, and it doesn't exist in most places yet. Until it does, I'm sure more and ore universities will be implementing #1 since their budgets just aren't prepared for the bills their getting charged with.
I think RPM is a good thing from an end-users point of view. It allows easy installations and upgrades to packages without much work on their part. It's a good model for the desktop.
It fails in other ways though:
building an rpm distribution is a pain in the neck.
There is now multi-host integrated db management system.
Appending to your own rpm database is equally as much of a pain.
Problem 1 stems from the.spec file. It's a pain to learn, understand, and create one. Anything that requires copying a template, modifying and preying while you test it is a bad design. What is needed is a build system on top of it.
Problem 2 is a big issue for people managing huge sets of machines. How do you remember which machines have which packages installed on them? Sure "for i in box1, box2..." type solutions can do this but it's a pain in the neck. What I want is a DB that can handle remote queries (actually, I have the beginnings of this worked out via SNMP queries but...) and can list for me the machines with differences from the rest, packages that are on every system, systems that are missing package X, etc. And, of course, you should be able to say "with respect to architecture Y" for any of these queries.
Problem 3: Not everything comes in RPM or any other distribution package format. You need something that allows you to automatically append to the DB the files that you're building and installing.
Actually, I wrote a small utility a few years ago to handle problems 2 and 3. Basically, you keep an INSTALL variable set in your environment so configure uses that by default and it points to a hacked version of an bsd install script. Then, you run configure, make and make install just like you normally would and the INSTALL script automatically updates a database saying you installed all these files attached to a package with a version number. Hmm... I think I even have a sample output somewhere:
I set it up for a common disk path (eg,/afs), so it doesn't handle DBs on different machines. It assumes if you install it in one place, everyone can access it.
The nice thing about it is that it is easy to use... "sdb -setup XXX 0.0.9;./configure; make; make install" and it automatically updates everything.
However, it needs to be re-done to handle the multiple hosts without a common file system though.
(hmm... the chart should be properly spaced... HTML is slamming it without pre tags, which isn't allowd by slashdot)
Here are my notes from the meeting, in all their unedited (mostly) glory, for any that care. The meeting and the comments were longer than these notes indicate, but hey, I was writing some DES cracking software at the time and was distracted.
Wire tapping:
Should the IETF support protocol features whose use is specific to wiretapping? (*)
IP Telephony? (IETF WG: magaco)
Traditional voice networks tend to support wiretapping.
The internet has traditionally not.
Hence the question above. (*)
The RAVEN list: mailing list setup for this matter.
Established in october.
453 people on the mailing list. (51 people talked)
253? messages since then
Comments from people in favor of it:
The IETF can ensure it is auditable.
We have to do it, so lets do it in the IETF.
Comments from opponents:
Over my dead body.
Violates my rights as a human being.
Weakens security.
(Selected) Comments from the crowd at the meeting:
The request is for legal tapping, which has no context in a global international environment.
The work is going to get done anyway, as the commercial vendors that don't want to pay the penalty for not doing it will have to implement a different protocol or a hacked version of the protocol.
Complex systems are less secure, so putting in wire-tapping will make it less secure.
You don't need to decrypt what you tap. You only have to give the encrypted text to the government agency requesting it, so lets build end to end encryption into everything we do.
Interesting idea (putting in a fake function of the same name), but somehow I don't think it would fly in court very well...
Thats the really annoying thing: Why do they not even allow function calls to be put in place where the encryption would be done? That seems outragiously silly to me...
Well, thats certainly what a lot of other sites seem to be doing... Most of them have a simple form to fill out before you can download it, but I don't know 1) if they log that inforamation (IP address and answers) and 2) if they additionally look up the CIDR block to determine where its really coming from (since I'm in the US, I'm not sure if you can still get to the page from outside the US).
The software is mirrored in a few places already outside the US.
I think you have do to a bit more than just "whack it up with a disclaimer".
The ucd-snmp package can produce the information you're looking for. Someone else has already mentioned mrtg, etc, which can be used to create graphs of the data that you want to collect from the ucd-snmp snmp agent...
Slashdot Mirror
Hmm... my hands could be tools of thievery too.
The RIAA should start a suit against Micro$soft, sun, etc as well. They're distributing software like IIS and ftpd that allows users to easily download copyright protected content from a machine. Combined with Altavista, who should also be sued for providing an easily searchable index of illicit material, these products make it too easy to distribute and exchange copyrighted materials.
- Block sites that require heavy bandwidth, as has been done recently by universities dealing with napster, ipad, etc.
- Continue to pay the bills regardless of what is used and proclaim that students (and staff!) should have absolute freedom. Most likely this will result in higher tuition charges to cover the cost.
- Start charging each student on a per byte basis for the bandwidth they use.
I'm betting that #3 will win in the long run. It's the only fair solution when you break it down, as it charges the people that use it. As unfair as it seems to the people that want to use the most bandwidth, it simply puts the charges on the people that use it. Option #2 is certainly the way it should be, but if the cost is spread out to the students that aren't making use of it then its not really fair to them. What we need is free bandwidth, and since that'll never happen we're stuck with charging someone. The only sensible solution is to charge the people that are using the bandwidth. However, the biggest problem with this is that universities are not set up to handle this kind of recharge service. There is a whole new wave of infrastructure that is required to put a per-byte pricing model in place, and it doesn't exist in most places yet. Until it does, I'm sure more and ore universities will be implementing #1 since their budgets just aren't prepared for the bills their getting charged with.I think RPM is a good thing from an end-users point of view. It allows easy installations and upgrades to packages without much work on their part. It's a good model for the desktop.
It fails in other ways though:
Problem 1 stems from the
Problem 2 is a big issue for people managing huge sets of machines. How do you remember which machines have which packages installed on them? Sure "for i in box1, box2..." type solutions can do this but it's a pain in the neck. What I want is a DB that can handle remote queries (actually, I have the beginnings of this worked out via SNMP queries but...) and can list for me the machines with differences from the rest, packages that are on every system, systems that are missing package X, etc. And, of course, you should be able to say "with respect to architecture Y" for any of these queries.
Problem 3: Not everything comes in RPM or any other distribution package format. You need something that allows you to automatically append to the DB the files that you're building and installing.
Actually, I wrote a small utility a few years ago to handle problems 2 and 3. Basically, you keep an INSTALL variable set in your environment so configure uses that by default and it points to a hacked version of an bsd install script. Then, you run configure, make and make install just like you normally would and the INSTALL script automatically updates a database saying you installed all these files attached to a package with a version number. Hmm... I think I even have a sample output somewhere:
% sdb -h
usage:
sdb -add PKG VERSION FILE...
sdb -chart [PKG [ARCH]]
sdb -list [PKG [ARCH]]
sdb -report
sdb -compact [-verbose] [-check]
sdb [-cset|-sset]
sdb -setup [-arch] PKG VERSION
sdb -remove [PKG] [VERSION] [FILE]
% sdb -chart
package Linux_2 SunOS_5 HP_UX_B_10
x11.xscreensaver 3.10
gnu.cvs 1.10
x11.libjpeg 6b
contrib.pgp 50i 50i
ucd-snmp 3.5.1
gnu.patch 2.5 2.5
gnu.fileutils 3.16 3.16, 4.0
gnu.groff 1.11
contrib.ssh 1.2.26 1.2.26
flex 2.5.4
I set it up for a common disk path (eg,
The nice thing about it is that it is easy to use... "sdb -setup XXX 0.0.9;
However, it needs to be re-done to handle the multiple hosts without a common file system though.
(hmm... the chart should be properly spaced... HTML is slamming it without pre tags, which isn't allowd by slashdot)
fish!
Wire tapping:
IP Telephony? (IETF WG: magaco)
- Traditional voice networks tend to support wiretapping.
- The internet has traditionally not.
- Hence the question above. (*)
The RAVEN list: mailing list setup for this matter.- Established in october.
- 453 people on the mailing list. (51 people talked)
- 253? messages since then
Comments from people in favor of it:- The IETF can ensure it is auditable.
- We have to do it, so lets do it in the IETF.
Comments from opponents:- Over my dead body.
- Violates my rights as a human being.
- Weakens security.
(Selected) Comments from the crowd at the meeting:Thats the really annoying thing: Why do they not even allow function calls to be put in place where the encryption would be done? That seems outragiously silly to me...
Well, thats certainly what a lot of other sites seem to be doing... Most of them have a simple form to fill out before you can download it, but I don't know 1) if they log that inforamation (IP address and answers) and 2) if they additionally look up the CIDR block to determine where its really coming from (since I'm in the US, I'm not sure if you can still get to the page from outside the US).
The software is mirrored in a few places already outside the US.
I think you have do to a bit more than just "whack it up with a disclaimer".
The ucd-snmp package can produce the information you're looking for. Someone else has already mentioned mrtg, etc, which can be used to create graphs of the data that you want to collect from the ucd-snmp snmp agent...