Is there any good documentation on tc out there anywhere? I've been finding the traffic shaping howtos a bit impenetrable and I used an iptables based filter instead. But I want to understand how to use tc and Linux traffic shaping because it looks a lot more flexible.
I had a housemate who ran P2P software all the time without even realizing it. Talking to him did nothing. Limiting the number of outbound packets from his computer to a certain number per second with a fairly high burst solved the problem. He liked playing WoW and when his WoW connection started getting all weird and I told him it was his P2P sofware he started to make sure it wasn't running. The average cap I set was plenty enough for WoW and enough for a decent download speed for P2P as well.
I'm all for bandwidth throttling and traffic shaping as long as it's to ensure usage fairness. If I were running an ISP I would have a per-customer 5 minute bandwidth meter and customers who had exceeded their share for 5 minutes would have all their traffic dropped to the lowest priority until there was a 5 minute interval in which they hadn't exceeded their share.
And it would be share of total pipe available to the ISP's upstreams, not some arbitrary fixed cap per customer. If the P2P application were written to favor connecting to other customers of the ISP that would be a way to avoid the re-prioritization completely.
I do not like companies like yours at all. I've worked in a couple, and the culture of them tends to be trying to put down any Open Source competitors and somehow claim your product is better when it isn't.
One of these companies was basically a one-trick-pony that had one really neat technology and a bunch of non-GPL Open Source around it. They consistently bastardized the non-GPL Open Source and knowingly added huge security vulnerabilities for the sake of expediency and being able to have their features out faster than Open Source competitors. It was stupid and wrong.
The sad thing is, they all could've sold their stuff just fine as an Open Source solution. Most companies who bought from them bought an appliance that they wanted the company in question to just make work. That's a fine Open Source play, and I would've had a lot more respect for them had they actually done that.
I do not like this section
on
I Will Derive
·
· Score: 1
I do not want to see posts from it. I notice that it doesn't appear in the sections list so I can turn it off. I want to turn it off.
I believe that using the numbers out of the wikipedia entry you mention to describe cold fusion reactions would be a mistake. It seems to me that those numbers reflect what happens with the high-energy nuclei interactions you'd expect to see in extremely hot and dense plasmas. That does not describe the environment when nuclei interact in cold fusion, if that's what's really happening.
This article links to what is basically an infomercial. What it links to is filled with pictures and seeming explanations, but it's written in scare-mongering language and not written with an eye towards the reader understanding it. It as an advertisement telling you that Websense is a fantastic company because they understand all this terribly scary stuff and already have the technology to defeat it for you.
Basically they are asking you for an arbitrary amount of computer power whenever they want it, for free. You shouldn't allow this.
If you provide access to some interface for running SQL queries against databases you host, come up with a way for charging them for the resources those queries take to run. If you don't, you're just asking them to write SQL queries that compute 1 billion digits of Pi.
Otherwise, work with them to get the data feeds they need to run those queries locally using their own resources. If they're worried about cost have them use MySQL or something like that.
I repeat, do not allow them to run arbitrary queries without some way of making sure that you aren't providing them with potentially infinite resources for free.
I think you are completely correct and that this is exactly what would happen in most cases with software that came out of a corporation. I don't think you're being cynical at all, just realistic.
i was sure that netscape problem was due to the US crypto export regs (the silly encryption=munitions thing) that limited the encryption to 40-bit keys.
Then you are mistaken. Read the linked to paper. N bit security doesn't protect you much when you can guess N-10 bits of the N bits.
I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.
Yes, it is a big worry because any keys generated with this package are now potentially suspect. This means that anybody who's used Debian or a Debian derived distribution like Ubuntu needs to go back and destroy all host and personal keys generated since 2006. All of those keys are potentially guessable.
If you have ever worked for a closed source software maker you wouldn't be talking about the quality control in closed source.
Yes, I agree that having a trojan slipped in is a little less likely as it would require a malicious employee rather than a malicious random contributor. But the quality of the code is utterly and horribly abysmal. For every trojan that doesn't make it in there must be at least 500 security bugs that make it out because of the horrible quality control of closed source.
The software industry is currently in worse shape than Detroit auto manufacturers in the 70s. Way worse shape.
What I recommend is a hook for your source control system that refuses checkins for any code that has leading whitespace containing tabs.:-)
But yeah, I hear you with Makefiles. And I can see how Python's use of a similar idea is similarly problematic. I've never actually found the leading spaces in Makefiles to be that big of a problem, it's other things about Makefiles that I find problematic. But I know it's something that vexes a lot of people.
I consider any filesystem that can't handle thousands of small files in a single directory to be broken. And Hans Reiser's whole point about naming systems in his initial paper about Reiser 3 is perfectly true and seems to be being ignored by most people creating filesystems.
I hate 'indentation is scope'. If your editor disagrees with your runtime on how many spaces are in a tab (or if it changes), your code breaks.
Stop using tabs for indentation. Please, for all of our sakes, just don't do it. Every single person I know who uses tabs for indentation sets 4 space tabs. Every single tool in existence that's not a programmers editor sets 8 space tabs (except for vi and emacs which also use 8 space tabs). This means that to anybody who doesn't go through and obsessively change any use of a random tool to have 4 space tabs insead of 8, your code looks horribly ugly and is much harder to understand.
So just stop using tabs for indentation. Ignore the seductive sirens call of setting them to 4 spaces in your editor. Your editor is wrong. You are wrong if you use tabs for indentation. Just stop doing it please.
I frequently use a comment like that at the end of namespaces. Namespaces by their very nature are blocks that encompass many lines. And I don't indent code inside of namespaces. So, while I generally agree with you, I think there are specific cases in which that sort of comment is pretty helpful.
I can see cases in which I'd want to write an application primarily in C++, but it would be a pretty rare thing now. Mostly I see C and C++ as ways to make Python faster when it needs to be.
The garbage collection is nice, yes. But what really draws me to interpreted languages is how easy it is to build programs in tiny little scraps that you independently test along the way. And after that, how some of them allow you to have great economy of expression without being hopelessly obscure.
Do the math. About the only feasible designs for near C craft are ones that rely on being to scoop up interstellar hydrogen and use that. Even antimatter doesn't give you enough energy to be able to manage it.
There are two big problems with traveling that fast. The first is shielding. At really high speeds every stray atom becomes a cosmic ray. The second is the amount of energy and reaction mass needed.
Is, to some extant, against the tenants of democracy. My reading on democracy is that there are rules about what people are allowed to do to eachother physically, but no rules about memes. I think it's questionable as to whether using physically coercive means such as taxes to further memetic warfare directed at our own citizens is at all valid within this framework. The government here is trying to enforce rules about memes on its own citizens.
Slashdot Mirror
Is there any good documentation on tc out there anywhere? I've been finding the traffic shaping howtos a bit impenetrable and I used an iptables based filter instead. But I want to understand how to use tc and Linux traffic shaping because it looks a lot more flexible.
I had a housemate who ran P2P software all the time without even realizing it. Talking to him did nothing. Limiting the number of outbound packets from his computer to a certain number per second with a fairly high burst solved the problem. He liked playing WoW and when his WoW connection started getting all weird and I told him it was his P2P sofware he started to make sure it wasn't running. The average cap I set was plenty enough for WoW and enough for a decent download speed for P2P as well.
I'm all for bandwidth throttling and traffic shaping as long as it's to ensure usage fairness. If I were running an ISP I would have a per-customer 5 minute bandwidth meter and customers who had exceeded their share for 5 minutes would have all their traffic dropped to the lowest priority until there was a 5 minute interval in which they hadn't exceeded their share.
And it would be share of total pipe available to the ISP's upstreams, not some arbitrary fixed cap per customer. If the P2P application were written to favor connecting to other customers of the ISP that would be a way to avoid the re-prioritization completely.
I do not like companies like yours at all. I've worked in a couple, and the culture of them tends to be trying to put down any Open Source competitors and somehow claim your product is better when it isn't.
One of these companies was basically a one-trick-pony that had one really neat technology and a bunch of non-GPL Open Source around it. They consistently bastardized the non-GPL Open Source and knowingly added huge security vulnerabilities for the sake of expediency and being able to have their features out faster than Open Source competitors. It was stupid and wrong.
The sad thing is, they all could've sold their stuff just fine as an Open Source solution. Most companies who bought from them bought an appliance that they wanted the company in question to just make work. That's a fine Open Source play, and I would've had a lot more respect for them had they actually done that.
I do not want to see posts from it. I notice that it doesn't appear in the sections list so I can turn it off. I want to turn it off.
I believe that using the numbers out of the wikipedia entry you mention to describe cold fusion reactions would be a mistake. It seems to me that those numbers reflect what happens with the high-energy nuclei interactions you'd expect to see in extremely hot and dense plasmas. That does not describe the environment when nuclei interact in cold fusion, if that's what's really happening.
This particular programmer has been known in the past to check in code to CVS that failed to compile. So the fact he did this doesn't surprise me.
Perhaps most pieces of DNS software can do both. But actual DNS installations should not be configured that way. In fact, I've seen a rise in DNS cache poisoning attempts against my authoritative DNS server.
It would be really nice if people would tag articles like this with 'slashvertisement'. :-)
This article links to what is basically an infomercial. What it links to is filled with pictures and seeming explanations, but it's written in scare-mongering language and not written with an eye towards the reader understanding it. It as an advertisement telling you that Websense is a fantastic company because they understand all this terribly scary stuff and already have the technology to defeat it for you.
Basically they are asking you for an arbitrary amount of computer power whenever they want it, for free. You shouldn't allow this.
If you provide access to some interface for running SQL queries against databases you host, come up with a way for charging them for the resources those queries take to run. If you don't, you're just asking them to write SQL queries that compute 1 billion digits of Pi.
Otherwise, work with them to get the data feeds they need to run those queries locally using their own resources. If they're worried about cost have them use MySQL or something like that.
I repeat, do not allow them to run arbitrary queries without some way of making sure that you aren't providing them with potentially infinite resources for free.
I think you are completely correct and that this is exactly what would happen in most cases with software that came out of a corporation. I don't think you're being cynical at all, just realistic.
A simple update is not sufficient to fix the problems caused by this bug.
i was sure that netscape problem was due to the US crypto export regs (the silly encryption=munitions thing) that limited the encryption to 40-bit keys.
Then you are mistaken. Read the linked to paper. N bit security doesn't protect you much when you can guess N-10 bits of the N bits.
I'm sure the problem will be fixed if the developers acknowledge that the problem exists. Not a big worry.
Yes, it is a big worry because any keys generated with this package are now potentially suspect. This means that anybody who's used Debian or a Debian derived distribution like Ubuntu needs to go back and destroy all host and personal keys generated since 2006. All of those keys are potentially guessable.
And that's a real vulnerability. Early versions of Netscape's SSL implementation (the first SSL implementation) were trivially crackable because of just such a vulnerability.
Who did this? You don't remove the seeding... stupid
That's what I was thinking too. What kind of idiot makes that sort of change?
If you have ever worked for a closed source software maker you wouldn't be talking about the quality control in closed source.
Yes, I agree that having a trojan slipped in is a little less likely as it would require a malicious employee rather than a malicious random contributor. But the quality of the code is utterly and horribly abysmal. For every trojan that doesn't make it in there must be at least 500 security bugs that make it out because of the horrible quality control of closed source.
The software industry is currently in worse shape than Detroit auto manufacturers in the 70s. Way worse shape.
What I recommend is a hook for your source control system that refuses checkins for any code that has leading whitespace containing tabs. :-)
But yeah, I hear you with Makefiles. And I can see how Python's use of a similar idea is similarly problematic. I've never actually found the leading spaces in Makefiles to be that big of a problem, it's other things about Makefiles that I find problematic. But I know it's something that vexes a lot of people.
I consider any filesystem that can't handle thousands of small files in a single directory to be broken. And Hans Reiser's whole point about naming systems in his initial paper about Reiser 3 is perfectly true and seems to be being ignored by most people creating filesystems.
Stop using tabs for indentation. Please, for all of our sakes, just don't do it. Every single person I know who uses tabs for indentation sets 4 space tabs. Every single tool in existence that's not a programmers editor sets 8 space tabs (except for vi and emacs which also use 8 space tabs). This means that to anybody who doesn't go through and obsessively change any use of a random tool to have 4 space tabs insead of 8, your code looks horribly ugly and is much harder to understand.
So just stop using tabs for indentation. Ignore the seductive sirens call of setting them to 4 spaces in your editor. Your editor is wrong. You are wrong if you use tabs for indentation. Just stop doing it please.
I frequently use a comment like that at the end of namespaces. Namespaces by their very nature are blocks that encompass many lines. And I don't indent code inside of namespaces. So, while I generally agree with you, I think there are specific cases in which that sort of comment is pretty helpful.
I can see cases in which I'd want to write an application primarily in C++, but it would be a pretty rare thing now. Mostly I see C and C++ as ways to make Python faster when it needs to be.
The garbage collection is nice, yes. But what really draws me to interpreted languages is how easy it is to build programs in tiny little scraps that you independently test along the way. And after that, how some of them allow you to have great economy of expression without being hopelessly obscure.
Do the math. About the only feasible designs for near C craft are ones that rely on being to scoop up interstellar hydrogen and use that. Even antimatter doesn't give you enough energy to be able to manage it.
There are two big problems with traveling that fast. The first is shielding. At really high speeds every stray atom becomes a cosmic ray. The second is the amount of energy and reaction mass needed.
I mean, it could be done so badly, like abstinence-only sex education. But, IMHO, this kind of thing could be handled well and be extremely useful.
Censoring things is the option most people seem to have chosen, and that's a horrible, horrible choice.
Is, to some extant, against the tenants of democracy. My reading on democracy is that there are rules about what people are allowed to do to eachother physically, but no rules about memes. I think it's questionable as to whether using physically coercive means such as taxes to further memetic warfare directed at our own citizens is at all valid within this framework. The government here is trying to enforce rules about memes on its own citizens.