For every 'yank' performed on the cable, you pull the anchor lower in orbit.
This is wrong - the transmitting end (ground station) can and would "push" just as readily as it would "pull". Then the vehicle would absorb this wavefront as it converts it to potential energy, such that there is very little energy propagating past it up the cable. You have to consider that this cable is very very long, and at such a scale it becomes more like a slinky, or a piece of string with a cup on each end.
Consider how much energy it would take to move this massively long cable. There is no way in hell that is going to be efficient. You're going to be wasting a massive amount of energy as you move the entire cable the whole time the thing is climbing.
That was my initial reaction too, but then I thought about it for a minute and it occurred to me that this is probably analogous to an electrical/RF transmission line. The cable has some (very low) impedance in the sense that it is quite rigid, but it's not zero. You're not "moving the whole cable" by jerking on it, what you're really doing is transmitting a wavefront along a medium. Provided the whole system is impedance matched, nearly all the power could be delivered to the vehicle.
I'm not sure how well this holds up when you consider internal friction of the cable and other inefficiencies, but I wouldn't dismiss it off hand. The simplicity of it in that it works purely on kinetic energy makes it pretty intriguing. It may even have applications besides a space elevator.
Apple's GS/OS had FSTs (File System Translators) that allowed that operating system to access HFS, ProDOS, DOS 3.3, and FAT volumes. How does FUSE compare in function to GS/OS's FSTs? You know, apart from working with non-obsolete hardware.
Fuse is not a file system or even a translation layer per se. It's just a way to let you run a filesystem in userspace, instead of inside the kernel where it would normally reside.
This is slower, but has many benefits including easy development/debugging, not requiring access to kernel sources or rebuilding of the kernel, and easy portability of these filesystems to run atop different host OSes. It also gives the "guest" file system access to all the features of userland, making it easy to, for example, launch a process to convert a file or establish a TCP connection somewhere.
GS/OS was very primitive by todays standards and did not even have a "user space" to speak of - there was no preemptive multitasking or protected memory, so FST was not some significant architectural paradigm - just that the OS knew how to read more than one kind of disk. It's not really comparable to fuse, although it is comparable to some of the things you can do with fuse.
Look around for other projects that use fuse. There's some interesting stuff you can do with it. To give you an idea, years ago somebody did a filesystem which would make a bunch of audio files in a variety of formats all appear to be.MP3 files. When you view the directories all that's happening is the extensions are being changed, but then when you open one, he would transparently launch a decoder in the background to convert the file.
You could also do things like making a remote FTP site appear as a normal file system... all kinds of stuff.
I am not an economist but I have owned a couple businesses and consider myself a reasonably practical person.
I have always believed that the vast majority of today's financial instruments have been invented out of thin air for no reason other than to ultimately ensure the employment of bankers and brokers.
For example, lots of people have a checking account, savings account, credit card, poersonal line of credit, HELOC, brokerage account, and more. I see absolutely no reason why a single account could not offer all those features. The only reason you "need" all that is because the banks created all these funny rules so that they could introduce more and more products and services. This is done so they can charge you more for each of those things, and also to differentiate them from their competitors.
Besides consumer banking, can somebody explain to me why we NEED "commercial paper"? Yes, I've read the wikipedia page and I know how it's used, but I don't understand why it's needed. If you can't make payroll then you're pulling from your credit one way or another - why do we need separate instruments for a 2 week loan versus a longer term loan, or a credit card, or whatever?
And don't even get me started on real estate lending...
It's like freaking starbucks - you can get your banking services just as special as an upside-down triple no foam half calf non fat 160 degree two splenda mocha. But it's one thing for a coffee company to cater to every individual snowflake's desire, and quite another IMHO for something as important as our financial system to become as absurdly complex and fragile as it is.
As for the people who are really benefitting from all this complexity - well, it's only during recession that we all collectively take a good hard look at who's making a contribution to society and who isn't. Unfortunately the powers that be think they can beat a recession by tweaking some rates, stealing from taxpayers, or shuffling money from one hand to the other. That's just going to hurt us more in the long term. We need to clean this shit up now - get rid of unnecessary products and overhead, and let the unproductive companies go bankrupt. Let the UAW strangle themselves to death. Just get it done.
A standard outlet delivers at most enough power to run a vacuum cleaner. At that rate, you're going to be recharging for something on the order of one hour for each mile driven. Maybe they can charge from a regular outlet in case of emergency, but that would not be suitable for daily recharging.
This is a little OT but I figure someone here might know. With so many electric cars finally coming to market I thought it would be smart to plan ahead even if I'm not ready to take the leap yet...
So, I'm in the process of a remodel and have an easy opportunity to install a high-amperage electric circuit to some location in the garage. Is there any emerging standard for charging electric cars that would dictate the ideal location to put the outlet? I.e. in front of the car, driver side, passenger side, what height from ground, etc. Also amperage, type of plug etc would be good to anticipate, although initially I'd just have an empty conduit running there from the load center.
Well, yes. All of the e-commerce sites I've worked on had in-house or outsourced phone staff. But my point is that a site must have some sort of failure mode. Whether it's to call customer service, give free or flat shipping, or whatever, it's better that the customer can complete the sale than see an arcane error message that the system has failed.
You're missing the point - your rate calculator should not even be such a point of failure in the first place. If you do the calculation yourself then it is not dependent on internet connectivity or the shipper's server being responsive.
Re:Crashing Web store applications?
on
USPS Server Meltdown
·
· Score: 2, Informative
Most e-commerce sites, including the ones I've built, have a multi-step process to place an order. If the step for shipping (or tax, etc.) failed, then the system would re-load the page with any appropriate messages and option changes. So, for example, if the third-party payment processing service didn't respond before a timeout the user would be asked to call customer service to complete their order. The sales rep could see the order in its incomplete state and finish it over the phone.
I would not consider that an acceptable failure mode. I think you overestimate the patience of the online shopper - you would lose a lot of sales making them jump through hoops like that. Not to mention, who are all these sales guys that you'll have on staff ready to take calls- are you going to pay them to sit there even while the web site is working?
And what happens when they change those tables? Sounds like you're asking for a world of business hurt down the road with the costs to update the code and cover the changed price.
The tables don't change very often. When they need to do a quick rate bump it is usually in the form a simple "fuel surcharge". Even when the tables are updated, it can usually be very closely approximated by applying a simple percentage increase.
Also, most sites put a significant markup on shipping (that's the "handling" part), so small changes aren't important. We applied different markups of our own depending on the shipping rate and destination, and in some cases we even discounted shipping and ate the difference in order to promote sales in areas where the shipping cost would otherwise be prohibitive, such as the Nordic countries.
But even when you're setting your own rates to some degree, the tables are still needed because of big disparities due to geography, particularly when dealing with foreign countries. However, any particular destinations don't fluctuate much relative to each other, they pretty much all move together. So you can easily go a few years between updating the tables, just applying percentage modifiers as needed.
Re:Crashing Web store applications?
on
USPS Server Meltdown
·
· Score: 4, Interesting
Only a really terrible developer would hit a web services API and not code for it to fail. No one should expect a third party service to be up 100%. The apps should fail gracefully. Anyone finding their e-commerce software handling this situation poorly should find another package.
I have developed a fulfillment system using UPS so I have some experience with this. This was a few years ago, but at the time, UPS's system was designed on the assumption that a shopping cart system would contact UPS during the order placement process (or checkout). USPS appears to be very similar. This is incredibly moronic, because it means that if their server doesn't respond or any reason, you simply lose the sale. Problems AFTER the order has been accepted are far less serious - that just means fulfillment is interrupted - you don't lose orders. It would be even better if you could print the labels without having to reach their server, but they don't provide this (UPS's own software, however, can.)
The only reasonable way to do it (obviously?) is to have your own shopping cart software calculate the shipping rate. At the time I did this in 2001, UPS did not offer reasonable data to let you do this. Their rating system is extremely complicated, and the spreadsheets they gave me had clearly been maintained by hand and needed a lot of massage to get them into a reasonably parseable format. Not only that but it was very difficult to get these tables in the first place, requiring multiple escalations through tech reps and ultimately a "god damn it just give him the tables" from our sales rep.
I imagine things might have improved a little since then and I know there are shopping carts that can now do the rate calculations internally. But if any shipping company forces its customers to contact a server to calculate shipping costs, then they are just as retarded as the merchants who use them (for a web checkout).
The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.
That statement makes no sense whatsoever. It's the same as saying "IP doesn't play as nicely as TCP". They are not comparable.
You have to be talking about whatever transfer protocol might be implemented ON TOP OF UDP, because UDP is merely a datagram protocol. It's nothing more than an IP packet plus port numbers.
In other words, I could write a simple program which blindly fires UDP packets at the rate of 1GB/s. This would kill my internet connection. I could also write a program which transmits one UDP packet per hour. This would have no effect. See what I mean? It's entirely a function of the application.
Detecting maximum throughput via packet dropping is really bad in high-latency links and in applications that need low latency.
I disagree. Please be more specific. First, what exactly do you believe is the problem? Secondly, how else would you do it (on an IP network)?
It is also apparently easy to implement TCP in such a way that overall transfer speed takes a nosedive when latency gets high, as evinced by Microsoft having done just that.
So you're saying it's possible to implement it with a bug? I've recently found a heinous bug in a recent Redhat kernel which would result in _deadlocked_ TCP connections. It happens to the best of us.
BT may have the best of intentions here in developing this experimental protocol, but this quote leads me to believe that their understanding of the problem is terribly naive:
It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once "packet loss" has occurred - i.e. once the user has lost data and (probably) noticed there is a problem.
Packet loss is a normal and deliberate mechanism by which TCP detects the maximum thoughput of a path. Periodically it increases the number of packets in flight until the limit is reached, then it backs off. You have to test again from time to time, in order to increase throughput if more capacity becomes available. This in no way incurs "loss of data" or a noticeable problem. Packets lost due to congestion window growth are handled by the fast retransmit algorithm, which means that there is no timeout or drop in throughput (that would be pretty stupid if the whole purpose of growing the congestion window is to _maximize_ throughput).
I wonder if Simon Morris was merely oversimplifying for the benefit of the layman, but I still find that statement disturbing. As I sugggested in the other thread, it really sounds like they're going to reinvent TCP (poorly). That's not to say you couldn't design a better protocol specifically for point-to-multipoint transfer, but I question if they're on the right track here.
If I pay for 10Mbps download speed, it should not matter to anyone how I use those bits. If you as my ISP cannot handle that traffic, you should NOT have sold it to me in the first place
You have totally missed the point of my post! I wasn't even addressing ISP billing policy, I am talking about how to share a link. Maybe YOU have a dedicated 10Mbps link all to yourself, but not everyone is so lucky. Imagine a small business where 50 people are sharing a T1 line. For web browsing, this many users could all get decent performance, even if a handful of people are doing big downloads, provided they are all using TCP. But all it takes is one guy hammering the link at full throttle to ruin it for everyone else. For better or worse, the internet is designed on the assumption that applications play nicely in this regard.
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine. That's just a consequence of the way Bittorrent works.
That behavior needs to be driven by some timing and retry logic. Also, hosts need to determine how fast they can fire these UDP packets at each other. Those are the most basic fundamentals of transmitting bulk data over a packet network. You really would be reinventing some subset of TCP.
obviously, metering of bandwidth should be by subscriber according to money paid, not by some arbitrary and easily manipulated value like number of open TCP connections.
It's not just about metering. What about where many users share a connection to the internet, such as at a business or school? Or even in a household? What if there's a bottleneck caused by a malfunction out on the backbone? You can't have good performance in these situations unless users agree on "equally aggressive" protocols.
If you're going to transfer files over UDP then you need to build some TCP-like protocol on top of it. The article doesn't say exactly how BT works in this respect, but he's probably right. There's no way that BT's protocol could be as sophisticated as TCP, given its 30+ years of development.
Most people don't appreciate how amazingly well TCP's flow control works in terms of maximizing link utilization in a way that is fair to all network users. We really don't need is an arms race of new, greedier protocols.
However, one thing to realize about P2P is that because there are often dozens of active TCP connections transmitting from one machine, fairness goes pretty much out the window anyway. An alternate protocol could conceivably improve on this by applying flow control to the aggregate throughput for the whole "bundle" of connections, rather than each connection individually. This would improve fairness and also increase efficiency because you wouldn't have a bunch of TCP streams individually trying to grow their windows, causing packet losses.
An open source project is an unlikely target for a patent troll. Trolls by definition are not in business actually implementing the technology that is the subject of their patents, so your open source project doesn't hurt them directly. Unless you're making lots of money selling your open source software, there's not much they can hope to sue you for.
If you are looking to for personal liability protection then you should create a corporation under which you do all your software development, which might even include hobby or GPL work. This is probably overkill, but it may be a good idea if you think that there's any possibility of building a business around your hobby work in the future. In that case you might be able to claim some tax breaks for the cost of your computer, internet connection etc.
Hiding behind a pseudonym is only helpful in the case where you are doing something very illegal or commercially disruptive, in which case you need to do a lot more than just choose a handle, eg offshoring, money laundering etc. See online casinos, spammers, and porn sites for ideas...
As a developer, the reason you don't search for patents (unless directed to by your own lawyer) is that you can be liable for treble damages if you willfully infringe a patent. Also if it is shown that your knowledge of the patent somehow helped you in your R&D, it becomes much harder to construct certain kinds invalidity and non-infringement defenses.
Maybe parties and candidates don't represent libertarian views, because libertarianism is a niche philosophy which would alienate huge sections of the population.
Possibly, but it also just happens to be the "niche philosophy" on which this country was founded. It makes me angry that both parties are absolutely trampling the constitution. If the Republicrats want to ban guns, ban certain forms of speech, allow arbitrary search and seizure, etc, then they should be allowed to do so only after first passing further amendments to strike those portions of the bill of rights.
Yes, get out of the house. How about going to a party, or hosting one? Instead of sitiing on your duff, you can drink, discuss, and celebrate/commiserate as the results come in. Much more interesting than trying to consume a dozen newsfeeds at the same time, whatever good that might do.
Slashdot Mirror
For every 'yank' performed on the cable, you pull the anchor lower in orbit.
This is wrong - the transmitting end (ground station) can and would "push" just as readily as it would "pull". Then the vehicle would absorb this wavefront as it converts it to potential energy, such that there is very little energy propagating past it up the cable. You have to consider that this cable is very very long, and at such a scale it becomes more like a slinky, or a piece of string with a cup on each end.
Consider how much energy it would take to move this massively long cable. There is no way in hell that is going to be efficient. You're going to be wasting a massive amount of energy as you move the entire cable the whole time the thing is climbing.
That was my initial reaction too, but then I thought about it for a minute and it occurred to me that this is probably analogous to an electrical/RF transmission line. The cable has some (very low) impedance in the sense that it is quite rigid, but it's not zero. You're not "moving the whole cable" by jerking on it, what you're really doing is transmitting a wavefront along a medium. Provided the whole system is impedance matched, nearly all the power could be delivered to the vehicle.
I'm not sure how well this holds up when you consider internal friction of the cable and other inefficiencies, but I wouldn't dismiss it off hand. The simplicity of it in that it works purely on kinetic energy makes it pretty intriguing. It may even have applications besides a space elevator.
Apple's GS/OS had FSTs (File System Translators) that allowed that operating system to access HFS, ProDOS, DOS 3.3, and FAT volumes. How does FUSE compare in function to GS/OS's FSTs? You know, apart from working with non-obsolete hardware.
Fuse is not a file system or even a translation layer per se. It's just a way to let you run a filesystem in userspace, instead of inside the kernel where it would normally reside.
This is slower, but has many benefits including easy development/debugging, not requiring access to kernel sources or rebuilding of the kernel, and easy portability of these filesystems to run atop different host OSes. It also gives the "guest" file system access to all the features of userland, making it easy to, for example, launch a process to convert a file or establish a TCP connection somewhere.
GS/OS was very primitive by todays standards and did not even have a "user space" to speak of - there was no preemptive multitasking or protected memory, so FST was not some significant architectural paradigm - just that the OS knew how to read more than one kind of disk. It's not really comparable to fuse, although it is comparable to some of the things you can do with fuse.
Look around for other projects that use fuse. There's some interesting stuff you can do with it. To give you an idea, years ago somebody did a filesystem which would make a bunch of audio files in a variety of formats all appear to be .MP3 files. When you view the directories all that's happening is the extensions are being changed, but then when you open one, he would transparently launch a decoder in the background to convert the file.
You could also do things like making a remote FTP site appear as a normal file system... all kinds of stuff.
I am not an economist but I have owned a couple businesses and consider myself a reasonably practical person.
I have always believed that the vast majority of today's financial instruments have been invented out of thin air for no reason other than to ultimately ensure the employment of bankers and brokers.
For example, lots of people have a checking account, savings account, credit card, poersonal line of credit, HELOC, brokerage account, and more. I see absolutely no reason why a single account could not offer all those features. The only reason you "need" all that is because the banks created all these funny rules so that they could introduce more and more products and services. This is done so they can charge you more for each of those things, and also to differentiate them from their competitors.
Besides consumer banking, can somebody explain to me why we NEED "commercial paper"? Yes, I've read the wikipedia page and I know how it's used, but I don't understand why it's needed. If you can't make payroll then you're pulling from your credit one way or another - why do we need separate instruments for a 2 week loan versus a longer term loan, or a credit card, or whatever?
And don't even get me started on real estate lending...
It's like freaking starbucks - you can get your banking services just as special as an upside-down triple no foam half calf non fat 160 degree two splenda mocha. But it's one thing for a coffee company to cater to every individual snowflake's desire, and quite another IMHO for something as important as our financial system to become as absurdly complex and fragile as it is.
As for the people who are really benefitting from all this complexity - well, it's only during recession that we all collectively take a good hard look at who's making a contribution to society and who isn't. Unfortunately the powers that be think they can beat a recession by tweaking some rates, stealing from taxpayers, or shuffling money from one hand to the other. That's just going to hurt us more in the long term. We need to clean this shit up now - get rid of unnecessary products and overhead, and let the unproductive companies go bankrupt. Let the UAW strangle themselves to death. Just get it done.
A standard outlet delivers at most enough power to run a vacuum cleaner. At that rate, you're going to be recharging for something on the order of one hour for each mile driven. Maybe they can charge from a regular outlet in case of emergency, but that would not be suitable for daily recharging.
This is a little OT but I figure someone here might know. With so many electric cars finally coming to market I thought it would be smart to plan ahead even if I'm not ready to take the leap yet...
So, I'm in the process of a remodel and have an easy opportunity to install a high-amperage electric circuit to some location in the garage. Is there any emerging standard for charging electric cars that would dictate the ideal location to put the outlet? I.e. in front of the car, driver side, passenger side, what height from ground, etc. Also amperage, type of plug etc would be good to anticipate, although initially I'd just have an empty conduit running there from the load center.
Well, yes. All of the e-commerce sites I've worked on had in-house or outsourced phone staff. But my point is that a site must have some sort of failure mode. Whether it's to call customer service, give free or flat shipping, or whatever, it's better that the customer can complete the sale than see an arcane error message that the system has failed.
You're missing the point - your rate calculator should not even be such a point of failure in the first place. If you do the calculation yourself then it is not dependent on internet connectivity or the shipper's server being responsive.
Most e-commerce sites, including the ones I've built, have a multi-step process to place an order. If the step for shipping (or tax, etc.) failed, then the system would re-load the page with any appropriate messages and option changes. So, for example, if the third-party payment processing service didn't respond before a timeout the user would be asked to call customer service to complete their order. The sales rep could see the order in its incomplete state and finish it over the phone.
I would not consider that an acceptable failure mode. I think you overestimate the patience of the online shopper - you would lose a lot of sales making them jump through hoops like that. Not to mention, who are all these sales guys that you'll have on staff ready to take calls- are you going to pay them to sit there even while the web site is working?
And what happens when they change those tables? Sounds like you're asking for a world of business hurt down the road with the costs to update the code and cover the changed price.
The tables don't change very often. When they need to do a quick rate bump it is usually in the form a simple "fuel surcharge". Even when the tables are updated, it can usually be very closely approximated by applying a simple percentage increase.
Also, most sites put a significant markup on shipping (that's the "handling" part), so small changes aren't important. We applied different markups of our own depending on the shipping rate and destination, and in some cases we even discounted shipping and ate the difference in order to promote sales in areas where the shipping cost would otherwise be prohibitive, such as the Nordic countries.
But even when you're setting your own rates to some degree, the tables are still needed because of big disparities due to geography, particularly when dealing with foreign countries. However, any particular destinations don't fluctuate much relative to each other, they pretty much all move together. So you can easily go a few years between updating the tables, just applying percentage modifiers as needed.
Only a really terrible developer would hit a web services API and not code for it to fail. No one should expect a third party service to be up 100%. The apps should fail gracefully. Anyone finding their e-commerce software handling this situation poorly should find another package.
I have developed a fulfillment system using UPS so I have some experience with this. This was a few years ago, but at the time, UPS's system was designed on the assumption that a shopping cart system would contact UPS during the order placement process (or checkout). USPS appears to be very similar. This is incredibly moronic, because it means that if their server doesn't respond or any reason, you simply lose the sale. Problems AFTER the order has been accepted are far less serious - that just means fulfillment is interrupted - you don't lose orders. It would be even better if you could print the labels without having to reach their server, but they don't provide this (UPS's own software, however, can.)
The only reasonable way to do it (obviously?) is to have your own shopping cart software calculate the shipping rate. At the time I did this in 2001, UPS did not offer reasonable data to let you do this. Their rating system is extremely complicated, and the spreadsheets they gave me had clearly been maintained by hand and needed a lot of massage to get them into a reasonably parseable format. Not only that but it was very difficult to get these tables in the first place, requiring multiple escalations through tech reps and ultimately a "god damn it just give him the tables" from our sales rep.
I imagine things might have improved a little since then and I know there are shopping carts that can now do the rate calculations internally. But if any shipping company forces its customers to contact a server to calculate shipping costs, then they are just as retarded as the merchants who use them (for a web checkout).
The major problem I see is that UDP doesn't play as nicely as TCP. Not by a longshot.
That statement makes no sense whatsoever. It's the same as saying "IP doesn't play as nicely as TCP". They are not comparable.
You have to be talking about whatever transfer protocol might be implemented ON TOP OF UDP, because UDP is merely a datagram protocol. It's nothing more than an IP packet plus port numbers.
In other words, I could write a simple program which blindly fires UDP packets at the rate of 1GB/s. This would kill my internet connection. I could also write a program which transmits one UDP packet per hour. This would have no effect. See what I mean? It's entirely a function of the application.
Detecting maximum throughput via packet dropping is really bad in high-latency links and in applications that need low latency.
I disagree. Please be more specific. First, what exactly do you believe is the problem? Secondly, how else would you do it (on an IP network)?
It is also apparently easy to implement TCP in such a way that overall transfer speed takes a nosedive when latency gets high, as evinced by Microsoft having done just that.
So you're saying it's possible to implement it with a bug? I've recently found a heinous bug in a recent Redhat kernel which would result in _deadlocked_ TCP connections. It happens to the best of us.
BT may have the best of intentions here in developing this experimental protocol, but this quote leads me to believe that their understanding of the problem is terribly naive:
It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once "packet loss" has occurred - i.e. once the user has lost data and (probably) noticed there is a problem.
Packet loss is a normal and deliberate mechanism by which TCP detects the maximum thoughput of a path. Periodically it increases the number of packets in flight until the limit is reached, then it backs off. You have to test again from time to time, in order to increase throughput if more capacity becomes available. This in no way incurs "loss of data" or a noticeable problem. Packets lost due to congestion window growth are handled by the fast retransmit algorithm, which means that there is no timeout or drop in throughput (that would be pretty stupid if the whole purpose of growing the congestion window is to _maximize_ throughput).
I wonder if Simon Morris was merely oversimplifying for the benefit of the layman, but I still find that statement disturbing. As I sugggested in the other thread, it really sounds like they're going to reinvent TCP (poorly). That's not to say you couldn't design a better protocol specifically for point-to-multipoint transfer, but I question if they're on the right track here.
If I pay for 10Mbps download speed, it should not matter to anyone how I use those bits. If you as my ISP cannot handle that traffic, you should NOT have sold it to me in the first place
You have totally missed the point of my post! I wasn't even addressing ISP billing policy, I am talking about how to share a link. Maybe YOU have a dedicated 10Mbps link all to yourself, but not everyone is so lucky. Imagine a small business where 50 people are sharing a T1 line. For web browsing, this many users could all get decent performance, even if a handful of people are doing big downloads, provided they are all using TCP. But all it takes is one guy hammering the link at full throttle to ruin it for everyone else. For better or worse, the internet is designed on the assumption that applications play nicely in this regard.
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine. That's just a consequence of the way Bittorrent works.
That behavior needs to be driven by some timing and retry logic. Also, hosts need to determine how fast they can fire these UDP packets at each other. Those are the most basic fundamentals of transmitting bulk data over a packet network. You really would be reinventing some subset of TCP.
obviously, metering of bandwidth should be by subscriber according to money paid, not by some arbitrary and easily manipulated value like number of open TCP connections.
It's not just about metering. What about where many users share a connection to the internet, such as at a business or school? Or even in a household? What if there's a bottleneck caused by a malfunction out on the backbone? You can't have good performance in these situations unless users agree on "equally aggressive" protocols.
If you're going to transfer files over UDP then you need to build some TCP-like protocol on top of it. The article doesn't say exactly how BT works in this respect, but he's probably right. There's no way that BT's protocol could be as sophisticated as TCP, given its 30+ years of development.
Most people don't appreciate how amazingly well TCP's flow control works in terms of maximizing link utilization in a way that is fair to all network users. We really don't need is an arms race of new, greedier protocols.
However, one thing to realize about P2P is that because there are often dozens of active TCP connections transmitting from one machine, fairness goes pretty much out the window anyway. An alternate protocol could conceivably improve on this by applying flow control to the aggregate throughput for the whole "bundle" of connections, rather than each connection individually. This would improve fairness and also increase efficiency because you wouldn't have a bunch of TCP streams individually trying to grow their windows, causing packet losses.
I don't think this would happen under obama's watch, [...]
Cool. In that case, I'll go back to my watching my regularly scheduled programming.. er, program.
Obama, do not appoint this man!!
An open source project is an unlikely target for a patent troll. Trolls by definition are not in business actually implementing the technology that is the subject of their patents, so your open source project doesn't hurt them directly. Unless you're making lots of money selling your open source software, there's not much they can hope to sue you for.
If you are looking to for personal liability protection then you should create a corporation under which you do all your software development, which might even include hobby or GPL work. This is probably overkill, but it may be a good idea if you think that there's any possibility of building a business around your hobby work in the future. In that case you might be able to claim some tax breaks for the cost of your computer, internet connection etc.
Hiding behind a pseudonym is only helpful in the case where you are doing something very illegal or commercially disruptive, in which case you need to do a lot more than just choose a handle, eg offshoring, money laundering etc. See online casinos, spammers, and porn sites for ideas...
It's only a flesh wound.
As a developer, the reason you don't search for patents (unless directed to by your own lawyer) is that you can be liable for treble damages if you willfully infringe a patent. Also if it is shown that your knowledge of the patent somehow helped you in your R&D, it becomes much harder to construct certain kinds invalidity and non-infringement defenses.
Maybe parties and candidates don't represent libertarian views, because libertarianism is a niche philosophy which would alienate huge sections of the population.
Possibly, but it also just happens to be the "niche philosophy" on which this country was founded. It makes me angry that both parties are absolutely trampling the constitution. If the Republicrats want to ban guns, ban certain forms of speech, allow arbitrary search and seizure, etc, then they should be allowed to do so only after first passing further amendments to strike those portions of the bill of rights.
Yes, get out of the house. How about going to a party, or hosting one? Instead of sitiing on your duff, you can drink, discuss, and celebrate/commiserate as the results come in. Much more interesting than trying to consume a dozen newsfeeds at the same time, whatever good that might do.
I wonder how many customers these two companies will have to lose before they realize that the right solution is to sack the lawyers.
And yet, they keep saying that Palin is inexperienced?
Actually I didn't say that, but now that you mention it... even if she were "merely inexperienced", the fact remains she's an utter nincompoop.