To me it's simpler to just push mono. Otherwise you have to deal with half a dozen different incompatible JVMs.
Naw. The major JVMs will become compatible.
To me, the significant issue is performance. Frankly, given that Mono's been under development for far less time than Sun's JDK and the other JDKs out there, I'm suspicious that it isn't going to do as well. I'm kind of preferring Java if one must be used...but there's no real reason not to have C# and Java bindings. If Miguel wants to write an app in C# and someone else in Java, hey, great.
Sun is apparently trying hard to prove that Java works well in all areas by getting some proof-of-concepts in gaming. The problem is that, really and honestly, for most genres, Java is a really lousy choice.
Performance matters in games.
Memory usage matters in games.
Bugs are more acceptable in games than in any other genre of software. I might learn to live with a painfully slow backup system if I knew that it was rock-solid, but with a game, "painfully slow" is unacceptable. I can live with having to reopen a game three times over the course of playing it, even if I don't like having to do so.
All this is going to do is drive home to people how poorly suited Java is for most game development. It hasn't worked well for horizontal-market app development either. Java is *already* big in custom and vertical market work, where it shines. I just don't see the point in Sun doing marketing when they *don't have the product to fill the need they're aiming at*.
Okay, look. There just isn't any point to having an open source Sun JVM.
* The specs are open (the big problem with MS is that they work hard to make it a pain in the ass for anyone to make compatible software).
* The specs are all that should be needed. There is *tons* of open source software out there that is RFC-compliant. Guess what? The RFCs don't come with free, public domain reference implementations. They just describe a standard. For *decades*, people have been quite happy with a nice open standard. Who needs the source?
* Sun's JVM is good, but not great. There are lots of people working on JVMs out there -- there is *no lack* of open source JVMs. There must be at least thirty JVMs out there, not counting variations produced by a single company. AFAIK, IBM's JVM is the highest-performance thing out there (for Linux at least) and if we're demanding that something be open-sourced based on the fact that it's really good, I'd like to see IBM open-source theirs.
* It works fine. We have had no problems with the current system. Sun has not tried to leverage their JVM to screw people over, and I don't see how or why they'd do so in the future.
* There is no good alternative. What are people going to threaten Sun with, switching to.NET? To a barely-operable Mono or the much-hated Microsoft? I don't think so.
* There is a good set of tools to support Java out there.
* There are open-source alternatives that will probably take over eventually anyway. GCJ is slowly moving along. Why, aside from some kind of symbolism, do people care about using Sun's JVM? Just let GCJ get up to speed and get nice native-code Java builds. Instead of trying to beg for favors from Sun, why not work on GCJ? Sun probably spent more developing the language, docs, and marketing Java than they do developing their particular JVM implementation, anyway.
Given a choice between having Sun's JVM open source or not...yeah, sure, I'd prefer to have it open source. But if I really can't stand using a closed one, I can download Kaffe or one of the other JVMs on freshmeat. I'm not going to avoid Java because one JVM happens to be closed-source. If I avoid Java, it would be for high resource usage and issues with the language, not for some silly political issue.
If there are any non-DRM BIOSes out there it's just because they haven't been updated yet.
Oh, for *Christ's sake*. Look, you silly ninny. Part of the TCPA spec is that it be *user-disablable*. A user *must* be able to flip off TCPA on a system that uses it.
Now, to this I've heard two counterarguments:
a) Compatibility. "Yes, but the vendors will just make their software not *run* without TCPA because they insist on having TCPA-based protection for their product." Fine. Buying a PPC or a SPARC or some oddball x86 box isn't going to do a damned thing to help you here. If a vendor isn't willing to make a product that works without TCPA, they aren't going to make that product that works without TCPA. It means people that have x86 boxes with TCPA off *and* Mac/Solaris/etc users are simply excluded from using that product. You gain nothing by switching platforms.
b) Slippery Slope. "Oh, but they don't have it on *today*, but I've seen someone speculate that the TCPA spec will be changed someday to *prevent* people from disabling TCPA!" Okay. For starters, this is astoundingly unlikely. There is *zero* reason for any BIOS vendor, OEM, or software publisher to want to prevent you from disabling TCPA. They simply have no incentive. It doesn't help them an iota. If they want their software not to run on a TCPA-less system, they won't let it run on a TCPA-less system. It doesn't help prevent piracy or let anyone charge higher prices, or do a single thing for anyone, and a few people will complain bitterly about it. Why bother? In the second place, no barriers are being erected that will make it harder to switch if such an unlikely event did take place. If the whole world suddenly says "no TCPA disabling for you!"...fine. You can switch.
The main group of people that I've seen ranting about TCPA have been overzealous Apple fans, who are apparently trying to confuse and worry people into switching to the Mac.
Oh, yes. This doesn't affect Linux users in the least, either. The only possible people who would be affected would be Windows users.
Finally, I just don't see the fuss over TCPA. It's useless for securing media (far too many ways to break it in any kind of a real-world implementation, it only takes one break to let media be spread across the Internet, etc). It may have minimal use (extremely minimal, since it is interfaced with in a standard manner) in securing software, but people already happily crack things using SafeCD and similar pieces of software -- players pirating software already frequently use cracked or modified copies. All they need to do is crack and distribute a copy that doesn't require TCPA (just like copies of software that check validity over the network or copies of software that use CD protection or whatnot.
TCPA is the most overblown fear that people here have had for *ages*. It's really amazing. If you want to get LinuxBIOS or something, great -- but be realistic, and do it for the fast-boot benefits and other nice things in LinuxBIOS, not because of some phantom fears that people have managed to raise about an Orwellian computing environment. It's just not going to happen.
Teachers have a dramatic impact on a limited-size group.
If you design a system, it can be replicated by the millions. Yes, that alarm clock chipset may only be a minor benefit to one person, but what about to all the people that use it?
Where can I purchase a board preloaded with and known to work with LinuxBIOS? Does it cost significantly more than one running Award or one of the other conventional BIOSes?
I doubt that it's really possible to get good tech support at consumer level prices. Good tech support is awfully expensive. There's a reason customer support has been moved to script-reading outsourced cheapies -- because even though consumers might *want* better tech support, they aren't willing to pay for it.
Frankly, I wish I could buy products with *no* tech support. I have never found the kind of tech support that is within my budget to have any value, and I dislike subsidizing poor tech support for others.
As far as I can tell, reading between the lines, this translates to "We are going to put out more tools that allow easier porting between the XBox and Windows."
There was a lot of what sounded like flufft, but it seems like this is the actual, practical change.
I've seen some terribly impressive motion work from Jessica Hodgins' research.
I also saw a student at CMU produce a swordfighting game as a class project using techniques based on this -- it was truly astounding to watch. It looked absolutely real, fluid, and had all the little nuances that make people move. Normally, you only see this with motion-captured pre-rendered sequences. The improvement here is that hours and hours of motion-captured data are captured, and then split up and combined to form a move that fits the designed constraints. For example, you capture someone doing a number of martial arts forms. You then place an arbitrary path on the ground that you want them to place, and they travel along the track using chunks of captured data from the motion capture that are automatically smoothly transitioned together. It looks really amazing, better than anything I've seen character-animation-wise in a video game yet.
SCO Seeks Licenses Down Under. They are attacking Satan Himself. Anyway, why are they under the impression the "people down under" would use linux? I do believe they are running pirated version of SCO Unix. Of course, not having worked for SCO, I do not have first-hand information on what software people of the nether-world would use.
And nwo the little demon gets SCO inflicted on him as well? Man, even he doesn't deserve that.
As for your instructions on how to make a shape, I can do that, sure, but it is not intuitive. In fact, I would never have figured that out, but I can draw a box in photoshop easily enough.
Huh. I didn't even think there was a box-drawing tool in Photoshop. I don't think I've seen a raster box-drawing program since the days of SuperPaint or MacPaint, but I haven't used Photoshop since version 4 or so, so maybe Photoshop's changed.
What I do in both Photoshop and GIMP was to create a selection with whatever outline I want (using the rectangular, circular, whatever) selection tool, and then hitting fill to create my nice rectangle or oval or whatnot.
As some other people have pointed out, though, are you sure Photoshop/GIMP/a raster processing program is what you want? If what you're making is a simple diagram, dia is both easier and much more convenient to use, and if you want just flat vector graphics...well, there are a bunch of Open Source programs, but nothing as nice as the GIMP is for raster graphics yet, you're right there.
The Open Source world consists of a massive herd of cats. They live by themselves, they do their own bizarre cat things, and they're awfully independent. They're talented but touchy. Some of them are awfully stubborn. Sometimes, one will get interested in something or gets an idea into its cat-brain, and start heading the direction of whatever's interested it. Sometimes other cats come along, and you get a whole pack swarming along. Occasionally a lot of cats get really interested in something (like a kernel), and then the sight is truly magestic, with a herd of cats pouring over everything that obstructs them from their goal. They're really quite unstoppable then.
The problem, Novell, is that right now a good-sized pack of cats have it firmly in their heads that they definitely and without question want to go *west*. There is another good-sized pack of cats that are absolutely certain that they want to go *east*. The combination has produced cats going in opposite directions colliding with each other and hissing and scratching at each other.
However, Novell, before you step smack dab into the middle of this writhing, temperamental herd and try to direct them to go *north*, I suggest that you keep in mind -- you are herding cats.
Don't forget to add a default class to the HTB to match any MAC that all your previous matching work didn't match. That way, anyone that you *haven't* added a MAC entry for (adding a child to the HTB tree) will at least go into a general class and get connectivity...they just have to share it with all the other people in the "general" class.
You may want to toy with the idea of having a perl script or something look at unmatched packets or maybe scrape the ARP cache (arp -a) to automatically add new entries to the HTB tree.
You will want to be sure that this box is set to autorestart on power failure.
You will want to include instructions (probably on the face of the box, as well as on file with whoever owns the property) on how to remove the box from the loop. That hard drive will fail someday.
For some reason, when I insert my shaper in between my DSL modem and the local network and start using it, I seem to see a delay of a minute or two before requests from clients on the inside start hitting the ouside). This confuses me immensely, since a major benefit of using a bridge over a pseudo-bridge is that the ARP entries, the MAC-IP mappings, stay the same. No idea what the cause is.
As another aside, some distros bundle pump as the DHCP client, rather than dhclient.
Oh, speaking of DHCP, big tip for Red Hat/Fedora users. Absolutely do not use the vanilla ifup scripts that Red Hat provides. They *suck*. If you are on any kind of a consumer DSL connection, every now and then (perhaps rare, perhaps common) you will lose your connection, for whatever reason. For some reason, Red Hat sets up their copy of dhclient to *give up* if it fails to get a dhcp lease, which means I frequently endured having a power outage at my house when I was away (killing the line) and then being unable to reach my computer remotely because it never acquired a DHCP lease.
Look in/etc/sysconfig/network-scripts/ifup, and search for a line that looks like the following:
DHCLIENTARGS="${DHCLIENTARGS} -1 -q -lf/var/lib/dhcp/dhclient-${DEVICE}.lea ses -pf/var/run/dhclient-${DEVICE}.pid -cf/etc/dhclient-${DEVICE}.conf"
Change the -1 (telling dhclient to die if it can't get a lease immediately) to a -w (telling it to keep trying) in that line, and you won't have to endure your Linux box randomly becoming unreachable and losing the IP address on its interface.
Policy solutions are generally less scalable, harder to enforce, and cause more social issues in enforcement than technical solutions. If one can manage a technical solution, I'd prefer it.
More to the point, a traffic shaper knows about the current demands that all the computers are putting on the network. Each individual computer with throttling capabilities does not. Sure, Bob can throttle his traffic down to 3KBps, but that means that when nobody else is using the network, he isn't taking advantage of it. It also means that if someone's doing something that *does* require low latency (ssh, perhaps web browsing), his P2P client bandwidth usage isn't scaled back to provide bandwidth for it.
As another followup, I looked on Freshmeat, and couldn't find anything that did what I wanted. It seems that it's all the rage to have traffic shapers also do NAT, which I *really* did not want.
I don't think Freshmeat is currently a good place to go when looking for a traffic shaping system to do this sort of thing.
The problem is that this still has severe problems. It does avoid the awful latency problems once someone starts using the network and fills up the modem's outbound buffer. It does not evenly share out bandwidth.
It requires the hosts on the inside side of the shaper to regulate their own traffic, via TCP throttling from packet loss. Unfortunately, TCP only knows about the single stream that it's dealing with. Most P2P clients these days have *scads* of TCP connections open at any given time. Which means that if one guy is running eDonkey with 300 simultaneous downloads running on his computer, and another guy is just trying to browse the web, eDonkey is going to get 99.7% of the bandwidth, and the guy with the web browser (one pipelined HTTP connection).3%, since his computer backs off just as quickly as the guy running the P2P client on each connection.
It's really necessary to use a system that shares out bandwidth evenly between hosts if your users are going to be opening many connections per host (and a P2P client almost always means that this is the case).
Also, if you want to keep the network usable for people that want to use the Internet comfortably *and* soak up any spare bandwidth on a host at the same time, you need to prioritize P2P traffic at the bottom, and things like ssh at the top.
The.glue TLD is part of OpenNIC. It is, AFAIK, not part of whatever this apparently despised "new.net" business is.
OpenNIC is just an alternate root that you can switch your name sever to if you don't like ICANN policies. Unfortunately, they can really only add TLDs, not remove them (since doing so would break resolution for all their users), so they can't do what *I* would really like to see -- eliminating the bullshit TLDs that ICANN added..museum?.biz? Christ.
For starters, you're never going to get away with breaking all existing URLs. Which means that "ICANN" will have to be the default.
If you want to do that, you could produce the same effect by just adding a new tld (".opennic"), and sticking everything under there -- you have computers.geek and computers.geek.opennic. You can do this *today* if you can deal with putting two levels instead of just a TLD in -- like computers.geek.reg.net or something.
I set up a DSL traffic shaper on Linux a bit ago. It's a bit of a pain in the ass to figure out the right things to do, and I don't have the script handy, but here are some pointers (given that this is from memory, some of this will probably be wrong).
Get a Linux box. Get two NICs (c'mon, NICs are cheap these days, and the DSL modem only needs a 10Mbit one).
If your boxes use DHCP, you might want to give your shaper an outside IP address (so that it can run ntp and the like, if nothing else). Use br0 as the interface -- this tripped me up at first.
dhclient br0
Add per-host rate limiting. There are two *excellent* solutions to do this automatically under Linux -- esfq and wrr. Both automatically detect IP addresses on one side and spread bandwidth out evenly. Neither is apparently actively maintained, unfortunately, so if you're using a 2.6 kernel, you're out of luck. Your best bet is probably HTB (which *is* included in 2.6 and I believe current 2.4 kernels). HTB requires you to manually create a child of the main HTB qdisc for each IP address, and filter based on source IP address (or source MAC address, which is probably more appropriate if you have a single Ethernet segment and dynamically assigned IP addresses) but lets you filter traffic differently for each host. For a small network, this may be feasible. I'd hang another qdisc off of the HTB that reduces the priority of P2P *within* each host's account, so that someone can use spare bandwidth for eDonkey or whatever, but still retains reasonably snappy SSH, even on their own box.
You must set the maximum flow of the HTB just below the DSL modem's data transfer rate, or else the modem's buffer will fill up when outbound traffic fills up its (big) buffer, making interactive use impossible. Keep reducing the limit and then ping flooding (ping -f) the outside world from an inside box. Keep a regular ping running in another terminal, and monitor it. When your system is working right *ping times should not climb above 150 or 200ms or so on a box*. No 1000ms latency. You should simply start seeing packet loss.
I must say that setting something like this up was a huge pain in the ass, and that if I had the script handy at the moment, I'd post it. The Linux networking/filtering/routing system is not as well documented as it should be, and is *not* always the most intuitive thing in the world. It is, apparently, pretty powerful, based on what I've read from folks that have used other systems, though. [shrug]
Speaking of which, I can't figure out why sfq is in mainstream Linux but esfq is not. SFQ is, to my mind, almost useless for most people. Who on earth wants to balance all their TCP flows evenly? Even per-host bandwidth allocation is a *far* more common problem, and one that vanilla Linux (and any 2.6 kernel) cannot handle well.
I did not find it necessary to use ebtables or ipchains to produce an effective traffic shaper. YMMV.
Slashdot Mirror
To me it's simpler to just push mono. Otherwise you have to deal with half a dozen different incompatible JVMs.
Naw. The major JVMs will become compatible.
To me, the significant issue is performance. Frankly, given that Mono's been under development for far less time than Sun's JDK and the other JDKs out there, I'm suspicious that it isn't going to do as well. I'm kind of preferring Java if one must be used...but there's no real reason not to have C# and Java bindings. If Miguel wants to write an app in C# and someone else in Java, hey, great.
Sun is apparently trying hard to prove that Java works well in all areas by getting some proof-of-concepts in gaming. The problem is that, really and honestly, for most genres, Java is a really lousy choice.
Performance matters in games.
Memory usage matters in games.
Bugs are more acceptable in games than in any other genre of software. I might learn to live with a painfully slow backup system if I knew that it was rock-solid, but with a game, "painfully slow" is unacceptable. I can live with having to reopen a game three times over the course of playing it, even if I don't like having to do so.
All this is going to do is drive home to people how poorly suited Java is for most game development. It hasn't worked well for horizontal-market app development either. Java is *already* big in custom and vertical market work, where it shines. I just don't see the point in Sun doing marketing when they *don't have the product to fill the need they're aiming at*.
Okay, look. There just isn't any point to having an open source Sun JVM.
.NET? To a barely-operable Mono or the much-hated Microsoft? I don't think so.
* The specs are open (the big problem with MS is that they work hard to make it a pain in the ass for anyone to make compatible software).
* The specs are all that should be needed. There is *tons* of open source software out there that is RFC-compliant. Guess what? The RFCs don't come with free, public domain reference implementations. They just describe a standard. For *decades*, people have been quite happy with a nice open standard. Who needs the source?
* Sun's JVM is good, but not great. There are lots of people working on JVMs out there -- there is *no lack* of open source JVMs. There must be at least thirty JVMs out there, not counting variations produced by a single company. AFAIK, IBM's JVM is the highest-performance thing out there (for Linux at least) and if we're demanding that something be open-sourced based on the fact that it's really good, I'd like to see IBM open-source theirs.
* It works fine. We have had no problems with the current system. Sun has not tried to leverage their JVM to screw people over, and I don't see how or why they'd do so in the future.
* There is no good alternative. What are people going to threaten Sun with, switching to
* There is a good set of tools to support Java out there.
* There are open-source alternatives that will probably take over eventually anyway. GCJ is slowly moving along. Why, aside from some kind of symbolism, do people care about using Sun's JVM? Just let GCJ get up to speed and get nice native-code Java builds. Instead of trying to beg for favors from Sun, why not work on GCJ? Sun probably spent more developing the language, docs, and marketing Java than they do developing their particular JVM implementation, anyway.
Given a choice between having Sun's JVM open source or not...yeah, sure, I'd prefer to have it open source. But if I really can't stand using a closed one, I can download Kaffe or one of the other JVMs on freshmeat. I'm not going to avoid Java because one JVM happens to be closed-source. If I avoid Java, it would be for high resource usage and issues with the language, not for some silly political issue.
If there are any non-DRM BIOSes out there it's just because they haven't been updated yet.
Oh, for *Christ's sake*. Look, you silly ninny. Part of the TCPA spec is that it be *user-disablable*. A user *must* be able to flip off TCPA on a system that uses it.
Now, to this I've heard two counterarguments:
a) Compatibility. "Yes, but the vendors will just make their software not *run* without TCPA because they insist on having TCPA-based protection for their product." Fine. Buying a PPC or a SPARC or some oddball x86 box isn't going to do a damned thing to help you here. If a vendor isn't willing to make a product that works without TCPA, they aren't going to make that product that works without TCPA. It means people that have x86 boxes with TCPA off *and* Mac/Solaris/etc users are simply excluded from using that product. You gain nothing by switching platforms.
b) Slippery Slope. "Oh, but they don't have it on *today*, but I've seen someone speculate that the TCPA spec will be changed someday to *prevent* people from disabling TCPA!" Okay. For starters, this is astoundingly unlikely. There is *zero* reason for any BIOS vendor, OEM, or software publisher to want to prevent you from disabling TCPA. They simply have no incentive. It doesn't help them an iota. If they want their software not to run on a TCPA-less system, they won't let it run on a TCPA-less system. It doesn't help prevent piracy or let anyone charge higher prices, or do a single thing for anyone, and a few people will complain bitterly about it. Why bother? In the second place, no barriers are being erected that will make it harder to switch if such an unlikely event did take place. If the whole world suddenly says "no TCPA disabling for you!"...fine. You can switch.
The main group of people that I've seen ranting about TCPA have been overzealous Apple fans, who are apparently trying to confuse and worry people into switching to the Mac.
Oh, yes. This doesn't affect Linux users in the least, either. The only possible people who would be affected would be Windows users.
Finally, I just don't see the fuss over TCPA. It's useless for securing media (far too many ways to break it in any kind of a real-world implementation, it only takes one break to let media be spread across the Internet, etc). It may have minimal use (extremely minimal, since it is interfaced with in a standard manner) in securing software, but people already happily crack things using SafeCD and similar pieces of software -- players pirating software already frequently use cracked or modified copies. All they need to do is crack and distribute a copy that doesn't require TCPA (just like copies of software that check validity over the network or copies of software that use CD protection or whatnot.
TCPA is the most overblown fear that people here have had for *ages*. It's really amazing. If you want to get LinuxBIOS or something, great -- but be realistic, and do it for the fast-boot benefits and other nice things in LinuxBIOS, not because of some phantom fears that people have managed to raise about an Orwellian computing environment. It's just not going to happen.
Teachers have a dramatic impact on a limited-size group.
If you design a system, it can be replicated by the millions. Yes, that alarm clock chipset may only be a minor benefit to one person, but what about to all the people that use it?
Where can I purchase a board preloaded with and known to work with LinuxBIOS? Does it cost significantly more than one running Award or one of the other conventional BIOSes?
I doubt that it's really possible to get good tech support at consumer level prices. Good tech support is awfully expensive. There's a reason customer support has been moved to script-reading outsourced cheapies -- because even though consumers might *want* better tech support, they aren't willing to pay for it.
Frankly, I wish I could buy products with *no* tech support. I have never found the kind of tech support that is within my budget to have any value, and I dislike subsidizing poor tech support for others.
As far as I can tell, reading between the lines, this translates to "We are going to put out more tools that allow easier porting between the XBox and Windows."
There was a lot of what sounded like flufft, but it seems like this is the actual, practical change.
I've seen some terribly impressive motion work from Jessica Hodgins' research.
I also saw a student at CMU produce a swordfighting game as a class project using techniques based on this -- it was truly astounding to watch. It looked absolutely real, fluid, and had all the little nuances that make people move. Normally, you only see this with motion-captured pre-rendered sequences. The improvement here is that hours and hours of motion-captured data are captured, and then split up and combined to form a move that fits the designed constraints. For example, you capture someone doing a number of martial arts forms. You then place an arbitrary path on the ground that you want them to place, and they travel along the track using chunks of captured data from the motion capture that are automatically smoothly transitioned together. It looks really amazing, better than anything I've seen character-animation-wise in a video game yet.
Yes, all that *sounds* nice, but you lose Bonzi Buddy functionality.
SCO Seeks Licenses Down Under.
They are attacking Satan Himself. Anyway, why are they under the impression the "people down under" would use linux? I do believe they are running pirated version of SCO Unix. Of course, not having worked for SCO, I do not have first-hand information on what software people of the nether-world would use.
And nwo the little demon gets SCO inflicted on him as well? Man, even he doesn't deserve that.
As for your instructions on how to make a shape, I can do that, sure, but it is not intuitive. In fact, I would never have figured that out, but I can draw a box in photoshop easily enough.
Huh. I didn't even think there was a box-drawing tool in Photoshop. I don't think I've seen a raster box-drawing program since the days of SuperPaint or MacPaint, but I haven't used Photoshop since version 4 or so, so maybe Photoshop's changed.
What I do in both Photoshop and GIMP was to create a selection with whatever outline I want (using the rectangular, circular, whatever) selection tool, and then hitting fill to create my nice rectangle or oval or whatnot.
As some other people have pointed out, though, are you sure Photoshop/GIMP/a raster processing program is what you want? If what you're making is a simple diagram, dia is both easier and much more convenient to use, and if you want just flat vector graphics...well, there are a bunch of Open Source programs, but nothing as nice as the GIMP is for raster graphics yet, you're right there.
Novell:
The Open Source world consists of a massive herd of cats. They live by themselves, they do their own bizarre cat things, and they're awfully independent. They're talented but touchy. Some of them are awfully stubborn. Sometimes, one will get interested in something or gets an idea into its cat-brain, and start heading the direction of whatever's interested it. Sometimes other cats come along, and you get a whole pack swarming along. Occasionally a lot of cats get really interested in something (like a kernel), and then the sight is truly magestic, with a herd of cats pouring over everything that obstructs them from their goal. They're really quite unstoppable then.
The problem, Novell, is that right now a good-sized pack of cats have it firmly in their heads that they definitely and without question want to go *west*. There is another good-sized pack of cats that are absolutely certain that they want to go *east*. The combination has produced cats going in opposite directions colliding with each other and hissing and scratching at each other.
However, Novell, before you step smack dab into the middle of this writhing, temperamental herd and try to direct them to go *north*, I suggest that you keep in mind -- you are herding cats.
Legality has nothing to do with whether something is terrorism or not.
Hmm. The RIAA has hit Berkeley, Stanford, and MIT now. They're really trying *hard* to convince CS students to work on anonymizing projects...
Don't forget to add a default class to the HTB to match any MAC that all your previous matching work didn't match. That way, anyone that you *haven't* added a MAC entry for (adding a child to the HTB tree) will at least go into a general class and get connectivity...they just have to share it with all the other people in the "general" class.
You may want to toy with the idea of having a perl script or something look at unmatched packets or maybe scrape the ARP cache (arp -a) to automatically add new entries to the HTB tree.
You will want to be sure that this box is set to autorestart on power failure.
You will want to include instructions (probably on the face of the box, as well as on file with whoever owns the property) on how to remove the box from the loop. That hard drive will fail someday.
For some reason, when I insert my shaper in between my DSL modem and the local network and start using it, I seem to see a delay of a minute or two before requests from clients on the inside start hitting the ouside). This confuses me immensely, since a major benefit of using a bridge over a pseudo-bridge is that the ARP entries, the MAC-IP mappings, stay the same. No idea what the cause is.
As another aside, some distros bundle pump as the DHCP client, rather than dhclient.
/etc/sysconfig/network-scripts/ifup, and search for a line that looks like the following:
/var/lib/dhcp/dhclient-${DEVICE}.lea /var/run/dhclient-${DEVICE}.pid -cf /etc/dhclient-${DEVICE}.conf"
Oh, speaking of DHCP, big tip for Red Hat/Fedora users. Absolutely do not use the vanilla ifup scripts that Red Hat provides. They *suck*. If you are on any kind of a consumer DSL connection, every now and then (perhaps rare, perhaps common) you will lose your connection, for whatever reason. For some reason, Red Hat sets up their copy of dhclient to *give up* if it fails to get a dhcp lease, which means I frequently endured having a power outage at my house when I was away (killing the line) and then being unable to reach my computer remotely because it never acquired a DHCP lease.
Look in
DHCLIENTARGS="${DHCLIENTARGS} -1 -q -lf
ses -pf
Change the -1 (telling dhclient to die if it can't get a lease immediately) to a -w (telling it to keep trying) in that line, and you won't have to endure your Linux box randomly becoming unreachable and losing the IP address on its interface.
Policy solutions are generally less scalable, harder to enforce, and cause more social issues in enforcement than technical solutions. If one can manage a technical solution, I'd prefer it.
More to the point, a traffic shaper knows about the current demands that all the computers are putting on the network. Each individual computer with throttling capabilities does not. Sure, Bob can throttle his traffic down to 3KBps, but that means that when nobody else is using the network, he isn't taking advantage of it. It also means that if someone's doing something that *does* require low latency (ssh, perhaps web browsing), his P2P client bandwidth usage isn't scaled back to provide bandwidth for it.
As another followup, I looked on Freshmeat, and couldn't find anything that did what I wanted. It seems that it's all the rage to have traffic shapers also do NAT, which I *really* did not want.
I don't think Freshmeat is currently a good place to go when looking for a traffic shaping system to do this sort of thing.
The problem is that this still has severe problems. It does avoid the awful latency problems once someone starts using the network and fills up the modem's outbound buffer. It does not evenly share out bandwidth.
.3%, since his computer backs off just as quickly as the guy running the P2P client on each connection.
It requires the hosts on the inside side of the shaper to regulate their own traffic, via TCP throttling from packet loss. Unfortunately, TCP only knows about the single stream that it's dealing with. Most P2P clients these days have *scads* of TCP connections open at any given time. Which means that if one guy is running eDonkey with 300 simultaneous downloads running on his computer, and another guy is just trying to browse the web, eDonkey is going to get 99.7% of the bandwidth, and the guy with the web browser (one pipelined HTTP connection)
It's really necessary to use a system that shares out bandwidth evenly between hosts if your users are going to be opening many connections per host (and a P2P client almost always means that this is the case).
Also, if you want to keep the network usable for people that want to use the Internet comfortably *and* soak up any spare bandwidth on a host at the same time, you need to prioritize P2P traffic at the bottom, and things like ssh at the top.
Oh, yes. If you're just giving br0 a static IP, don't forget to bring the interface up.
ifconfig br0 1.2.3.4 [or whatever your IP is]
ifconfig br0 up
I did not find it necessary to use ebtables or ipchains to produce an effective traffic shaper.
And by this I mean that all the commands that you'll have to use that I didn't already list should start with tc.
The .glue TLD is part of OpenNIC. It is, AFAIK, not part of whatever this apparently despised "new.net" business is.
.museum? .biz? Christ.
OpenNIC is just an alternate root that you can switch your name sever to if you don't like ICANN policies. Unfortunately, they can really only add TLDs, not remove them (since doing so would break resolution for all their users), so they can't do what *I* would really like to see -- eliminating the bullshit TLDs that ICANN added.
For starters, you're never going to get away with breaking all existing URLs. Which means that "ICANN" will have to be the default.
If you want to do that, you could produce the same effect by just adding a new tld (".opennic"), and sticking everything under there -- you have computers.geek and computers.geek.opennic. You can do this *today* if you can deal with putting two levels instead of just a TLD in -- like computers.geek.reg.net or something.
I set up a DSL traffic shaper on Linux a bit ago. It's a bit of a pain in the ass to figure out the right things to do, and I don't have the script handy, but here are some pointers (given that this is from memory, some of this will probably be wrong).
Get a Linux box. Get two NICs (c'mon, NICs are cheap these days, and the DSL modem only needs a 10Mbit one).
Set up bridging on the Linux box.
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
If your boxes use DHCP, you might want to give your shaper an outside IP address (so that it can run ntp and the like, if nothing else). Use br0 as the interface -- this tripped me up at first.
dhclient br0
Add per-host rate limiting. There are two *excellent* solutions to do this automatically under Linux -- esfq and wrr. Both automatically detect IP addresses on one side and spread bandwidth out evenly. Neither is apparently actively maintained, unfortunately, so if you're using a 2.6 kernel, you're out of luck. Your best bet is probably HTB (which *is* included in 2.6 and I believe current 2.4 kernels). HTB requires you to manually create a child of the main HTB qdisc for each IP address, and filter based on source IP address (or source MAC address, which is probably more appropriate if you have a single Ethernet segment and dynamically assigned IP addresses) but lets you filter traffic differently for each host. For a small network, this may be feasible. I'd hang another qdisc off of the HTB that reduces the priority of P2P *within* each host's account, so that someone can use spare bandwidth for eDonkey or whatever, but still retains reasonably snappy SSH, even on their own box.
You must set the maximum flow of the HTB just below the DSL modem's data transfer rate, or else the modem's buffer will fill up when outbound traffic fills up its (big) buffer, making interactive use impossible. Keep reducing the limit and then ping flooding (ping -f) the outside world from an inside box. Keep a regular ping running in another terminal, and monitor it. When your system is working right *ping times should not climb above 150 or 200ms or so on a box*. No 1000ms latency. You should simply start seeing packet loss.
I must say that setting something like this up was a huge pain in the ass, and that if I had the script handy at the moment, I'd post it. The Linux networking/filtering/routing system is not as well documented as it should be, and is *not* always the most intuitive thing in the world. It is, apparently, pretty powerful, based on what I've read from folks that have used other systems, though. [shrug]
Speaking of which, I can't figure out why sfq is in mainstream Linux but esfq is not. SFQ is, to my mind, almost useless for most people. Who on earth wants to balance all their TCP flows evenly? Even per-host bandwidth allocation is a *far* more common problem, and one that vanilla Linux (and any 2.6 kernel) cannot handle well.
I did not find it necessary to use ebtables or ipchains to produce an effective traffic shaper. YMMV.