I personally just want a big DC power supply in the basement and run USB ports all over the house.
You might think you do but when you actually run the sums you will probablly decide that you don't. Low voltages mean high currents which means high cable losses.
Plus this new power standard requires the host to switch voltages, so you can't run multiple ports directly off a single power supply.
I think you are worrying uncessacerally. The spec is freely downloadable at http://www.usb.org/developers/docs/usb_30_spec_071012.zip (USB_PD_V1_0-20120705-final.pdf within the zip). The A ends of the cables indicate thier type passively (micro connectors use an ID resistor while full-size connectors use mechanical differences).
What is it about Linux, that made Google choose it over any other Unix-likes?
It's better known, tends to have better hardware support and the GNU tools tend to feel more modern than their BSD equivilents.
My money is on the pervasive GPL. The GPL fits Google's agenda better than any other licensing scheme, and that's pretty much the end of that story.
I don't think it's the GPL that attracts google to linux, look at andriod for example, the kernel is GPLv2 but IIRC the rest of the stack is non-copyleft.
The whole manufacturing and distribution side of things is now being handled by RS and Farnell. You may not of heard of these companies (they do have a US presense under the names newark and allied but afaict mouser and digikey are more well-known over there) but anyone who is into electronics and lives in the UK will have heard of them and likely bought from at least one of them. Furthermore farnell at least aren't actually charging credit cards until just before they ship.
Yes it will take a while for them to catch up with demand but there are real Pis out there in the wild and I don't see any sign of this being a scam, just a project that had more success than it could easilly handle.
While it's possible to use the Pi as a media centre it is somewhat limited as one. In particular they only licensed on codec (h.264) for the GPU and the CPU doesn't have the grunt to decode in software.
the problem with a wastebasket is that it's not generally supposed to have cables going to/from it. That means you will have to run off batteries (running off batteries long term is a MAJOR PITA) and you will be limited to wireless hacks.
OTOH power strips are expected to have power and ones with communication surge protection while relatively unusual are not unheard of. This means that you can have power and network going to the "hacking device disguised as a power strip" without it looking too suspicious.
No, it's on a reasonablly decent dedicated server and neither network load or CPU load appeared to be a problem according to MRTG.
I'd guess the problem was some kind of misconfiguration somewhere (probably a limit set too low) but it was back up again before I noticed these posts.
now I hope they'll come up with a C model with more processing power, but that's for another day.
I think they should leave it at least a couple of years before doing that. Otherwise they risk the early adopters getting screwed as software development moves to the newer shinier model before a good base has built up.
It depends on your definition of "cheap". There have been many arm linux systems available before but all the ones i've seen were either far less capable than the Pi (hacked up home routers) or far more expensive (beagleboard and gumstix series) or both.
Do you think someone who is planning to commit multiple murders is going to care about a rule telling them they shouldn't bring their gun in? or care about setting off a metal detector as they barge-in?
Rules against bringing guns in are probablly good at reducing the damage when a fight gets out of hand (which is presumablly why bars and pubs had them) but they aren't going to stop premeditated attacks (indeed they may make them easier because they mean the regulars will be unable to fight back).
One big difference between physical media and online distribution is that selling by online distribution implies making a copy as part of the sale. That in turn means the seller has to have an license (or chain of licenses) with the copyright holder. That in turn means they have to play by the copyright holders rules.
Whereas with physical media it can be resold by an entity that has no such relationship with the copyright holder and is not bound by their rules.
I showed him the box and he wasn't sure how anyone had trouble opening it either.
Maybe it was a case of the boxes being made to an insufficiently tight tolerance. It can only take a tiny difference in dimensions to make the difference between a cover that slides off easily and one that is virtually stuck
NAT64 seems like a horrible soloution to me, protocol translation adds a load of complexity and afaict you have to mess with dns to direct users to your nat64 gateway (which breaks dnssec). I sure hope it doesn't become the default solution to the v4 address shortage but I fear you may be right that the mobile networks will pick it to simplify things at the device end.
The same applies if you are running debian on an older x86 box and try to install a deb built on ubuntu. Or if you try and upgrade from an older debian release to a newer one that has dropped support for your CPU variant.
Precedent is that debian architecture names specify cpu family/abi not specific CPU variants. This gives more flexibility but it does mean you can install packages that are compatible with those you have installed but are not compatible with the CPU variant you have.
Short answer: because that is what debian does and if you want to remain sane when rebuilding something as large as Debian you try and stay as close to what they do as possible.
Long answer: while there is some limited support for cross-compiling in the debian tools it is very poorly documented and there is absoloutely no requirement for individual packages to support being cross compiled, let alone any testing as to whether packages meet that requirement. Trying to cross-build would mean that in addition to solving armv6 hardfloat specific issues (which fortunately are relatively rare) we would also have to fixup every package to support cross-compiling.
We can either spend money and transition to IPv6 or spend more money managing the problem rather than solving it.
Unfortunately IPv6 has a massive chicken and egg problem. We can't really start deploying v6 only stuff until most of the internet has moved to dual stack but there is little financial motivation to move to dual stack while there is virtually no v6 only stuff out there.
So for the foreseeable future the choice for an ISP that is short on addresses (or one that has decided that the market value of their addresses is greater than the "use value") is between deploying some form of ISP level NAT and deploying IPv6 or deploying some form of ISP level NAT and ignoring IPv6.
Good question, the changes we make in raspbian come into basically three categories.
1: changing compiler defaults. Theese can't be pushed upstream until/unless the debian tools get an understanding of flavours*. This is a subject I intend to bring up on the debian mailing lists in-time but it may well cause a flamewar. 2: hacks, it's inevitable that when you have only two people doing a project on this scale that you will run into issues that you don't have the manpower to solve properly and so have to hack around to keep things moving forward. Such hacks include things like reducing optimisation levels, using non-default gcc versions and disabling testsuites. I don't think debian would want these changes. 3: proper bugfixes, I do try and push these back to debian where possible.
We do not intend to be a fork, the VAST majority of source packages are imported from debian and rebuilt with no source changes whatsoever.
* a flavour is a variant that is binary compatible but has different minimum CPU requirements.
You can buy a locked cell phone for "$50" with a 2-year service commitment at $60/month, or the same phone unlocked for $500.
Sure
The unlocked phone is of course a much better deal most of the time.
Afaict this depends completely on where you live and your usage patterns. In many places you end up effectively paying for the subsidised phones whether you accept it it or not.
since 2001:: (and a bunch of more address ranges in the 2000::/3)
The whole of 2000::/3 is assigned to the IPv6 internet (not all of it is in use yet though)
there is room for approximately 50 billion network organizations worldwide.
Umm, assuming each network gets a/48 (which is a conservative assumption many ISPs are only giving out a/64 by default and giving larger allocations on request) and a/3 is available for the "IPv6 internet" that leaves 45 bits to define the network. That means about 35 trillion networks can be addressed. To put that number into perspective it's thousands of networks for every person alive on earth today. Granted there will be some wastefulness in allocation (in particular ISPs that are big enough to be allocated a/32 but small enough that they won't ever allocate all 65536/48s) but I still don't see IPv6 addresses running out any time soon.
And finally remember the current ways of dividing up the IPv6 address are mostly just conventions. There is nothing stopping you using smaller subnets right now if you want (provided you are prepared to give up stateless autoconfiguration), the internet won't know or care.
That graph has misleading axis. It looks like the actual drop is from arround 1.92 to arround 1.8 which i'd consider to be noticable but not earth shattering.
Slashdot Mirror
Touching them is fine, what is NOT fine is dropping a spanner on them.
I personally just want a big DC power supply in the basement and run USB ports all over the house.
You might think you do but when you actually run the sums you will probablly decide that you don't. Low voltages mean high currents which means high cable losses.
Plus this new power standard requires the host to switch voltages, so you can't run multiple ports directly off a single power supply.
I think you are worrying uncessacerally. The spec is freely downloadable at http://www.usb.org/developers/docs/usb_30_spec_071012.zip (USB_PD_V1_0-20120705-final.pdf within the zip). The A ends of the cables indicate thier type passively (micro connectors use an ID resistor while full-size connectors use mechanical differences).
What is it about Linux, that made Google choose it over any other Unix-likes?
It's better known, tends to have better hardware support and the GNU tools tend to feel more modern than their BSD equivilents.
My money is on the pervasive GPL. The GPL fits Google's agenda better than any other licensing scheme, and that's pretty much the end of that story.
I don't think it's the GPL that attracts google to linux, look at andriod for example, the kernel is GPLv2 but IIRC the rest of the stack is non-copyleft.
but its totally setup for a large scam
BS
The whole manufacturing and distribution side of things is now being handled by RS and Farnell. You may not of heard of these companies (they do have a US presense under the names newark and allied but afaict mouser and digikey are more well-known over there) but anyone who is into electronics and lives in the UK will have heard of them and likely bought from at least one of them. Furthermore farnell at least aren't actually charging credit cards until just before they ship.
Yes it will take a while for them to catch up with demand but there are real Pis out there in the wild and I don't see any sign of this being a scam, just a project that had more success than it could easilly handle.
While it's possible to use the Pi as a media centre it is somewhat limited as one. In particular they only licensed on codec (h.264) for the GPU and the CPU doesn't have the grunt to decode in software.
the problem with a wastebasket is that it's not generally supposed to have cables going to/from it. That means you will have to run off batteries (running off batteries long term is a MAJOR PITA) and you will be limited to wireless hacks.
OTOH power strips are expected to have power and ones with communication surge protection while relatively unusual are not unheard of. This means that you can have power and network going to the "hacking device disguised as a power strip" without it looking too suspicious.
No, it's on a reasonablly decent dedicated server and neither network load or CPU load appeared to be a problem according to MRTG.
I'd guess the problem was some kind of misconfiguration somewhere (probably a limit set too low) but it was back up again before I noticed these posts.
now I hope they'll come up with a C model with more processing power, but that's for another day.
I think they should leave it at least a couple of years before doing that. Otherwise they risk the early adopters getting screwed as software development moves to the newer shinier model before a good base has built up.
It depends on your definition of "cheap". There have been many arm linux systems available before but all the ones i've seen were either far less capable than the Pi (hacked up home routers) or far more expensive (beagleboard and gumstix series) or both.
Do you think someone who is planning to commit multiple murders is going to care about a rule telling them they shouldn't bring their gun in? or care about setting off a metal detector as they barge-in?
Rules against bringing guns in are probablly good at reducing the damage when a fight gets out of hand (which is presumablly why bars and pubs had them) but they aren't going to stop premeditated attacks (indeed they may make them easier because they mean the regulars will be unable to fight back).
One big difference between physical media and online distribution is that selling by online distribution implies making a copy as part of the sale. That in turn means the seller has to have an license (or chain of licenses) with the copyright holder. That in turn means they have to play by the copyright holders rules.
Whereas with physical media it can be resold by an entity that has no such relationship with the copyright holder and is not bound by their rules.
I showed him the box and he wasn't sure how anyone had trouble opening it either.
Maybe it was a case of the boxes being made to an insufficiently tight tolerance. It can only take a tiny difference in dimensions to make the difference between a cover that slides off easily and one that is virtually stuck
NAT64 seems like a horrible soloution to me, protocol translation adds a load of complexity and afaict you have to mess with dns to direct users to your nat64 gateway (which breaks dnssec). I sure hope it doesn't become the default solution to the v4 address shortage but I fear you may be right that the mobile networks will pick it to simplify things at the device end.
http://news.google.com/newspapers?nid=1946&dat=19410812&id=iC0rAAAAIBAJ&sjid=tJgFAAAAIBAJ&pg=3813,1840173
The same applies if you are running debian on an older x86 box and try to install a deb built on ubuntu. Or if you try and upgrade from an older debian release to a newer one that has dropped support for your CPU variant.
Precedent is that debian architecture names specify cpu family/abi not specific CPU variants. This gives more flexibility but it does mean you can install packages that are compatible with those you have installed but are not compatible with the CPU variant you have.
Now you have to subscribe to the debian security mailing list and backport all security patches to your little customized OS.
No need to subscribe to the list really, just pull in the packages as they appear and let they autobuilders have at them.
Compared to following testing (which we are doing at the moment) following the various types of updates to stable will be a walk in the park.
Short answer: because that is what debian does and if you want to remain sane when rebuilding something as large as Debian you try and stay as close to what they do as possible.
Long answer: while there is some limited support for cross-compiling in the debian tools it is very poorly documented and there is absoloutely no requirement for individual packages to support being cross compiled, let alone any testing as to whether packages meet that requirement. Trying to cross-build would mean that in addition to solving armv6 hardfloat specific issues (which fortunately are relatively rare) we would also have to fixup every package to support cross-compiling.
We can either spend money and transition to IPv6 or spend more money managing the problem rather than solving it.
Unfortunately IPv6 has a massive chicken and egg problem. We can't really start deploying v6 only stuff until most of the internet has moved to dual stack but there is little financial motivation to move to dual stack while there is virtually no v6 only stuff out there.
So for the foreseeable future the choice for an ISP that is short on addresses (or one that has decided that the market value of their addresses is greater than the "use value") is between deploying some form of ISP level NAT and deploying IPv6 or deploying some form of ISP level NAT and ignoring IPv6.
For the record we are NOT cross-compiling. We are building natively on arm hardware (though admittedly not on Pis)
Good question, the changes we make in raspbian come into basically three categories.
1: changing compiler defaults. Theese can't be pushed upstream until/unless the debian tools get an understanding of flavours*. This is a subject I intend to bring up on the debian mailing lists in-time but it may well cause a flamewar.
2: hacks, it's inevitable that when you have only two people doing a project on this scale that you will run into issues that you don't have the manpower to solve properly and so have to hack around to keep things moving forward. Such hacks include things like reducing optimisation levels, using non-default gcc versions and disabling testsuites. I don't think debian would want these changes.
3: proper bugfixes, I do try and push these back to debian where possible.
We do not intend to be a fork, the VAST majority of source packages are imported from debian and rebuilt with no source changes whatsoever.
* a flavour is a variant that is binary compatible but has different minimum CPU requirements.
You can buy a locked cell phone for "$50" with a 2-year service commitment at $60/month, or the same phone unlocked for $500.
Sure
The unlocked phone is of course a much better deal most of the time.
Afaict this depends completely on where you live and your usage patterns. In many places you end up effectively paying for the subsidised phones whether you accept it it or not.
since 2001:: (and a bunch of more address ranges in the 2000::/3)
The whole of 2000::/3 is assigned to the IPv6 internet (not all of it is in use yet though)
there is room for approximately 50 billion network organizations worldwide.
Umm, assuming each network gets a /48 (which is a conservative assumption many ISPs are only giving out a /64 by default and giving larger allocations on request) and a /3 is available for the "IPv6 internet" that leaves 45 bits to define the network. That means about 35 trillion networks can be addressed. To put that number into perspective it's thousands of networks for every person alive on earth today. Granted there will be some wastefulness in allocation (in particular ISPs that are big enough to be allocated a /32 but small enough that they won't ever allocate all 65536 /48s) but I still don't see IPv6 addresses running out any time soon.
And finally remember the current ways of dividing up the IPv6 address are mostly just conventions. There is nothing stopping you using smaller subnets right now if you want (provided you are prepared to give up stateless autoconfiguration), the internet won't know or care.
On modern flip-chip packages what you see is the back of the die so I don't see any reason why you couldn't lap it.
That graph has misleading axis. It looks like the actual drop is from arround 1.92 to arround 1.8 which i'd consider to be noticable but not earth shattering.