The "5 minute convienience" of gasoline is a superficial crutch of the lazy who can't be bothered to plug their can in while at work or at home.
Because of course people only ever need to refuel their vehicle at work or at home, right? Nobody ever travels, trucks don't drive long distance, taxis don't drive all day, etc.
Hey, don't knock Alabama. A friend of mine had two motorcycles with personalized tags: GTFA and FYYFF. He made up alternate versions of what they stood for (they asked when he registered them).
There are advantages to having some things integrated at the filesystem layer instead of at the block layer. For example, creating a snapshot of an AdvFS fileset uses the free space in the fileset to store the changes, instead of having to have an otherwise unavailable chunk of the block device reserved in case I want a snapshot (and I can create snapshots of multiple filesets simultaneously without having a bunch of chunks of reserved space). The combination of file domains and filesets in AdvFS is useful; you can have multiple (otherwise distinct) filesets share the available space in a file domain. This is useful for using a large chunk of space but having distinct user/group quotas, inums, etc.
AdvFS also has been the basis for the TruCluster single system image clustering OS for years. In a TruCluster setup, you have one root filesystem that is shared throughout the cluster (vs. most cluster setups where each cluster member has its own root/OS filesystem and just shares some of the data). Combined with inode versioning, this allows rolling updates of the OS; our two member cluster was up for about 4 years until we had two separate failures at the same time.
AdvFS has its warts (just like all filesystems and OSes for that matter), but it is very useful in its places. It is also a very proven system (having been around in production use since about the same time Linux first started, with one major version update in around 2000 IIRC). I don't really see how some of the good and useful things you can do with AdvFS can be done without some type of "layering violation" or two-way communication between the VFS and the block layer.
Now, if someone would just port AdvFS to Linux so I can migrate my data to ext3/4 a whole lot easier (no matter how good it is, AdvFS and Tru64 are a dead end).
Properly designed systems should never result in any fault to become uncontained in this manner. That's nice in theory, but this is the real world. I live in Huntsville, Alabama, and we had a power failure a couple of weeks ago when the water treatment facility had a power problem that resulted in a fire, blowing a transformer, and taking a whole substation (that feeds a big chunk of the south end of town) off-line (and leaving us without 36 million gallons per day of water pumping capacity as well). Basically, you can design and plan all you like, but unexpected stuff still happens and causes bigger problems than you ever expected.
When the Linux kernel first supported multiprocessor systems, it was done with a single lock protecting access to all the kernel (the Big Kernel Lock); the kernel could still only do one thing at a time. Over time, most sections of the kernel have introduced their own fine-grained locking and moved out from under the BKL, allowing many parts of the kernel to be running at the same time on multiple processors. The BKL has shrunk over time, but it still exists over a chunk of the kernel. The kernel hackers recently tried to replace the hard lock with a preemptable lock, but that had some bad interactions with the scheduler (which determines what process/kernel thread runs when), so Linus switched back to the old-style BKL.
Now, a group is trying to see if it is possible to weed out all the remaining uses of the BKL and replace them with localized locking for specific sections of the kernel. This is tricky, as there are side-effects of the BKL that are not always obvious.
For the origin of that range to get as far as they have, they clearly had paperwork to prove to their upstream that the range is assigned to them. Except they don't. The IANA/ARIN records for that block show it being assigned to SF Bay Packet Radio in 1999. However, the nameservers appear to have been changed in October 2007 to sfbprservices.com, which is then registered by Media Breakaway (trying to pretend to be the original owner). Apparently, their upstreams (Level3, Cogent, and XO) did not do any checking, nor are they doing proper route filtering. IIRC all three of those companies are hurting finacially, so they probably just looked the other way because they need the money.
Equal cost multipath is rarely used in large Internet routers because even that decreases the packets-per-second throughput of the router. Also, using a hash is not the same as tracking flows; an individual TCP connection flow will always take the same path (unless the routes change) because the hash is always the same (but the hash is not stored anywhere). For the "flow management" scheme to work, the router actually has to keep track of all active flows to know which ones are eligible for packet drops. The RAM used for router forwarding tables is also not cheap because it is not normal RAM, it is TCAM. You'd have to have a lot more TCAM to store enough information about all active flows (since you would need to track at least an order of magnitude more flows the forwarding entries, and each flow entry would be several times as large as a forwarding entry).
Ahh, the Customer Enragement Feature. It isn't a table of "recent connections" or really any kind of cache. CEF builds a forwarding table from the routing table; the forwarding table has all routes resolved to the next-hop interface. When there is a routing table update, a CEF forwarding table update is also made; the CEF forwarding table has just as many entries as the routing table. CEF has nothing to do with flows or connections.
Netflow/Jflow are for statistics, and on the larger routers, they are just sampled (not every packet/flow is monitored, just one out of every N packets). Originally netflow could be used as a packet switching method on Cisco, but it is just for statistics now.
Overhead. Right now, routers just track individual packets: receive a packet, look up the next-hop IP in the forwarding table (which might have 250,000 entries), and send it on its merry way. To do anything based on flows, routers would have to keep track of all the active flows, which amounts to all open TCP connections going through that router. For an active router, there would be millions of active flows at any one time, so the overhead would be huge. This would be like a NAT or stateful firewall device that could do line-rate forwarding at gigabit, 10G, or 100G port speeds.
You also have problems tracking flows; routes change, so while a router may be tracking an active flow, the flow may choose another path. The router has no way of knowing this, so it has to keep track of the flow until it times out (and the timeout would have to be more than just a few seconds).
There are flow-based router architectures, but they are not generally used for ISP core/edge routers because there are too many ways they can break.
Air heat transfer is not that good, and you can't just pipe in outside air to cool the data center (due to dust and humidity control), so it doesn't generally work out that a cool outside climate lowers cooling costs significantly. If you compared it to some place with high (35C) normal temperatures, it might make enough of a difference (because standard air conditioning efficiency does drop off in that range IIRC), but that is not most of the US. Also, 50% of power going to cooling is not representative; it should be down closer to 35% from what I remember of our numbers (and we're in a location with relatively hot summers). Our electric rates are also already pretty cheap; commercial rates can go as low as 4.721 cents per kilowatt hour (plus a demand charge).
Yes, the network is oversold; the Internet (and packet-switched networks in general) is designed around the assumption that nobody uses 100% of their bandwidth 100% of the time. We could go back to circuit-switched networks, but who wants to pay $1000+/month for residential Internet access?
In Comcast's case though, the problem is the design of the cable modem network protocols. There are a limited number of channels available for upstream bandwidth, and they have to be shared among all users on a segment. Comcast could put just one user per segment, but again the cost would be many times what they charge today (because of the significant increase in equipment and management costs). The newest version of the protocol (DOCSIS 3.0) allows for more upstream bandwidth, but they're going to have to spend a significant amount of money to upgrade (and in some cases replace) all of their existing equipment to take advantage of the new version.
It is less than one watt of extra metabolic power when braking. I would assume (without RTFA) that this is analogous to regenerative braking in electric/hybrid cars.
Where do you get that "gasoline's upper limit is 10 to 1 in a production vehicle that has to be warrantied"? The Honda S2000 has had engines with 11 to 1 compression for years now (and I don't think they are the only high-compression engine sold).
I think all versions of JUNOS allow individual processes to be restarted. Different versions have different processes (for example, PPP is in the kernel for most versions, but it is being moved to a user-space process). Juniper also already works with third-parties for hardware. For example, on the J-series, you can get a PIM that has an Avaya PBX in a slot.
I also wonder: Red Hat, why? The article says the patched kernel is not available via Red Hat's normal support channels, but it doesn't say who is distributing a patched kernel (or requiring an NDA) at all. Red Hat may not even be involved (since the RHEL kernel source is available, anyone could build patched kernels).
Those would be some pretty big worms, to be making holes that would move these rocks. Was there a nuclear plant nearby, leaking radiation and creating mutant giant rock-moving worms?
Do you really want to pay $400+/month for a 3 meg guaranteed-bandwidth DSL? I just got a quote for a high-speed link from a "top tier" backbone provider. I can get high-quality backbone bandwidth for about $30/meg/month, but then it costs about the same for the loop to carry that bandwidth to my network facility. Customers expect ISPs to have network redundancy, so to sell that 3 meg DSL I have to pay $360/month for 3 meg of Internet bandwidth to two backbones. I also have to pay the telco for the DSL loop, somewhere between $15 and $40 (depending on speed, location, and telco). Oh yeah, and I have to buy routers, servers, spares, and pay support/maintenance costs for all of the above. It'd also be good to pay the employees, and there's not much incentive to sell this if I don't at least make a small amount of profit on each customer.
Even if you oversell the redundant Internet connection to 100%, you are looking at over $200 in fixed costs per customer to guarantee 3 meg (not including the ISP infrastructure, employees, and any profit).
Nobody really wants ISPs to be common carriers. Part of being a common carrier is that you are required to be content-agnostic. Think about what the Internet would be like if ISPs couldn't block customers for spamming, spreading worms, DoS attacks, etc.
IIRC, when a subpoena is issued for information from a third party, that party can charge a fee to cover the costs of gathering the requested information.
You've successfully spoofed an IP address not on your network for a TCP connection to a file sharing program? I expect a lot of people would be interested in knowing how you did that; it is far from easy.
You chose a poor example. While Windows and other OSes used the BSD IP stack (legally under the BSD license), the Linux stack was written from scratch. At the time, the BSD code was under the old 4 clause BSD license (with the advertising clause), which is not compatible with the GPL.
Slashdot Mirror
The "5 minute convienience" of gasoline is a superficial crutch of the lazy who can't be bothered to plug their can in while at work or at home.
Because of course people only ever need to refuel their vehicle at work or at home, right? Nobody ever travels, trucks don't drive long distance, taxis don't drive all day, etc.
Hey, don't knock Alabama. A friend of mine had two motorcycles with personalized tags: GTFA and FYYFF. He made up alternate versions of what they stood for (they asked when he registered them).
There are advantages to having some things integrated at the filesystem layer instead of at the block layer. For example, creating a snapshot of an AdvFS fileset uses the free space in the fileset to store the changes, instead of having to have an otherwise unavailable chunk of the block device reserved in case I want a snapshot (and I can create snapshots of multiple filesets simultaneously without having a bunch of chunks of reserved space). The combination of file domains and filesets in AdvFS is useful; you can have multiple (otherwise distinct) filesets share the available space in a file domain. This is useful for using a large chunk of space but having distinct user/group quotas, inums, etc.
AdvFS also has been the basis for the TruCluster single system image clustering OS for years. In a TruCluster setup, you have one root filesystem that is shared throughout the cluster (vs. most cluster setups where each cluster member has its own root/OS filesystem and just shares some of the data). Combined with inode versioning, this allows rolling updates of the OS; our two member cluster was up for about 4 years until we had two separate failures at the same time.
AdvFS has its warts (just like all filesystems and OSes for that matter), but it is very useful in its places. It is also a very proven system (having been around in production use since about the same time Linux first started, with one major version update in around 2000 IIRC). I don't really see how some of the good and useful things you can do with AdvFS can be done without some type of "layering violation" or two-way communication between the VFS and the block layer.
Now, if someone would just port AdvFS to Linux so I can migrate my data to ext3/4 a whole lot easier (no matter how good it is, AdvFS and Tru64 are a dead end).
When the Linux kernel first supported multiprocessor systems, it was done with a single lock protecting access to all the kernel (the Big Kernel Lock); the kernel could still only do one thing at a time. Over time, most sections of the kernel have introduced their own fine-grained locking and moved out from under the BKL, allowing many parts of the kernel to be running at the same time on multiple processors. The BKL has shrunk over time, but it still exists over a chunk of the kernel. The kernel hackers recently tried to replace the hard lock with a preemptable lock, but that had some bad interactions with the scheduler (which determines what process/kernel thread runs when), so Linus switched back to the old-style BKL.
Now, a group is trying to see if it is possible to weed out all the remaining uses of the BKL and replace them with localized locking for specific sections of the kernel. This is tricky, as there are side-effects of the BKL that are not always obvious.
... but the software is considered property of the State of California So, BSD license then. That can still be used under the GPL.Equal cost multipath is rarely used in large Internet routers because even that decreases the packets-per-second throughput of the router. Also, using a hash is not the same as tracking flows; an individual TCP connection flow will always take the same path (unless the routes change) because the hash is always the same (but the hash is not stored anywhere). For the "flow management" scheme to work, the router actually has to keep track of all active flows to know which ones are eligible for packet drops. The RAM used for router forwarding tables is also not cheap because it is not normal RAM, it is TCAM. You'd have to have a lot more TCAM to store enough information about all active flows (since you would need to track at least an order of magnitude more flows the forwarding entries, and each flow entry would be several times as large as a forwarding entry).
Ahh, the Customer Enragement Feature. It isn't a table of "recent connections" or really any kind of cache. CEF builds a forwarding table from the routing table; the forwarding table has all routes resolved to the next-hop interface. When there is a routing table update, a CEF forwarding table update is also made; the CEF forwarding table has just as many entries as the routing table. CEF has nothing to do with flows or connections.
Netflow/Jflow are for statistics, and on the larger routers, they are just sampled (not every packet/flow is monitored, just one out of every N packets). Originally netflow could be used as a packet switching method on Cisco, but it is just for statistics now.
Overhead. Right now, routers just track individual packets: receive a packet, look up the next-hop IP in the forwarding table (which might have 250,000 entries), and send it on its merry way. To do anything based on flows, routers would have to keep track of all the active flows, which amounts to all open TCP connections going through that router. For an active router, there would be millions of active flows at any one time, so the overhead would be huge. This would be like a NAT or stateful firewall device that could do line-rate forwarding at gigabit, 10G, or 100G port speeds.
You also have problems tracking flows; routes change, so while a router may be tracking an active flow, the flow may choose another path. The router has no way of knowing this, so it has to keep track of the flow until it times out (and the timeout would have to be more than just a few seconds).
There are flow-based router architectures, but they are not generally used for ISP core/edge routers because there are too many ways they can break.
Air heat transfer is not that good, and you can't just pipe in outside air to cool the data center (due to dust and humidity control), so it doesn't generally work out that a cool outside climate lowers cooling costs significantly. If you compared it to some place with high (35C) normal temperatures, it might make enough of a difference (because standard air conditioning efficiency does drop off in that range IIRC), but that is not most of the US. Also, 50% of power going to cooling is not representative; it should be down closer to 35% from what I remember of our numbers (and we're in a location with relatively hot summers). Our electric rates are also already pretty cheap; commercial rates can go as low as 4.721 cents per kilowatt hour (plus a demand charge).
Yes, the network is oversold; the Internet (and packet-switched networks in general) is designed around the assumption that nobody uses 100% of their bandwidth 100% of the time. We could go back to circuit-switched networks, but who wants to pay $1000+/month for residential Internet access?
In Comcast's case though, the problem is the design of the cable modem network protocols. There are a limited number of channels available for upstream bandwidth, and they have to be shared among all users on a segment. Comcast could put just one user per segment, but again the cost would be many times what they charge today (because of the significant increase in equipment and management costs). The newest version of the protocol (DOCSIS 3.0) allows for more upstream bandwidth, but they're going to have to spend a significant amount of money to upgrade (and in some cases replace) all of their existing equipment to take advantage of the new version.
It is less than one watt of extra metabolic power when braking. I would assume (without RTFA) that this is analogous to regenerative braking in electric/hybrid cars.
Where do you get that "gasoline's upper limit is 10 to 1 in a production vehicle that has to be warrantied"? The Honda S2000 has had engines with 11 to 1 compression for years now (and I don't think they are the only high-compression engine sold).
I think all versions of JUNOS allow individual processes to be restarted. Different versions have different processes (for example, PPP is in the kernel for most versions, but it is being moved to a user-space process). Juniper also already works with third-parties for hardware. For example, on the J-series, you can get a PIM that has an Avaya PBX in a slot.
I also wonder: Red Hat, why? The article says the patched kernel is not available via Red Hat's normal support channels, but it doesn't say who is distributing a patched kernel (or requiring an NDA) at all. Red Hat may not even be involved (since the RHEL kernel source is available, anyone could build patched kernels).
Those would be some pretty big worms, to be making holes that would move these rocks. Was there a nuclear plant nearby, leaking radiation and creating mutant giant rock-moving worms?
Do you really want to pay $400+/month for a 3 meg guaranteed-bandwidth DSL? I just got a quote for a high-speed link from a "top tier" backbone provider. I can get high-quality backbone bandwidth for about $30/meg/month, but then it costs about the same for the loop to carry that bandwidth to my network facility. Customers expect ISPs to have network redundancy, so to sell that 3 meg DSL I have to pay $360/month for 3 meg of Internet bandwidth to two backbones. I also have to pay the telco for the DSL loop, somewhere between $15 and $40 (depending on speed, location, and telco). Oh yeah, and I have to buy routers, servers, spares, and pay support/maintenance costs for all of the above. It'd also be good to pay the employees, and there's not much incentive to sell this if I don't at least make a small amount of profit on each customer.
Even if you oversell the redundant Internet connection to 100%, you are looking at over $200 in fixed costs per customer to guarantee 3 meg (not including the ISP infrastructure, employees, and any profit).
Nobody really wants ISPs to be common carriers. Part of being a common carrier is that you are required to be content-agnostic. Think about what the Internet would be like if ISPs couldn't block customers for spamming, spreading worms, DoS attacks, etc.
IIRC, when a subpoena is issued for information from a third party, that party can charge a fee to cover the costs of gathering the requested information.
I'll be able to get my genuine Klein Bottle!
OS 5 can't be but half as good as OS X!
You've successfully spoofed an IP address not on your network for a TCP connection to a file sharing program? I expect a lot of people would be interested in knowing how you did that; it is far from easy.
You chose a poor example. While Windows and other OSes used the BSD IP stack (legally under the BSD license), the Linux stack was written from scratch. At the time, the BSD code was under the old 4 clause BSD license (with the advertising clause), which is not compatible with the GPL.