There's quite a bit of code-sharing between the BSDs. I wouldn't be surprised if you found Theo's name stamped all over parts of FreeBSD. Then again, maybe they dislike him intensely enough that they would rather roll their own than import his code.
I've been flamed by Theo before. IIRC, he accused me of 'having ADD' the last time I spoke with him. It doesn't much change my opinion of the project, or of his abilities, but it suffices to say that talking to him doesn't exactly give me a warm, fuzzy feeling.
BSD has terrible driver support compared to Linux.
My experience has been exactly the opposite. It wasn't until Ubuntu 8.10 came around (having also tried Red Hat and Gentoo) that I found Linux's driver support to be acceptible. By contrast, my OpenBSD installs always worked for me out of the box. The only driver issue that's ever irked me there were USB-serial adapters. But the ease of configuration in OpenBSD has always been great, especially for wireless.
Anyhow, it probably depends on what you're doing, and with what hardware. Just thought I'd throw that out there, though.
That's a good point. I am being thoughtless. Assuming that Darby here is not trolling, well, you're right. I'm wrong.
If someone is honking their horn and flashing their lights, I'll get out of the way. Maybe they really need to get somewhere fast. I have no problems with that. But if Darby needs to think I am
An absolutely vile monster
and that I
fuck people over solely for your sick amusement
well, he's wrong, but then his beliefs are his own business. Can't please everyone. Last I checked, I was talking about being the responsible party. Oh well.
You know, I think I'm going to click that little Slashdot friend button, anyway.
It's funny, when you start living in Boston (as I do), you discover that you even walk down the sidewalk like an asshole. Don't even get me started on the bicycles*.
* Case in point: I once threw a donut at a driver's head (and into his open window) when I was cycling. I had just come out of the shop, got on my bike, and as I'm coming up to the intersection that he's supposed to stop at, this guy looks at me from his van and chooses to cut me off! Man, was he pissed when he got beaned with a donut. Best $0.99 I ever spent.
From a safety standpoint, you are absolutely right. Pulling over is the safest thing to do. In my estimation, if a person is enough of an idiot to go flying down the highway at unsafe speeds, then I probably should get out of their way, because they're clearly not being careful.
But I have to admit, I get a bit of pleasure watching the guy behind me froth at the mouth because I delayed him a few seconds from getting to whatever thing he thinks is important enough that he doesn't mind endangering all the people around him. If someone wants to drive irresponsibly, they're going to have to deal with the fact that other people aren't going to like them for it.
I always wished I had a horn on the back of my car. Or, you know, Spy Hunter oil slicks.
Because lots of people don't want intruders being able to affect the actual zone data in case an outward-facing DNS server gets compromised. Using SSH to transfer zone data is much easier and more secure than BIND's own zone transfer mechanisms (e.g., you can automate and schedule them), and you don't have to worry about zone transfers through firewalls. Troubleshooting all the weird crap that can happen between different DNS daemons all supposedly doing regular AXFRs is a real pain in the ass. SSH makes life easier.
If having a DNS machine on the Internet that thinks it is a master really is a mistake, when then, BIND9 is a piece of shit. This is the most straightforward thing a DNS daemon should be asked to do.
Nowhere in BIND's manual does it say people have to use BIND in a master/slave setup.
Followed by Spaceward Ho!, Escape Velocity, and finally, Sid Meier's F19 Stealth Fighter. Sid did a surprisingly decent remake of Pirates! for XBox, so that takes that one off the list. I remember playing that one originally on a C64.
Water usage is one. Biofuels need an enormous amount of water to grow, process, and refine. There was a water expert at NIST who recently covered this, but the upshot of his presentation was: if you don't address the shortage of clean water before you start producing biofuels, you have a new and serious problem to address. Most of us in the Western world are not accustomed to water shortage, due to our excellent water distribution systems, so we tend not to think about it. If you compare biofuels and petroleum products on the basis of water usage alone, oil wins. Sorry, I don't have the slides, or I would link them.
Food shortage is another. You need to take into account-- at least in the US-- that biofuels compete with food production. This is partially due to entrenched political interests. Again, in the west, this probably didn't affect you (unless you were, say, in the cattle feed market or a small beer producer), but I've read that the grain shortages (and resulting high prices) in Asia last year were the direct result of a double-whammy of biofuel production and crop disease.
Now, I personally don't think that the two things above rule out biofuels as a viable alternative for the future. We just need to be aware that they are not without their consequences; they solve some problems, and introduce new ones.
It's obviously more complicated than that. If I were running Exxon, and literally, this quarter is all that matters, you know what I'd do? I'd sell all of our refineries and derricks to our competitors. Huge influx of cash. Of course, next quarter, you're toast.
Since this is not happening, I think we can conclude that (gee, wow!) even public companies have some ability to think long-term. Shareholders may want ROI, but don't forget that many of them also want ROI over a long term (this is what the term "investment" used to mean, anyway!) They're not going to go charging in, demanding the CEO's head for a bad quarter, or even a few. Public companies are obviously on a tighter profitability leash than a privately-held company, but anyone who thinks that public companies, categorically, aren't capable of real investments is wrong. Intel is a great example of a company that manages to stay competitive (ok, they have some evil tricks, too) precisely because of their long-term investments.
Wow, great post. I gather from what you say that you can have a market that is very liquid, but also very stable (as in, non-volatile). I don't really understand the mechanisms that cause volatility (but I'm a programmer, so that's not surprising). Do you?
This is the thing about the Matrix that I kept thinking about when watching the movie. No whistling IT person (or even robot IT person) cleaning the contacts on the killer robots...
This is really a follow-on to #6, but there's nothing stopping a SaaS vendor from getting you hooked on their service and then jacking up their prices. Adobe uses this strategy. Their early revisions are often cheap, but after a few years, the price is through the roof. Captivate is a good example-- when that came out (from Macromedia), we bought a number of copies for $80 each. 4 years and 3 versions later, Captivate is now more than $800 a copy! Now, since this is pretty much our breaking point, we can go off and find another piece of software that does the same thing. File formats might be a pain to deal with-- but, here's the thing about SaaS-- what if your data is 'in the cloud?'. You're essentially screwed.
This is the thing about SaaS that keep us away. We'd need guarantees that this wouldn't happen. Do you really want to bank your business on someone else's? I don't.
Do you mean that it's sad that we think that or sad that it is the case? Global warming aside, we know that we've "stuffed up" the planet before-- PCBs and other contaminants in drinking water, Chernobyl, acid rain, the ozone hole, and so on. Since we don't know much about this phenomenon, we have to at least ask ourselves whether it is an human-induced phenomenon or a natural one. If we didn't ask the question, we wouldn't be very good scientists. Only through asking the question will we be able to determine whether such a thing really is our fault, and whether that is a phenomenon we can live with.
This isn't quite the same as the telephone network. In the POTS network, you have two end users, each having (at most) one network. Sometimes that network is the same network. If they want to talk, a connection is set up between the two networks at an exchange, and the communication goes forward.
The Internet is vastly more distributed. If you have two VOIP users, you could be traversing a half-dozen networks. In the POTS setup, both networks are motivated to provide a certain quality of service, because they are directly serving their customers (not to mention-- "having a connection" and "not having a connection" are Boolean in POTS). In the Internet example-- the transit networks are not, especially if it competes with their own services or degrades the quality of service for their own customers. Competition (i.e., the "greedy solution" in the algorithmic sense) here makes the problem worse. They are less motivated, especially if they are providing transit for free, as a part of a transit agreement. This is why you see Cogent getting de-peered all the time; other ISPs think Cogent is flooding their networks for little in return to them.
You a little confused about who P2P helps. It helps the distributor, but it most certainly doesn't help the ISP. For the ISP, P2P means more traffic for the same amount of real data. All that data has to flow down their pipe to you, one way or the other, and like it or not, that pipe is shared by you and your neighbors. Take a file that would ordinarily be distributed in large chunks and now spit it up into a zillion pieces and tack headers on every single piece-- the overhead goes way up. That's one of the many reasons why ISPs do not like BitTorrent.
Of course, you omitted the part about how you can only control your egress bandwidth. You have absolutely no traffic shaping ability in TCP/IP for ingress communication except "do I drop this packet or accept it?" Drop enough of those packets, and, if you're using TCP, you have bigger problems.
Provisioning is more complicated than people think. It's not just a matter of overprovisioning to solve congestion issues-- because in datagram networks, congestion starts to happen at 30-40% of capacity. Add in different kinds of communication (short, bursty vs. long, steady), and determining what counts as "overprovisioned" or not is not so clear.
Of course, when you have the router inserting NACKs into the transport stream, you're violating your layers (although it could be argued that they're already violated because congestion avoidance got put into TCP). You're fixing lame congestion control in TCP by breaking IP. Wouldn't it be better to remove congestion control from TCP and put real flow control in IP?
I think the real interesting thing to see happen would be LLC, because then you could run datagrams and virtual circuits on the same wire. But if I understand correctly Ethernet is not capable of doing this.
Well, what the user (where 'user' is more likely the application) should be in control over is the QoS parameters. Like, "I want low jitter, occasional packet loss is OK". Leave the mechanism up to the intermediaries. If someone asks for "all of the above", treat it as invalid input and ignore it, or even better, treat their traffic like shit, since they don't know how to play nice. "Priority" is only one QoS parameter, and one that the end-user should have no control over.
TCP's congestion control backs off exponentially because it has to.
Sure, but it's looking at the problem from the wrong end. IP has no feedback mechanism to allow for flow control (i.e., to prevent the sender from overrunning the receiver), so TCP has congestion control instead to stop it from happening when it does. Since TCP has no way of knowing what the available bandwidth is, it goes looking for it by causing the problem and then backing off. And since packet-switched traffic is "bursty", it resumes increasing the rate until it hits the ceiling again (because maybe you just so happened to have an abnormally low ceiling when you checked before), and backs off, ad infinitum.
This is analogous to saying "I have this problem where cars keep crashing into my house!" and so, designing your house so it can dodge cars.
It just makes the packet switching faster. But really, we're talking about the same idea here: datagram networks. Congestion avoidance has been known to be a difficult problem in datagram networks for a long time.
TCP's congestion control algorithm, which causes congestion and then backs off is the real culprit here, and this router does nothing to fix that. The way to fix that is to dump TCP's congestion control and replace it with real flow control in the network layer. That requires lots of memory on intermediaries, because you need all the hosts along the data path to cooperate with each other to communicate about flow control, and that means keeping state. At which point, we're not talking about datagram networks anymore. And that means dumping the other desirable thing about datagram networks: fault tolerance. Packets are path-independent.
Anyway: getting back to TCP's congestion control: his article even says that "During congestion, it adjusts each flow rate at its input instead." Wait, what? "If an incoming flow has a rate deemed too high, the equipment discards a single packet to signal the transmission to slow down." That's how it works right now! The only difference that I can see is that he's being a little smarter about which packets to discard, unlike RED, which is what he's comparing this to. If so, that's an improvement, but it doesn't solve the problem. It will still take awhile for TCP to notice the problem, because the host has to wait for a missed ACK. TCP can only "see" the other host-- it does not know (or care) about flow control along the path. Solving the problem requires flow control along that path, i.e., in the network layer, but IP lacks such a mechanism.
Slashdot Mirror
There's quite a bit of code-sharing between the BSDs. I wouldn't be surprised if you found Theo's name stamped all over parts of FreeBSD. Then again, maybe they dislike him intensely enough that they would rather roll their own than import his code.
I've been flamed by Theo before. IIRC, he accused me of 'having ADD' the last time I spoke with him. It doesn't much change my opinion of the project, or of his abilities, but it suffices to say that talking to him doesn't exactly give me a warm, fuzzy feeling.
BSD has terrible driver support compared to Linux.
My experience has been exactly the opposite. It wasn't until Ubuntu 8.10 came around (having also tried Red Hat and Gentoo) that I found Linux's driver support to be acceptible. By contrast, my OpenBSD installs always worked for me out of the box. The only driver issue that's ever irked me there were USB-serial adapters. But the ease of configuration in OpenBSD has always been great, especially for wireless.
Anyhow, it probably depends on what you're doing, and with what hardware. Just thought I'd throw that out there, though.
If someone is honking their horn and flashing their lights, I'll get out of the way. Maybe they really need to get somewhere fast. I have no problems with that. But if Darby needs to think I am
An absolutely vile monster
and that I
fuck people over solely for your sick amusement
well, he's wrong, but then his beliefs are his own business. Can't please everyone. Last I checked, I was talking about being the responsible party. Oh well.
You know, I think I'm going to click that little Slashdot friend button, anyway.
Holy shit, that's the first +2 Troll post I've ever seen. Ha ha. The gerbil running SlashCode is totally fucked!
a sick little fucker and beneath contempt
so he might be the kind of friend I get along with.
It's funny, when you start living in Boston (as I do), you discover that you even walk down the sidewalk like an asshole. Don't even get me started on the bicycles*.
* Case in point: I once threw a donut at a driver's head (and into his open window) when I was cycling. I had just come out of the shop, got on my bike, and as I'm coming up to the intersection that he's supposed to stop at, this guy looks at me from his van and chooses to cut me off! Man, was he pissed when he got beaned with a donut. Best $0.99 I ever spent.
From a safety standpoint, you are absolutely right. Pulling over is the safest thing to do. In my estimation, if a person is enough of an idiot to go flying down the highway at unsafe speeds, then I probably should get out of their way, because they're clearly not being careful.
But I have to admit, I get a bit of pleasure watching the guy behind me froth at the mouth because I delayed him a few seconds from getting to whatever thing he thinks is important enough that he doesn't mind endangering all the people around him. If someone wants to drive irresponsibly, they're going to have to deal with the fact that other people aren't going to like them for it.
I always wished I had a horn on the back of my car. Or, you know, Spy Hunter oil slicks.
Because lots of people don't want intruders being able to affect the actual zone data in case an outward-facing DNS server gets compromised. Using SSH to transfer zone data is much easier and more secure than BIND's own zone transfer mechanisms (e.g., you can automate and schedule them), and you don't have to worry about zone transfers through firewalls. Troubleshooting all the weird crap that can happen between different DNS daemons all supposedly doing regular AXFRs is a real pain in the ass. SSH makes life easier.
If having a DNS machine on the Internet that thinks it is a master really is a mistake, when then, BIND9 is a piece of shit. This is the most straightforward thing a DNS daemon should be asked to do.
Nowhere in BIND's manual does it say people have to use BIND in a master/slave setup.
Followed by Spaceward Ho!, Escape Velocity, and finally, Sid Meier's F19 Stealth Fighter. Sid did a surprisingly decent remake of Pirates! for XBox, so that takes that one off the list. I remember playing that one originally on a C64.
Apparently there are a lot of rogue acetylene canisters catching fire in London on a regular basis.
It's not really surprising that their acetylene canisters are catching on fire when you consider their fire extinguishers.
Water usage is one. Biofuels need an enormous amount of water to grow, process, and refine. There was a water expert at NIST who recently covered this, but the upshot of his presentation was: if you don't address the shortage of clean water before you start producing biofuels, you have a new and serious problem to address. Most of us in the Western world are not accustomed to water shortage, due to our excellent water distribution systems, so we tend not to think about it. If you compare biofuels and petroleum products on the basis of water usage alone, oil wins. Sorry, I don't have the slides, or I would link them.
Food shortage is another. You need to take into account-- at least in the US-- that biofuels compete with food production. This is partially due to entrenched political interests. Again, in the west, this probably didn't affect you (unless you were, say, in the cattle feed market or a small beer producer), but I've read that the grain shortages (and resulting high prices) in Asia last year were the direct result of a double-whammy of biofuel production and crop disease.
Now, I personally don't think that the two things above rule out biofuels as a viable alternative for the future. We just need to be aware that they are not without their consequences; they solve some problems, and introduce new ones.
It's obviously more complicated than that. If I were running Exxon, and literally, this quarter is all that matters, you know what I'd do? I'd sell all of our refineries and derricks to our competitors. Huge influx of cash. Of course, next quarter, you're toast.
Since this is not happening, I think we can conclude that (gee, wow!) even public companies have some ability to think long-term. Shareholders may want ROI, but don't forget that many of them also want ROI over a long term (this is what the term "investment" used to mean, anyway!) They're not going to go charging in, demanding the CEO's head for a bad quarter, or even a few. Public companies are obviously on a tighter profitability leash than a privately-held company, but anyone who thinks that public companies, categorically, aren't capable of real investments is wrong. Intel is a great example of a company that manages to stay competitive (ok, they have some evil tricks, too) precisely because of their long-term investments.
Wow, great post. I gather from what you say that you can have a market that is very liquid, but also very stable (as in, non-volatile). I don't really understand the mechanisms that cause volatility (but I'm a programmer, so that's not surprising). Do you?
This is the thing about the Matrix that I kept thinking about when watching the movie. No whistling IT person (or even robot IT person) cleaning the contacts on the killer robots...
Somebody, somewhere, has to do the work.
7) extortion
This is really a follow-on to #6, but there's nothing stopping a SaaS vendor from getting you hooked on their service and then jacking up their prices. Adobe uses this strategy. Their early revisions are often cheap, but after a few years, the price is through the roof. Captivate is a good example-- when that came out (from Macromedia), we bought a number of copies for $80 each. 4 years and 3 versions later, Captivate is now more than $800 a copy! Now, since this is pretty much our breaking point, we can go off and find another piece of software that does the same thing. File formats might be a pain to deal with-- but, here's the thing about SaaS-- what if your data is 'in the cloud?'. You're essentially screwed.
This is the thing about SaaS that keep us away. We'd need guarantees that this wouldn't happen. Do you really want to bank your business on someone else's? I don't.
What if the service provider goes under? Screwed.
Do you mean that it's sad that we think that or sad that it is the case? Global warming aside, we know that we've "stuffed up" the planet before-- PCBs and other contaminants in drinking water, Chernobyl, acid rain, the ozone hole, and so on. Since we don't know much about this phenomenon, we have to at least ask ourselves whether it is an human-induced phenomenon or a natural one. If we didn't ask the question, we wouldn't be very good scientists. Only through asking the question will we be able to determine whether such a thing really is our fault, and whether that is a phenomenon we can live with.
It's not piss. It's chubby rain.
This isn't quite the same as the telephone network. In the POTS network, you have two end users, each having (at most) one network. Sometimes that network is the same network. If they want to talk, a connection is set up between the two networks at an exchange, and the communication goes forward.
The Internet is vastly more distributed. If you have two VOIP users, you could be traversing a half-dozen networks. In the POTS setup, both networks are motivated to provide a certain quality of service, because they are directly serving their customers (not to mention-- "having a connection" and "not having a connection" are Boolean in POTS). In the Internet example-- the transit networks are not, especially if it competes with their own services or degrades the quality of service for their own customers. Competition (i.e., the "greedy solution" in the algorithmic sense) here makes the problem worse. They are less motivated, especially if they are providing transit for free, as a part of a transit agreement. This is why you see Cogent getting de-peered all the time; other ISPs think Cogent is flooding their networks for little in return to them.
You a little confused about who P2P helps. It helps the distributor, but it most certainly doesn't help the ISP. For the ISP, P2P means more traffic for the same amount of real data. All that data has to flow down their pipe to you, one way or the other, and like it or not, that pipe is shared by you and your neighbors. Take a file that would ordinarily be distributed in large chunks and now spit it up into a zillion pieces and tack headers on every single piece-- the overhead goes way up. That's one of the many reasons why ISPs do not like BitTorrent.
Of course, you omitted the part about how you can only control your egress bandwidth. You have absolutely no traffic shaping ability in TCP/IP for ingress communication except "do I drop this packet or accept it?" Drop enough of those packets, and, if you're using TCP, you have bigger problems.
Provisioning is more complicated than people think. It's not just a matter of overprovisioning to solve congestion issues-- because in datagram networks, congestion starts to happen at 30-40% of capacity. Add in different kinds of communication (short, bursty vs. long, steady), and determining what counts as "overprovisioned" or not is not so clear.
Of course, when you have the router inserting NACKs into the transport stream, you're violating your layers (although it could be argued that they're already violated because congestion avoidance got put into TCP). You're fixing lame congestion control in TCP by breaking IP. Wouldn't it be better to remove congestion control from TCP and put real flow control in IP?
I think the real interesting thing to see happen would be LLC, because then you could run datagrams and virtual circuits on the same wire. But if I understand correctly Ethernet is not capable of doing this.
Well, what the user (where 'user' is more likely the application) should be in control over is the QoS parameters. Like, "I want low jitter, occasional packet loss is OK". Leave the mechanism up to the intermediaries. If someone asks for "all of the above", treat it as invalid input and ignore it, or even better, treat their traffic like shit, since they don't know how to play nice. "Priority" is only one QoS parameter, and one that the end-user should have no control over.
TCP's congestion control backs off exponentially because it has to.
Sure, but it's looking at the problem from the wrong end. IP has no feedback mechanism to allow for flow control (i.e., to prevent the sender from overrunning the receiver), so TCP has congestion control instead to stop it from happening when it does. Since TCP has no way of knowing what the available bandwidth is, it goes looking for it by causing the problem and then backing off. And since packet-switched traffic is "bursty", it resumes increasing the rate until it hits the ceiling again (because maybe you just so happened to have an abnormally low ceiling when you checked before), and backs off, ad infinitum.
This is analogous to saying "I have this problem where cars keep crashing into my house!" and so, designing your house so it can dodge cars.
It just makes the packet switching faster. But really, we're talking about the same idea here: datagram networks. Congestion avoidance has been known to be a difficult problem in datagram networks for a long time.
TCP's congestion control algorithm, which causes congestion and then backs off is the real culprit here, and this router does nothing to fix that. The way to fix that is to dump TCP's congestion control and replace it with real flow control in the network layer. That requires lots of memory on intermediaries, because you need all the hosts along the data path to cooperate with each other to communicate about flow control, and that means keeping state. At which point, we're not talking about datagram networks anymore. And that means dumping the other desirable thing about datagram networks: fault tolerance. Packets are path-independent.
Anyway: getting back to TCP's congestion control: his article even says that "During congestion, it adjusts each flow rate at its input instead." Wait, what? "If an incoming flow has a rate deemed too high, the equipment discards a single packet to signal the transmission to slow down." That's how it works right now! The only difference that I can see is that he's being a little smarter about which packets to discard, unlike RED, which is what he's comparing this to. If so, that's an improvement, but it doesn't solve the problem. It will still take awhile for TCP to notice the problem, because the host has to wait for a missed ACK. TCP can only "see" the other host-- it does not know (or care) about flow control along the path. Solving the problem requires flow control along that path, i.e., in the network layer, but IP lacks such a mechanism.
is that men will have sex with women that they don't find attractive.
Of course, this fact may only be surprising to you if you are not a man.