A commercial OS, at least by my definition, is an OS principally developed and backed by a company.
Not Redhat then? Nor Canonical? Nor SuSE?
Seriously, Open Source can be (and is!) commercial. Your post said "Open Source BSD or commercial operating system" - that implies there is a difference. Largely, there is not.
"commercial operating system" - you mean proprietary. There's a lot of "commerce" in the Linux/Free Software/Open Source world, you may have noticed it.
Bravo, that man!
Why should only those who can pass an exam get in? Why would you put a large barrier to entry in the way? What possible purpose would that serve?
Sounds good!
One amendment though - you NEVER want one person in charge of something for a long period of time. They might learn how to do things better, for sure, but they're more likely to take self-interest into the equation much sooner.
That's why I suggested that for each bill, a new "jury" of 100 people were chosen. It seems fair, considering ultimately they would have to abide by those laws when deciding someone's innocence/guilt in a court.
Personally, I don't think so. You only need look at the US to see that having two elected chambers is not necessarily a good thing. While the hereditary aspects of peerages are not very nice, the vast majority of the debate that goes on within the Lords would surprise you and some startlingly frank and honest discussion is carried out that really does represent the best interest of our country.
In my ideal world (and I'm not suggesting for a moment that this is a perfect system), the upper house would be replaced with a system of jurors. Just like in jury service, a selection of 100 people are chosen at random and they debate the bill under discussion, and place their vote in favour, against, or decline to vote. There would be no politics to play, as they have no seat to defend - just like how the Lords was designed. Only now, you get the common-man check on the bill that the Commons is trying to pass.
As a by-product, I think you'd get legislation that is also a hell of a lot easier to read and understand, rather than the legalese that seems to be produced at the moment.
"All they need to do is just upgrade the crappy wires, a large chunk of them still being stuck on awful Aluminium lines, and all the switches probably."
Read the post I was replying to before trading insults.
Also, read up on the technology you're pimping too - a VDSL DSLAM placed at the DP will get you 40Mbit, yes. (not the 100Mbit you describe, you're confusing Ethernet over Cat5e UTP with phone-grade wiring installed decades ago) Your typical DSL connection in a suburban area will be lucky to ever go above 5Mbit using the latest in ADSL2+ technology. You're also completely ignoring the fact that the fibers can be pulled down the same conduits the existing lines are placed into (assuming your country does things the way mine does) which means only a small outlay.
Back in the 80s/90s, Diamond Cable in the UK dug up huge amounts of pavement to install coax to large swathes of the UK. It might be labor and time intensive, that doesn't mean it wouldn't be a project worth embarking on.
DSL has *maybe* 5 years of life left in it, mostly because it's running over a medium that was never designed to support the data it's carrying.
No, really, we've had video conferencing for more than 50 years. No-one wants it because it doesn't add anything constructive. It's not like the difference between TV and radio - if you're on a phone call, you can be doing other things, with a video call you're just blankly staring at a screen with another face blankly staring back at you. Video conferencing is a niche that continually dies out moments after it is introduced.
Look at it this way, let's say you want an ice cream. You phone the yellow pages and ask where you can get some (i.e. the tracker). It says it's in Kansas. You're in Warsaw. So, you go to the airport and travel to Kansas and buy your ice cream.
As far as I'm aware, no client or server software takes into account network topologies so that you can be told "actually, there's one across the block!"
P2P sounds great, but the information required to make a "good" decision is really hard to distribute. Whereas, with a CDN, the data (or ice cream) can be brought TO the user. Almost always, a CDN *will* be quicker than BitTorrent. I'm sure you can provide counter-examples, but P2P by it's very nature makes bad decisions on where to get data.
Oh, and forget about P2P video streaming. Worst idea, ever. That's what multicast is for.
The problem with P2P is it pays no attention to network topology. When faced with 5 peers, it gets data off all of them at the same time. What it *should* do, in an ideal world, is work out the least congested path and stream from that in preference. With CDN peers, that's exactly what happens in HTTP-world.
BitTorrent et al are great for sparsely sourced items - where there are 10 peers. If you have a mesh of 10,000 peers, you want to prefer the shortest, most economical path. Otherwise, you're shooting yourself in the foot. Of course, in the ideal situation, this information would be signalled by consulting a DFZ routing table, but that's not really practical
I think we both misunderstand each other. I'm very happy we have a decentralised internet, and BGP has been working that way for nearly 20 years.
What I disagree with is that homes should be able to run servers. It's a really bad idea for the general populace to run a server, because they won't have the experience in configuring it to prevent the kind of situations you see with compromised servers out there. Sure, there are smart users, but at the end of the day it's far better to have a system where the home user is a client, and they contact a server to get their data processed. This server could be in San Francisco, or it could be at one of their ISPs PoPs. Then, the decentralisation can take place, with a properly configured system that knows about the best routes to take, rather than treating the whole IP space as the same.
I know there have been some cases of people importing AS_PATHs into BitTorrent so that they get the shortest path available, and that's a good thing (mostly, it obviously comes with massive warning flags!) for prioritising peers, but you'll always get the most optimised network if the user uses and the server does all the hard work.
One final point - in the more rural areas (and especially if you're more than 5km from an exchange) the DSL speeds you get tend to be in the 3:1 range, not 15:1, so changing it to a 2.5:1.5 or even a 2:2 connection would seriously affect the download speed. With a cable connection, you generally have a shared downstream that you have a slice of, then much slower upstream channels to maximise the number of clients you can have on the system. It's not done out of spite or limiting, it's done because technically it's the easier thing to do.
90-99% of the people I see complaining on slashdot about slow upload speeds aren't doing photo uploads, though, they're doing P2P, you have to give me that
IPv4 has MTU discovery as well. RFC1191. Many overly-security-conscious networks block all traffic not officially sanctioned, though, which also hampers correct ICMP replies.
Oh, we're going all professional are we now, Mr. Sysadmin? I'm a Network Architect, primarily dealing with traffic flows in the 5-10Gb range, using BGP to *signal*, not to transfer data. A full table is less than 100MB and if designed right, will only be transferred *once*, and that's when the session comes up. I highly doubt you're a "tier-1" network, as you're a customer of Level-3. By definition, not tier-1.
Decentralisation is *not* a good thing, because the end user doesn't know the path to the remote end - they could quite easily be taking their data over a congested link. That's why in the "real world" we have these fantastic things called CDNs, that bring the content to the user, rather than saturating those precious trans-continental links.
Business users running VPNs will easily be in the "1% range" rather than the "30% range" you suggest. Looking at *any* ISPs traffic flow will show you that more than 75% of traffic is made up by HTTP and P2P, followed by SMTP which is a decentralised (but importantly, still client/server at the user level) transport protocol you may have heard of.
Upload bandwidth is not important. As long as there is enough to do the TCP ACKs, the initial requests, and simple gaming traffic, people are happy with it. Giving them additional upload bandwidth (at the cost of slower download, as with the case of DSL) would be pointless unless they're a heavy P2P user.
You're just being another one of those people that think they're being hard done by, when realistically the vast majority of the population just want to use services - not create their own out of spare computing power in their houses.
(Of course, when it comes to business connections, all bets are off and you're entirely correct in some regards, but then they're more likely to go with a leased line rather than DSL, and my point was about residential practices!)
1) Seriously, yes.
2) He didn't mention YouTube.
The thing abou Youtube is that you start a video uploading, then you go do something else. With faster upload, you just go do something else for less time. Having faster upload hasn't enabled you to do anything else. Having faster download has enabled Youtube to exist, as it allows people to stream rather than download and watch.
The only criticism I'd have with that suggestion is:
Many other countries have fast, symmetric connections. They don't do any of that kind of stuff - if anything, the vast majority of their additional upload speed is *only* used for P2P.
Everybody keeps mentioning video streaming, as though this is a new thing - we've been able to do video streaming for years, but we don't, and bandwidth has never been the problem.
"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight
