Putting more applications into kernel mode is a step along the transitional path to a microkernel architecture. If things like that get popular, then Linux will evolve means to guard them from the rest of the kernel, fairly allocate resources between them, etc.
(One path development might take is to do less checking during each context switch, and more earlier on, when the application was first loaded. If a degree of trust can be statically verified, the app can be safely permitted to run with full kernel privs. This gets into HP of course.)
To play with the concept, here's a toolkit which allows any program to be added to the kernel.
If you take the time to hunt patents before you use an idea, you run the risk of delaying the publication of an idea long enough for someone else to patent it.
If that's any kind of concern for you- if you've got a good idea, and are afraid someone else might patent it in the near future- then hurry up and publish immediately, before you even manage to write a functioning program that uses it.
Post it on Slashdot (Off-topic). Spam to USENET (alt.sources ?) Do something to get a public record of the time you were aware of the idea. Just get it onto the internet in a place where third parties (Google's dejanews service) can, if needed, verify the time/date of your posting.
illegally obtained evidences are inadmissible in court
Illegally obtained evidence can be used in US court. Sometimes. On a case-by-case basis, up to the presiding judge.
If the illegal actions were done by police, prosecutors, or other government types, then the rule is very strict that the evidence is thrown out (as is anything else found based on that evidence- the "poisoned tree" rule).
But if private citizens break the law to obtain evidence, the judge can allow it. (If the citizen seemed to have been encouraged by police, then he'd be a kind of "government agent", and should be excluded. But discretion applies)
Prehaps that's an interpretation that has recently been applied to the UK. It must be fairly new, though. Since at least the 1600s, English Common Law has included the principle "Ignorant facti excusat, ignorantia juris neminem excurat.". Ignorance of fact is an excuse; ignorance of law is not
The US, from 1776, maintained that same principle. Citizens are not liable for actions performed prior to a law's passage, but a law's effectiveness is global, regardless of who's heard about it yet.
Fragmentation, the basis of your wild assertion, has nothing to do with overall capacity.
From a theory perspective, total capacity does have something to do with fragmentation.
Assuming both drives are using the same intelligently designed filesystem (meaning it makes some effort to avoid fragmenting), and that the user creates and edits files in the same order, a smaller disk will suffer fragmentation before a larger one does.
If a one gig disk has two files on it, A and B, and then file A is appended to be 501 megabytes in size, it will probably be fragmented. On a 10 gig drive, it may still be contiguously stored, just from natural writing.
i was playing with one of those little keychain usb drive things.
Those drives work just fine with all recent Linux distributions. Stick one into a RedHat9 machine, for example, and a window with the drive contents pops onto your screen automatically.
they want to be able to buy a cheap ass webcam and have it work
It's true that camera vendors often avoid using standard interfaces for no good reason except to be different. However, I've purchased webcams for as little as $9 (still in the original packaging) and had them work in Linux just fine.
The only way I can think of that mattering is if it causes you to have less swap space.
Here's another possibility: Because the data on the drive had to be compressed to fit.
This is a common tactic for Linux distributions that want to stuff in a big assortment of desktop programs. (On the assumption that their users will be unable manage installing anything later, so they need all file-handlers present initially)
The Knoppix live-cd is the most famous user of this technique. Knoppix provides KDE, OpenOffice.org, Mozilla, Gimp, and other large programs, but it reads them from a compressed archive that further degrades the already low read-speed of a CDROM.
If the CPU is slow, like on these cheap PCs, then loading compressed files is an even bigger drag.
Why would someone who has a $200 computer be buying a $100 digital camera?...
At Walmart, you can buy a 2.1 megapixel digital camera for $25. It takes SmartMedia cards for storage, a rapidly obseleting format that is still widely available. You can grab 32meg SM cards for $10 each.
To get those pictures onto a Lindows PC, the safest bet would be a $14 USB-SmartMedia adapter, also sold at Walmart.
That makes it sound really like a problem in the application (MPlayer or xine) itself, then. Not something related to your kernel or sound drivers.
It's as if, when the window is being dragged, the program doesn't bother updating the audio output buffers.
However, I tried Mplayer myself, and it continues to play sound during a move or resize. You might try adjusting your window manager properties (in KDE or Gnome control center, for example) to change the effect used when moving a window. Try toggling things like "display content in moving windows" on, and stuff involving "translucency" off.
Yes, but the guy I responded to does have broadband, and he was downloading ~4550 MB of software.
If you want Debian, and have broadband, then a netinst is almost always best. If you don't have broadband, then ask (or pay) someone for a copy of the CDs. Downloading the CDs gives you the worst of both worlds.
(People with a packrat tendency, and many blank CDRs, are free to expand their collections if that's what makes them happy. Just don't expect to ever use half those discs.)
Re:You can see the code too !
on
Settling SCOres
·
· Score: 1
Unless this person used illegal means to get access to that information, it is the responsibility of the company to protect their trade secrets.
US trade secret law is the same.
Re:Linus' stuff?
on
Settling SCOres
·
· Score: 5, Interesting
Since a process scheduler is such a well studied piece of Computer Science theory, it might be that the code in both Linux and SCO's Unix is derived from the same published, academic source.
Something like an example from an Operating Systems 101 textbook... The natural starting place to write something like that. Both author's could've tossed in explanation from the same original source matter.
Also, the scheduler is part of what makes Unix what it is- a multitasking, process-switched operating system. If several people want to implement that feature, they'll all have a very similar thought pattern, and converge towards a similar solution.
What's wasteful is network installing debian on multiple machines when you could save bandwidth (and some of us are bandwidth limited or metered) and download a few.iso's and be done with it.
If you want to save bandwidth, you can download a single ISO of Debian's desktop packages and stick with that. The highly popular Knoppix CD, for example.
Anyone willing to download seven ISOs of stuff he'll probably never even look at obviously has little concern for conservation of bandwidth.
Most of the benefits that make Debian unique and valuable come from its network installability. If you don't intend to take advantage of that feature, you've got little reason to use Debian at all. (Unless you were already very familiar with Debian, but then you'd know how to assemble a custom install CD without grabbing a ton of ISOs)
You're making me think I'm not going to like the installer
That's a common opinion, although it somewhat depends on what you mean by "installer". The installer that initially prepares your hard drive is quite servicable (in terms of partitioning, bootloaders, etc), although not as pretty as a recent RedHat or Mandrake offering.
However, once that setup is over, you're left with some bad options to add further packages. There is dselect, which is full-featured and informative but painfully convoluted to use. And there is apt-get, whose minimal CLI is adequate for those who can handle it, but unhelpful for newbies. An assortment of "Graphical APT frontends" have come and gone over the years, but they never manage to survive very long ("aptitude", etc).
Unfortunately, up2date doesn't grab programs that weren't in the distrobution.:(
In general, Debian's apt system doesn't support that either. But their larger number of packages in "the distribution" makes that less problematic. Since most users never attempt to burn a full set of discs, they have little pressure to save space by dropping packages.
If a 3rd party developer supports it, she can provide an apt.config line to add HTTP access to auxilliary deb files via your normal apt-get routine.
So I doubt that being two separate companies would do much for innovation, especially since each would still have the lion's share of its respective market.
If Microsoft were split up like that, there's a freakish-sounding scenario that actually becomes highly probable:
The application-half will try to get back into the OS market as quickly as possible, and will soon release a "Microsoft Office" CD that optionally installs a bootable image to your hard drive. How will they leapfrog over the year of time it takes to write a reliable OS? Build it on Linux, of course!
This is reasonable, because if the companies are truely split up, then they'll have no reason not to undermine the other's monopoly position. The backstabbing will be relentless. And with Linux out there, an OS is much closer to a free commodity than Office Suites are (since OpenOffice is still a marginal competitor). So it will be the Office half, not the Windows half, that will be victorious.
If you weren't Anonymous, then I'd have some expectation you'd read a reply, and thus I'd have some motivation to reply at length. I could point out specific 20th century Supreme Court cases where shrinkwrap licensing was specificially prohibited.
I could mention that in a software store, you neither "purchase software" nor "license software"- you "buy a copy of software", which has a specific legal meaning, identical to buying music or a book.
including the part where you are agreeing to license the software when you open the shrinkwrap.
I could also demolish that claim, but won't waste my time on something you won't read. Similar answers to mine are easy to find on the WWW, if you care. Some even WBAL.
A look at the history of DeCSS contradicts that statement. When a program called DeCSS was first released, it ran on Microsoft(tm) Windows(r), and served to strip the copy-restriction from a DVD that had been copied to hard disk.
The original DeCSS only enabled "DVD playing on Linux" insofar as you could convert the DVD to AVI on Windows, and then transfer the file to a Linux box.
Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.
Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.
You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.
I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.
RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.
The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.
Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.
I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.
I did noticed dragging video windows (e.g., MPlayer) and my SB Live! (emu10k1 driver from opensource.creative.com) stop playing audio until I let go of the mouse button.
That seems like something wrong with MPlayer itself, not the sound driver or kernel. Assuming the audio is coming from the videofile, MPlayer might stop updating the output stream until the window drag is complete.
(Or, do you mean sounds from other applications stop as well when MPlayer is dragged?)
In the past, putting all the targets on one make invocation could fail mysteriously. I never tracked the problem to it's source (the workaround is easy enough), although presumably it involved the makefiles created in the "dep" stage not being read in time for the other targets to see them. (This might be dependent on the version of "make" you have)
Why would anyone download multiple Debian CDs before installing? That just doesn't make sense. The most you should download is a 150 meg bootable CDROM image, then let the rest of the packages you want come over HTTP when you choose to install them.
Debian prides itself on an enormous amount of packages... nearly twice as many, counting bytes, as RedHat provides. To attempt to download "a copy of Debian" is wrong and wasteful. The fun of Debian comes in when you decide, on the spur of the moment, to try some exotic free software program and can apt-get it in a much less time that it would take to even figure out the name of the RPM you'd need to install on a "normal" Linux system.
Even if the desired install computer doesn't have fast internet access, burning 7 CDs is excessive. There probabably won't even be 2 CDs worth of packages you really want to install. Of the top ten largest packages in Debian, six of them are only desirable for hardcore software developers.
Re:The article misses a few things as well.
on
Sun's Last Stand
·
· Score: 1
And what, pray tell, is the bit of law that stops you from running a server on your cable modem?
It's a big stretch, but one could argue that consumer protection laws, if properly enforced, would allow him to run a server on a cable modem.
The argument would go like this
The company advertised and promised me "Internet Access". Internet Access, as defined by the IETF, is the ability to send or recieve TCP or UDP packets on any valid port. By imposing a restriction on the nature and content of the packets I can transmit, they have violated the promise made that I would have "Internet Access". Not only is this false advertising, it also voids the "common carrier" status that protects them from liability for my actions.
It doesn't make sense for cable operators to allocate enough RF channels to the upstream to make it a kick-ass cheap serving pipe.
It doesn't make sense for them to allocate enough upstream for users to constantly send big files. But you can transmit huge data chunks without running a server. I could repeatedly upload Linux ISOs to a public FTP, 24 hours a day. More realistically, I could run a stream live video of my dorm room into a single remote site. Or just look at all the Kazaa users, which are ISPs single biggest headache today (although Kazaa is arguably a server, I don't see why ISPs haven't explicitly forbidden it from their TOS)
If ISPs want to prohibit (or just rate-limit) large outbound connections, fine. Then prohibit "large outbound connections"- not "servers". Running a server is neither a necessary nor sufficient condition for using an unfair amount of bandwidth.
Slashdot Mirror
Putting more applications into kernel mode is a step along the transitional path to a microkernel architecture. If things like that get popular, then Linux will evolve means to guard them from the rest of the kernel, fairly allocate resources between them, etc.
(One path development might take is to do less checking during each context switch, and more earlier on, when the application was first loaded. If a degree of trust can be statically verified, the app can be safely permitted to run with full kernel privs. This gets into HP of course.)
To play with the concept, here's a toolkit which allows any program to be added to the kernel.
via RedHat 9 and the multiple XFree86 hack
How does that work? This approach? Or is there a better way to attach individual USB keyboards to separate X servers?
Don't wait to "implement". Publish first.
If you take the time to hunt patents before you use an idea, you run the risk of delaying the publication of an idea long enough for someone else to patent it.
If that's any kind of concern for you- if you've got a good idea, and are afraid someone else might patent it in the near future- then hurry up and publish immediately, before you even manage to write a functioning program that uses it.
Post it on Slashdot (Off-topic). Spam to USENET (alt.sources ?) Do something to get a public record of the time you were aware of the idea. Just get it onto the internet in a place where third parties (Google's dejanews service) can, if needed, verify the time/date of your posting.
illegally obtained evidences are inadmissible in court
Illegally obtained evidence can be used in US court. Sometimes. On a case-by-case basis, up to the presiding judge.
If the illegal actions were done by police, prosecutors, or other government types, then the rule is very strict that the evidence is thrown out (as is anything else found based on that evidence- the "poisoned tree" rule).
But if private citizens break the law to obtain evidence, the judge can allow it. (If the citizen seemed to have been encouraged by police, then he'd be a kind of "government agent", and should be excluded. But discretion applies)
Prehaps that's an interpretation that has recently been applied to the UK. It must be fairly new, though. Since at least the 1600s, English Common Law has included the principle "Ignorant facti excusat, ignorantia juris neminem excurat.". Ignorance of fact is an excuse; ignorance of law is not
The US, from 1776, maintained that same principle. Citizens are not liable for actions performed prior to a law's passage, but a law's effectiveness is global, regardless of who's heard about it yet.
Fragmentation, the basis of your wild assertion, has nothing to do with overall capacity.
From a theory perspective, total capacity does have something to do with fragmentation.
Assuming both drives are using the same intelligently designed filesystem (meaning it makes some effort to avoid fragmenting), and that the user creates and edits files in the same order, a smaller disk will suffer fragmentation before a larger one does.
If a one gig disk has two files on it, A and B, and then file A is appended to be 501 megabytes in size, it will probably be fragmented. On a 10 gig drive, it may still be contiguously stored, just from natural writing.
i was playing with one of those little keychain usb drive things.
Those drives work just fine with all recent Linux distributions. Stick one into a RedHat9 machine, for example, and a window with the drive contents pops onto your screen automatically.
they want to be able to buy a cheap ass webcam and have it work
It's true that camera vendors often avoid using standard interfaces for no good reason except to be different. However, I've purchased webcams for as little as $9 (still in the original packaging) and had them work in Linux just fine.
The only way I can think of that mattering is if it causes you to have less swap space.
Here's another possibility: Because the data on the drive had to be compressed to fit.
This is a common tactic for Linux distributions that want to stuff in a big assortment of desktop programs. (On the assumption that their users will be unable manage installing anything later, so they need all file-handlers present initially)
The Knoppix live-cd is the most famous user of this technique. Knoppix provides KDE, OpenOffice.org, Mozilla, Gimp, and other large programs, but it reads them from a compressed archive that further degrades the already low read-speed of a CDROM.
If the CPU is slow, like on these cheap PCs, then loading compressed files is an even bigger drag.
Why would someone who has a $200 computer be buying a $100 digital camera? ...
At Walmart, you can buy a 2.1 megapixel digital camera for $25. It takes SmartMedia cards for storage, a rapidly obseleting format that is still widely available. You can grab 32meg SM cards for $10 each.
To get those pictures onto a Lindows PC, the safest bet would be a $14 USB-SmartMedia adapter, also sold at Walmart.
"A Package Tool" is an acronym too. But it lacks the complex texture of a nested acronym.
That makes it sound really like a problem in the application (MPlayer or xine) itself, then. Not something related to your kernel or sound drivers.
It's as if, when the window is being dragged, the program doesn't bother updating the audio output buffers.
However, I tried Mplayer myself, and it continues to play sound during a move or resize. You might try adjusting your window manager properties (in KDE or Gnome control center, for example) to change the effect used when moving a window. Try toggling things like "display content in moving windows" on, and stuff involving "translucency" off.
Yes, but the guy I responded to does have broadband, and he was downloading ~4550 MB of software.
If you want Debian, and have broadband, then a netinst is almost always best. If you don't have broadband, then ask (or pay) someone for a copy of the CDs. Downloading the CDs gives you the worst of both worlds.
(People with a packrat tendency, and many blank CDRs, are free to expand their collections if that's what makes them happy. Just don't expect to ever use half those discs.)
Unless this person used illegal means to get access to that information, it is the responsibility of the company to protect their trade secrets.
US trade secret law is the same.
Since a process scheduler is such a well studied piece of Computer Science theory, it might be that the code in both Linux and SCO's Unix is derived from the same published, academic source.
Something like an example from an Operating Systems 101 textbook... The natural starting place to write something like that. Both author's could've tossed in explanation from the same original source matter.
Also, the scheduler is part of what makes Unix what it is- a multitasking, process-switched operating system. If several people want to implement that feature, they'll all have a very similar thought pattern, and converge towards a similar solution.
What's wasteful is network installing debian on multiple machines when you could save bandwidth (and some of us are bandwidth limited or metered) and download a few .iso's and be done with it.
If you want to save bandwidth, you can download a single ISO of Debian's desktop packages and stick with that. The highly popular Knoppix CD, for example.
Anyone willing to download seven ISOs of stuff he'll probably never even look at obviously has little concern for conservation of bandwidth.
Most of the benefits that make Debian unique and valuable come from its network installability. If you don't intend to take advantage of that feature, you've got little reason to use Debian at all. (Unless you were already very familiar with Debian, but then you'd know how to assemble a custom install CD without grabbing a ton of ISOs)
You're making me think I'm not going to like the installer
:(
That's a common opinion, although it somewhat depends on what you mean by "installer". The installer that initially prepares your hard drive is quite servicable (in terms of partitioning, bootloaders, etc), although not as pretty as a recent RedHat or Mandrake offering.
However, once that setup is over, you're left with some bad options to add further packages. There is dselect, which is full-featured and informative but painfully convoluted to use. And there is apt-get, whose minimal CLI is adequate for those who can handle it, but unhelpful for newbies. An assortment of "Graphical APT frontends" have come and gone over the years, but they never manage to survive very long ("aptitude", etc).
Unfortunately, up2date doesn't grab programs that weren't in the distrobution.
In general, Debian's apt system doesn't support that either. But their larger number of packages in "the distribution" makes that less problematic. Since most users never attempt to burn a full set of discs, they have little pressure to save space by dropping packages.
If a 3rd party developer supports it, she can provide an apt.config line to add HTTP access to auxilliary deb files via your normal apt-get routine.
So I doubt that being two separate companies would do much for innovation, especially since each would still have the lion's share of its respective market.
If Microsoft were split up like that, there's a freakish-sounding scenario that actually becomes highly probable:
The application-half will try to get back into the OS market as quickly as possible, and will soon release a "Microsoft Office" CD that optionally installs a bootable image to your hard drive. How will they leapfrog over the year of time it takes to write a reliable OS? Build it on Linux, of course!
This is reasonable, because if the companies are truely split up, then they'll have no reason not to undermine the other's monopoly position. The backstabbing will be relentless. And with Linux out there, an OS is much closer to a free commodity than Office Suites are (since OpenOffice is still a marginal competitor). So it will be the Office half, not the Windows half, that will be victorious.
If you weren't Anonymous, then I'd have some expectation you'd read a reply, and thus I'd have some motivation to reply at length. I could point out specific 20th century Supreme Court cases where shrinkwrap licensing was specificially prohibited.
I could mention that in a software store, you neither "purchase software" nor "license software"- you "buy a copy of software", which has a specific legal meaning, identical to buying music or a book.
including the part where you are agreeing to license the software when you open the shrinkwrap.
I could also demolish that claim, but won't waste my time on something you won't read. Similar answers to mine are easy to find on the WWW, if you care. Some even WBAL.
But, if you drag MPlayer around, does the audio stream from XMMS get interrupted too? Or does it continue?
DeCSS is for playing DVDs on Linux.
A look at the history of DeCSS contradicts that statement. When a program called DeCSS was first released, it ran on Microsoft(tm) Windows(r), and served to strip the copy-restriction from a DVD that had been copied to hard disk.
The original DeCSS only enabled "DVD playing on Linux" insofar as you could convert the DVD to AVI on Windows, and then transfer the file to a Linux box.
Yes, I have heard of the great "apt-get" and will definitely exercise it a bit.
Even if you install packages from CD-Rom, you'll use the same interface as if you were getting it live from HTTP. The only difference is that it'll prompt you to insert the right disc first... and since most packages are small, it'll often take more time for you to find the disc than to just get it from the server.
You didn't mention if you had downloaded the stable or testing Debian... testing is generally prefered, because it's not as painfully obselete. If you value stability, "stable" is good of course. But if you want to have fun and experiment, then newer is better. And if you're using "testing", then you'll probably want to keep up with changes made after the CDs were burnt. Debian "testing" CD-Roms go obselete really fast.
I don't know why you have a problem with the naming of RPMs. I find that it is usually the same as the program or package name.
RPM names also contain at least the version string, and often an indication of which architecture the software will run on. Sometimes supported OS versions are mixed in too. For example, when I tried to install a package on a Red Hat system, I had to download that RPM. Then go to install it, and find out I needed multiple other RPMs first, which need even more RPMs to work.
The point of apt-get is you, the installing user, never even see the *.deb file that the package actually comes in. The hunt for dependencies is completely hidden from you.
Of course, RedHat users can optionally run apt-get themselves, but that's not formally supported by the distribution developer.
I won't go into the whole problem of not getting *.deb files for new, bleeding edge software. It's an accepted fact that Debian users who wish to try something brand-new will be compiling it themselves.
I did noticed dragging video windows (e.g., MPlayer) and my SB Live! (emu10k1 driver from opensource.creative.com) stop playing audio until I let go of the mouse button.
That seems like something wrong with MPlayer itself, not the sound driver or kernel. Assuming the audio is coming from the videofile, MPlayer might stop updating the output stream until the window drag is complete.
(Or, do you mean sounds from other applications stop as well when MPlayer is dragged?)
In the past, putting all the targets on one make invocation could fail mysteriously. I never tracked the problem to it's source (the workaround is easy enough), although presumably it involved the makefiles created in the "dep" stage not being read in time for the other targets to see them. (This might be dependent on the version of "make" you have)
Why would anyone download multiple Debian CDs before installing? That just doesn't make sense. The most you should download is a 150 meg bootable CDROM image, then let the rest of the packages you want come over HTTP when you choose to install them.
Debian prides itself on an enormous amount of packages... nearly twice as many, counting bytes, as RedHat provides. To attempt to download "a copy of Debian" is wrong and wasteful. The fun of Debian comes in when you decide, on the spur of the moment, to try some exotic free software program and can apt-get it in a much less time that it would take to even figure out the name of the RPM you'd need to install on a "normal" Linux system.
Even if the desired install computer doesn't have fast internet access, burning 7 CDs is excessive. There probabably won't even be 2 CDs worth of packages you really want to install. Of the top ten largest packages in Debian, six of them are only desirable for hardcore software developers.
It's a big stretch, but one could argue that consumer protection laws, if properly enforced, would allow him to run a server on a cable modem.
The argument would go like this
It doesn't make sense for cable operators to allocate enough RF channels to the upstream to make it a kick-ass cheap serving pipe.
It doesn't make sense for them to allocate enough upstream for users to constantly send big files. But you can transmit huge data chunks without running a server. I could repeatedly upload Linux ISOs to a public FTP, 24 hours a day. More realistically, I could run a stream live video of my dorm room into a single remote site. Or just look at all the Kazaa users, which are ISPs single biggest headache today (although Kazaa is arguably a server, I don't see why ISPs haven't explicitly forbidden it from their TOS)
If ISPs want to prohibit (or just rate-limit) large outbound connections, fine. Then prohibit "large outbound connections"- not "servers". Running a server is neither a necessary nor sufficient condition for using an unfair amount of bandwidth.