The ugly part is that as long as the transportation needs to be privately owned, where it goes is dependent on market forces. Acording to a book I once read, light rail becomes economical with population densities greater than row-houses. IIRC, it has to do with the distance that people are willing to walk to the transit station. And you need that population density at every place that you put a station, making it infeasible for all but the largest cities.
However, if you allow the rail system to be publically funded, you can make rail/subway/hovertrain possible in less dense areas. The trick is that the environmental benefit is still dramatically less in such cities as it would be in the larger ones.
At the fringes there are really two types of internet service offered: upstream and downstream. Most consumers (individuals) need a lot of downstream and very little upstream. They typically are sold assymetric service that is heavily biased in this direction. My cable connection, for example, gives me ~5Mbps down and 768kbps up. On the flip side are the content providers who typically need a lot of upstream bandwidth and less upstream bandwidth. ISPs have found that these customer are willing/able to pay quite a bit more for their internet connections. Therefore, the law of supply and demand has increased the cost of connections with higher upstream capacity.
Several levels up the ISP heirarchy, however, there are mostly only symmetric lines (T3, OCx,...) providing equal upstream and downstream bandwith. In order to maximize the use of this bandwidth, many providers try to balance the number of content providers with content consumers in order to use the upstream and downstream capacity equally. In theory, this usage should be well balanced by the time it reaches the Teir 1 providers.
The problem we are having right now is caused by Cogent not subscribing to that business model. They have found that the cost to support content consumers is much higher than the cost to support providers. (If for no other reason than there are far more of them.) So, their business model skews heavily towards the provider customers, reducing their operational costs. This, in turn, means that they are able to offer lower costs to those content providers -- in many cases undercutting the other big service providers such as Level 3
This, of course, makes the other providers unhappy because it cuts into their high-yield business. So, occasionally, one of them demands compensation for "transit" instead of providing free peering. They do this because they feel (rightly IMO) that Cogent is able to make more money on these high paying content providers by using an asset owned by the other service providers -- the online customer/consumer base. Basically, Level 3 is telling Cogent that because Cogent is making money by using that virtual asset owned by Level 3, Cogent owes Level 3 some sort of compensation. It is worth noting that several other Teir 1 providers already take this approach with Cogent and Cogent is forced to pay for "transit" service to those providers' customers.
As long as all the Teir 1 providers cooperate, the system works reasonably well. However, in this case, Cogent is trying to take advantage of that informal cooperation to make some extra money. So, they are being capatalists. In this case, capatalism is at odds with cooperation and the system is not working well.
Many people are calling for government regulation to prevent this sort of situation. I expect this to cause some major problems. The issue could be resolved if all the Teir 1 providers would realize that there is a different market value for ingress and outgress traffic. In a free market, I expect that the ingress traffic (corresponding to upstream traffic of content providers from the lower levels) would have substantially more value than the outgress traffic (downstream traffic to consumers). The outgress traffic might even have negative value (meaning that a service provider would charge to take care of it). In the case that two peers balance their traffic well (the ideal cooperative solution) no money needs to change hands. In the other cases (like this one) the ISP with excess outgress usage should probably be charging the one with excess ingress.
Unfortunately, there is no fluidity to the system between the true market (the upstream and downstream bandwidth consumers) and the core market (the Teir 1 providers). If there were, Level 3 could justify their demand for more money based on the value of the traffic they were accepting from lower down the food chain.
would allow me to connect it to an emacsclient session. That way I can take advantage of all the goodies I have loaded into my main emacs session, have seamless integration with my kill and search rings and not take a year and a day (er, 10 seconds) to load.
I can only hope that the interfaces necessary to do this will fall out of this work.
XML - FO - PDF
on
PDF Writers?
·
· Score: 3, Interesting
My current favorite for PDF generation is to build an XML document programatically. This document has no layout information, so I use Saxon and an XSLT stylesheet to translate it to XSL Formatting Objects. From there, I use FOP to translate to PDF.
The best part is that the XML document contains the content, while the XSLT stylesheet describes how to make a document out of it. If I need a screen version all I have to do is write another stylesheet to translate to HTML.
Especially if you are out of warranty. Apple describes it in support article 95039. The most frustrating part is that replacing the power supply is the last step -- they try to replace the CPU before checking the power supply. This means that you have to commit to purchasing a CPU if it is the problem child. My CPU (500Mhz G4) was ~USD900 last time I checked -- more than the value of the the computer at the time. All this is after you pay their diagnostic fee.
Don't get me wrong, Apple Care is wonderful, but once it expires you can be in for some expensive repairs...
Get patent.
If you don't want to deal with steps 2 and 3, assign administration of it to someone who will. (A Free IP Foundation [FIPF?] would be ideal here.)
License it under Intellectual Property GPL (see below).
Don't profit. (This is, after all an open source business model.)
Intellectual Property GPL [IP-GPL](Proposed)
License author INAL
Any serious use of this license should be accompanied by a written admission that the patent owner is behaving moronically.
The patent in question is licensed for free usage by any binary
distributed with a legal copy of all sources or a promise to provide
those sources similar to that found in the GPL.
This license does not follow copies of the binary if they
are provided without full sources as stipulated by this item, even if
such copies are permitted by the code license. All entities using or
distributing such a release are in violation of this license
The owner of the patent in question offers free limited time licenses
to any Non-Open Source Entity [NOSE] willing to release patents under
clause 2 of this license.
The intent here is to prevent the NOSE from using their patents
offensively against open source projects. The time is
limited so that the FIPF can re-assess whether the NOSE has begun to
use patents against the open source community. This also allows a
NOSE to negotiate a patent swap for some of their technology without
giving up all patents, while the FIPF retains the right to re-evaluate
whether the NOSE has begun behaving badly.
I know this is not common, but I had a bad experience with ext3 a few months back that resulted in the first ever time I have had a complete catastrophic data loss without hardware failure.
I'll start with the observed events (the stuff I know that happened):
System crash. Probably one of those that happens when my laptop's flaky power management hardware picks a fight with the kernel
First reboot. fsck runs and claims to be fixing some broken stuff. The box doesn't make it through the init scripts before hitting a busted program
Second reboot. fsck runs and claims to be fixing some broken stuff. The box makes it less far through the init scripts before hitting another (newly) busted program
Third reboot. Kernel cannot find init
Boot from floppy and manually run fsck on the disk. (In retrospect, this was probably not the best of choices.)
Fourth reboot. lilo cannot find the kernel. (Or more appropriately, the kernel cannot make it through its own init.)
Rescue disk, take two. No surviving superblocks to be found on the disk.
The following is my hypothesis as to what was happening at the low level to cause this series of problems. (Note, however, that my knowledge of the ext3 internals is sketchy, so the following is probably somewhere between slightly mistaken and out to pasture in left field.)
System crashes. Data corruption happens. Probably both in the journal file and the superblocks/inodes referring to the journal. Possibly, the magic ext3 bit indicating an active journal on disk is not set properly.
Aparently, fsck.ext2 was running, trying to fix broken file structure, but ended up making changes to the journal itself.
Some brilliant (buggy) piece of software on my poor machine decides to replay the "fixed" journal. Since this is no longer the carefully constructed entry we expect (see #2), this is effectively spitting random information around my hard drive.
I observe still busted machine and think that I should give the restore process another chance. I reboot, effectively returning to step 2.
There is no step 5. The partition has effectively ceased to exist.
Note that I cannot confirm that steps 2 and 3 took place in that order. My guess is that if the journal damage was bad enough, step 2 would not even be necessary (though it was clearly happening). I can only assume that the progressive nature of the failure resulted from data from journal replays between each step #2
My guess is that some buggy/un-updated version of some piece of software was likely to blame. (I was quite a bit behind on my updates.) However, my hypothesis leads me to believe that storing the journal as a file on the journaled filesystem itself is a bad design decision that probably contributed to the extent of data loss on my system.
What about vendor branches in BitKeeper?
on
Missing Kernel Patches
·
· Score: 2, Informative
It seems like it would be trivial for vendors to maintain their patches in their own BitKeeper repository. If done consistently across vendors, it would allow the kernel maintainers to merge patches into the standard distribution with minimal effort.
Moreover, this would probably make it easier for anybody to track different sets of patches. Imagine being able to use an SCM tool to help minimize the pain of tracking patches through several kernel revs. Many of us do this on a daily basis anyways and would love to see such tools used properly in the open source community.
Re:My dream worthless TCP/IP carrier
on
TCP/IP Over HTTP
·
· Score: 1
Actually, I have a friend who used to teach programming in Turkey back in the early days of the 'net. At that time, the entire _country_ was connected to the rest of the net via a 9600 baud link to Germany. The servers on either end would get so backed up that occasionally (every week or two) they would offload the entire mail spool onto tape and snail mail it to the other end where it would be loaded back onto the network.
Slashdot Mirror
I just called and told them that I intend to cancel my account on the day they remove my ability to maintain separate queues.
The ugly part is that as long as the transportation needs to be privately owned, where it goes is dependent on market forces. Acording to a book I once read, light rail becomes economical with population densities greater than row-houses. IIRC, it has to do with the distance that people are willing to walk to the transit station. And you need that population density at every place that you put a station, making it infeasible for all but the largest cities.
However, if you allow the rail system to be publically funded, you can make rail/subway/hovertrain possible in less dense areas. The trick is that the environmental benefit is still dramatically less in such cities as it would be in the larger ones.
At the fringes there are really two types of internet service offered: upstream and downstream. Most consumers (individuals) need a lot of downstream and very little upstream. They typically are sold assymetric service that is heavily biased in this direction. My cable connection, for example, gives me ~5Mbps down and 768kbps up. On the flip side are the content providers who typically need a lot of upstream bandwidth and less upstream bandwidth. ISPs have found that these customer are willing/able to pay quite a bit more for their internet connections. Therefore, the law of supply and demand has increased the cost of connections with higher upstream capacity.
Several levels up the ISP heirarchy, however, there are mostly only symmetric lines (T3, OCx, ...) providing equal upstream and downstream bandwith. In order to maximize the use of this bandwidth, many providers try to balance the number of content providers with content consumers in order to use the upstream and downstream capacity equally. In theory, this usage should be well balanced by the time it reaches the Teir 1 providers.
The problem we are having right now is caused by Cogent not subscribing to that business model. They have found that the cost to support content consumers is much higher than the cost to support providers. (If for no other reason than there are far more of them.) So, their business model skews heavily towards the provider customers, reducing their operational costs. This, in turn, means that they are able to offer lower costs to those content providers -- in many cases undercutting the other big service providers such as Level 3
This, of course, makes the other providers unhappy because it cuts into their high-yield business. So, occasionally, one of them demands compensation for "transit" instead of providing free peering. They do this because they feel (rightly IMO) that Cogent is able to make more money on these high paying content providers by using an asset owned by the other service providers -- the online customer/consumer base. Basically, Level 3 is telling Cogent that because Cogent is making money by using that virtual asset owned by Level 3, Cogent owes Level 3 some sort of compensation. It is worth noting that several other Teir 1 providers already take this approach with Cogent and Cogent is forced to pay for "transit" service to those providers' customers.
As long as all the Teir 1 providers cooperate, the system works reasonably well. However, in this case, Cogent is trying to take advantage of that informal cooperation to make some extra money. So, they are being capatalists. In this case, capatalism is at odds with cooperation and the system is not working well.
Many people are calling for government regulation to prevent this sort of situation. I expect this to cause some major problems. The issue could be resolved if all the Teir 1 providers would realize that there is a different market value for ingress and outgress traffic. In a free market, I expect that the ingress traffic (corresponding to upstream traffic of content providers from the lower levels) would have substantially more value than the outgress traffic (downstream traffic to consumers). The outgress traffic might even have negative value (meaning that a service provider would charge to take care of it). In the case that two peers balance their traffic well (the ideal cooperative solution) no money needs to change hands. In the other cases (like this one) the ISP with excess outgress usage should probably be charging the one with excess ingress.
Unfortunately, there is no fluidity to the system between the true market (the upstream and downstream bandwidth consumers) and the core market (the Teir 1 providers). If there were, Level 3 could justify their demand for more money based on the value of the traffic they were accepting from lower down the food chain.
Wouldn't shutting down the GPS network be an effective terrorist attack.
would allow me to connect it to an emacsclient session. That way I can take advantage of all the goodies I have loaded into my main emacs session, have seamless integration with my kill and search rings and not take a year and a day (er, 10 seconds) to load.
I can only hope that the interfaces necessary to do this will fall out of this work.
My current favorite for PDF generation is to build an XML document programatically. This document has no layout information, so I use Saxon and an XSLT stylesheet to translate it to XSL Formatting Objects. From there, I use FOP to translate to PDF.
The best part is that the XML document contains the content, while the XSLT stylesheet describes how to make a document out of it. If I need a screen version all I have to do is write another stylesheet to translate to HTML.
Especially if you are out of warranty. Apple describes it in support article 95039. The most frustrating part is that replacing the power supply is the last step -- they try to replace the CPU before checking the power supply. This means that you have to commit to purchasing a CPU if it is the problem child. My CPU (500Mhz G4) was ~USD900 last time I checked -- more than the value of the the computer at the time. All this is after you pay their diagnostic fee.
Don't get me wrong, Apple Care is wonderful, but once it expires you can be in for some expensive repairs...
ESOSUMI
- Get patent.
If you don't want to deal with steps 2 and 3, assign administration of it to someone who will. (A Free IP Foundation [FIPF?] would be ideal here.)
- License it under Intellectual Property GPL (see below).
- Don't profit. (This is, after all an open source business model.)
Intellectual Property GPL [IP-GPL] (Proposed)Any serious use of this license should be accompanied by a written admission that the patent owner is behaving moronically.
This license does not follow copies of the binary if they are provided without full sources as stipulated by this item, even if such copies are permitted by the code license. All entities using or distributing such a release are in violation of this license
The intent here is to prevent the NOSE from using their patents offensively against open source projects. The time is limited so that the FIPF can re-assess whether the NOSE has begun to use patents against the open source community. This also allows a NOSE to negotiate a patent swap for some of their technology without giving up all patents, while the FIPF retains the right to re-evaluate whether the NOSE has begun behaving badly.
I know this is not common, but I had a bad experience with ext3 a few months back that resulted in the first ever time I have had a complete catastrophic data loss without hardware failure.
I'll start with the observed events (the stuff I know that happened):
The following is my hypothesis as to what was happening at the low level to cause this series of problems. (Note, however, that my knowledge of the ext3 internals is sketchy, so the following is probably somewhere between slightly mistaken and out to pasture in left field.)
Note that I cannot confirm that steps 2 and 3 took place in that order. My guess is that if the journal damage was bad enough, step 2 would not even be necessary (though it was clearly happening). I can only assume that the progressive nature of the failure resulted from data from journal replays between each step #2
My guess is that some buggy/un-updated version of some piece of software was likely to blame. (I was quite a bit behind on my updates.) However, my hypothesis leads me to believe that storing the journal as a file on the journaled filesystem itself is a bad design decision that probably contributed to the extent of data loss on my system.
It seems like it would be trivial for vendors to maintain their patches in their own BitKeeper repository. If done consistently across vendors, it would allow the kernel maintainers to merge patches into the standard distribution with minimal effort.
Moreover, this would probably make it easier for anybody to track different sets of patches. Imagine being able to use an SCM tool to help minimize the pain of tracking patches through several kernel revs. Many of us do this on a daily basis anyways and would love to see such tools used properly in the open source community.
Actually, I have a friend who used to teach programming in Turkey back in the early days of the 'net. At that time, the entire _country_ was connected to the rest of the net via a 9600 baud link to Germany. The servers on either end would get so backed up that occasionally (every week or two) they would offload the entire mail spool onto tape and snail mail it to the other end where it would be loaded back onto the network.