I should clarify, by "a load" I meant a significant proportion of total IPv6 traffic at the time, it's still of course tiny compared to IPv4 traffic and pretty small compared to total IPv4 traffic now.
6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.
This statement seems kind of contradictory to me If 6to4 is causing "headaches" that means hosts must have been using it. Googles stats also indicate that a load of clients were using it at one stage though that number has dropped off more recently
6to4 provided an easy way for people to build experience with ipv6 without having to agree to a possibly onerous list of terms from some tunnel provider and provides a way for users to access v6 only resources (which aren't very numerous yet but they can only become numerous if everyone can reach them) with only a v4 internet connection.
Having said that 6to4 does have it it's problems. Firstly running over IP directly may have made it slightly more efficient but it also meant it couldn't really be run behind a NAT box, it would have made far more sense to run it over UDP which can easilly be port forwarded. Secondly and more importantly it has performance and reliability problems because ISPs don't take it seriously. If every dual stack PoP had a 6to4 relay router then 6to4 would be fast and reliable but they don't so 6to4 traffic ends up handled by benevolent third parties who may or may not provide acceptable quality of service.
There was a load of talk about hierarchical routing when IPv6 was being developed but what we actualy ended up with was much the same as we have with IPv4, autonomous systems advertise prefixes over BGP which combine to produce a massive routing table. The table will have less cruft than the IPv4 one both because it's newer (The IPv4 table contains a lot of cruft like legacy allocations where an equivilent allocation wouldn't be PI under current rules, multiple seperate allocations for companies whose IP space needs have grown and so-on) and because IPv6 gives the RIRs room to make allocations sparsely allowing them to extend existing allocations rather than making new ones but that isn't really relavent here..
As with IPv4 autonomous systems are able to route things as they wish within their own networks and as with IPv4 some autonomous systems span multiple continents and as with IPv4 some users traffic may pass for considerable distances over non-ip networks (or tunneled over a non-internet ip network) before entering the providers "general routing" (for example most smaller ISPs in the UK have only on PoP).
Further allocation procedures may make geolocation worse for IPv6 than IPv4. IIRC the default allocation to an ISP is a/32 so if the ISP only gives out a/56 or smaller by default they will probably never need to get any more IPs (how many ISPs really have more than 16 million customers) which means they won't need to worry too much about keeping the RIR happy. I know when I get an IP from freenet6's dutch gateway the geoipv6 database lists it as being in canada.
normal people off the street have to jump through so many hoop to own an automatic weapon now (fingerprinting, extensive background check, letter of endorsement from local head law enforcement official, tax stamp, etc.) that VERY few do so
IIRC someone recently produced a special holder in which you could place a semi automatic gun which would cause your finger to release from the trigger when it recoiled and then spring it back pushing your finger back into the trigger giving you effectively full auto fire without the gun itself being full auto.
Dunno if anyone has used one in a crime yet though.
The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses.
That sounds like a bad idea from multiple perspectives, first there is the issue of finding hardware capable of doing it (or finding load balancing hardware). Secondly it means that if routing in the ISP network chooses a different exit point then a different NAT will be used which will break existing sessions. Thirdly if the ISP provides hosting or premium connections with public IPs and a private IP user connects to them then it may not get natted which may cause problems. Fourthly having routing to multiple NATs will break many nat traversal techniques.
If NAT has to happen (and for some ISPs NAT or a similar IP sharing system WILL have to happen) it's much better if it happens near the edge where there is only really a single route. If the ISPs management systems want to see the private addresses then that can easilly be arranged which keeping the NATs near the edge by adding an exception to the NAT rule.
This means a national scale ISP like Comcast could probably function on a/16.
Comcasts problem is they want to keep a flat network for managing their devices and there simply aren't enough private v4 IPs to do that. That is why they are working to move as much as possible to IPv6.
It's perfectly possible to run a PPP server with static mappings from logins to addresses (of course this means you can only have one client at a time per set of login details but that isn't usually too much of a problem).
The ISP determines whether the prefix is allocated statically or dynamically, the end user determines whether the addresses within the prefix are allocated statically or dynamically. If the prefix is static then trackers can use it to track down to the premisis level regardless of whether the addresses within the prefix are static or dynamic. If the prefix is dynamic then it makes network administration a massive PITA.
There are three possible soloutions to multi-ISP operation (whether for v4 or v6), none of them great.
1: have your own IP block and advertise it over BGP. The trouble with this is that the number of people who can do it without killing the core routers is limited, so noone wants to encourage people to do it who aren't already doing so. 2: use NAT, this is what everyone does for IPv4 but it's what we are trying to get away from for v6. 3: put multiple v6 addresses on each end system. The question then becomes how quickly can you get the end systems to stop using an address block if it's associated internet connection fails.
I suspect the best compromise may be a combination of 2 and 3. Stop advertising addresses whose connectivity has failed but use NAT to bridge the gap until the clients stop using them.
Any new protocol will take years to deploy, years that we don't have.
The choices going forward at this point are IPv4 ISP level NAT, IPv4 ISP level nat in dual stack with IPv6 or IPv6 with some from of transition method (NAT64, DS-LITE etc).
Mistakes were made but they mostly weren't mistakes in the design of the core protocol, they were policy mistakes such as failing to provide any real incentive to ISPs to deploy IPv6 and doing a poor job of providing transition mechanisms for users behind v4 only NAT boxes (teredo came too late and has a fragile design). Which have resulted in lots of places leaving deployment to the last minuite.
Still big improvements have happened in recent years. A significant one was when HE very generously deployed a large number of 6to4 and teredo relays and advertised them on the public internet making those transition mechanisms far more reliable for users. Another was the implementation of the "happy eyeballs" specification in many web browsers (though sadly not in IE) to reduce delays for users with broken IPv6 connectivity and hence both reduce the chances of end users disabling IPv6 as a workaround and making website operators able to be more confident in offering AAAA records.
And I'd love to tell those ISPs that they aren't getting my business.
Which side will get what they want depends on how much competition there is and how much each side wants it. For end user ISPs in some places there is little competition so end users may be forced to accept such terms. OTOH for hosting providers there is plenty of competition. If having a full/48 is important to you i'm sure you will be able to find hosting providers who offer it.
Also, organizations that use IP phones do need as many publicly routable IP addresses as they have phones
Only if they
1: use the braindead but sadly popular protocol called SIP that doesn't play nice with NAT. 2: try to route that protocol over the open internet directly from individual phones
If the organisation does the sensible thing and routes all phones through a PBX then this isn't really an issue. Only the PBX needs public IP space.
Also, the most common form of NAT used is Port Address Translation, and in this one, one needs more routable IPv4 addresses - just 1 won't do. And so even NAT can't for the long run alleviate the demand on IPv4 addresses.
There is a limit to the number of customers per IP address but it's high enough that most ISPs who deploy NAT won't be running out of IPs in the foreseeable future. If world population increases by orders of magnitude we may have a problem but frankly if world population increases that much we are likely to have bigger problems.
if you know it weighed X in 2000, and it weighs Y in 2013 whats the problem
The problem is we DON'T know that. We know that the kilogram prototypes are gradually diverging in mass but we don't know which one is most correct or whether the group as a whole is gaining or losing mass. The cleaning procedures are supposed to remove contamination (and no matter how careful you are some contaimination is inevitable) without removing the actual metal of the prototype but afaict we have no real way of knowing how effectively they achieve that goal. Nor do we really know how much wear there is from handling the things.
Isn't the definition of a gram the mass of 1 cm3 of water?
No, that was how it was initially defined but in 1799 they moved to using metal prototypes.
Would this not be a standard you could employ in any lab without the need for the international 1Kg prototypes?
It's trickier than it sounds. Between the difficulty of accurately measuring out the liquid, the fact that density changes with temperature and pressure, the fact that isotopic mixes can vary and the fact that our units of pressure are in themselves based on the kilogram making the definition recursive this becomes a difficult definition to apply accurately.
There is talk of moving to a definition based on fundamental physical units but it's difficult to get the experimental results consistent and stable enough (IIRC two different methods for determining avagadros number were giving slighly different results).
. If the physical layer is trusted, then NTLM works fine. Historically, lots of corporate networks controlled every computer on the office network, and air-gapped the internet.
To what extent did they control them though? The bigger a network gets the more chance of a rouge device getting on it either through compromise of a machine that was legitimately there or through introducing a machine illegitimately.
The sensor ports on NXT bricks use I2C for communication, allowing "sensors" to be daisy chained and referred to by address.
Third party sensors generally yes, lego sensors no. Most of the lego sensors don't use I2C and the only one i'm aware of that does (the ultrasound sensor) is not readdressable.
That is why you need a device like the hitechnic sensor mux (which you admittedly did link) that can deal with all the different types of lego sensor and then present the results as an I2C device. Not cheap though.
Want to control more motors? Simply add a I2C controlled motor controller - a simple circuit to make yourself, or buy one of the commercially available options. In most cases you would use these with an external power supply (i.e. battery box).
Indeed you have to use an external battery box.
Separating "things like device power supply from device control" is as simple as making your own cables...
Not really, the NXT has no external power connection* so you can't really run it off an external battery and you can't really run your external devices off the battery in the NXT either (there is a tiny ammount of power available on the sensor ports but it's only enough for small sensors)
Using USB for these purposes rather than I2C would be far more complex. I2C is very simple to use, and is fast enough for most motor and sensor IO.
Agreed.
Overall it's nice that lego lets this third party stuff exist but you can tell it's third party hacks not a design feature of the system and the cost adds up pretty damn quick.
* The recharable battery accessory does have a charging port which can be used to supply the NXT but you wouldn't really want to use that to supply the NXT off another battery in a mobile model. I guess you could hack up a NXT battery pack to add an external power connection but that is going beyond "just making cables"
Since typically (as far as I recall) mindstorm programs are loaded into the brick at runtime
You are kind of out of date. The RCX kept almost everything in ram (which was a PITA, take the batteries out and you had to redownload the firmware before you could program it again) but the NXT uses flash for user programs and updatable firmware.
most of the NXT sensors are just packaged up I2C sensors
Actually that is not really true at least for the lego sensors (third party sensors are another matter).
The touch sensor is a simple switch I think the temperature sensor (not included in any kits but available for purchase seperately) is a simple thermister but i'm not positive on that. The light and sound sensors are analog sensors with some internal electronics. The ultrasound sensor is I2C. I think the color sensor included in the newer NXT kits is also an analog sensor with some electronics but i'm not postive on that (note that the lego color sensor is NOT the same as the hitechnic one).
For that matter, they'd be electrically compatible with a $35 Raspberry Pi's I2C bus if they could handle 3.3V or had a 3V3-5V circuit between them.
Any one of the NXTs sensors could be easilly interfaced to a raspberry Pi. Making an interface that works with all of them is somewhat trickier. Making it work with the RCX powered sensors too is trickier still. Also I heard somewhere that lego had patents on the tricks used in the RCX powered sensor interface which may make a commerical interface that supports those sensors difficult to pull off.
It is fundamental that you can't spend more than you take in indefinitely.
Not if you can print* more.
The distinction between the federal governent and the federal reserve is little more than an accounting fiction. One that if congress agreed they could disband (of course this whole story is about congress failing to agree..............).
The reason the greeks etc are so screwed is that they gave up their financial sovereignty to the EU.
* Nowadays "printing" is something of a metaphor, most of the money in existance is created by putting numbers in databases rather than by putting numbers on bits of paper.
eSATA has a couple of practical problems. Firstly if you set the SATA mode to "ATA" for ease of installing an older OS you often lose your eSATA port. Secondly most computers with eSATA only had one port and practically speaking eSATA is limited to one device per port. Port multipliers exist in theory but not all controllers support them, you can only have one level of them and i've only ever seen them integrated in drive enclosures not as a seperate product. Thirdly power was an afterthought hacked in later (eSATAp) so most eSATA drives needed a seperate cable for power. Finally eSATA has no backwards compatibility with any previous interface standard, some drives do support both eSATA and USB but you still need different cables.
In summary eSATA is fine if you have run out of drive bays and want an extra drive or are concerned about security and want to lock your drive in your safe when you go away so you have a drive that is external but lives with a single machine. It's not a good choice for a drive that is carried around and used with many machines.
10 Gbps is probablly overkill for current storage needs but SSDs keep getting quicker. Higher speeds also raise the possibility of graphics over USB3. The recent GPU switching stuff has shown that PCs now have enough internal bandwidth and the GPU vendors can be pushed to cooperate enough that a direct path from GPU to display output is not actually needed.
If you want printed photos on the go there are still options available.
Fujifilm have an instant photo product, due to patent license issues it wasn't widely available in the west during polaroid's heyday but with polariod out of the picture major vendors in the west have started stocking it. Search for "instax" on amazon and you'll find it.
There is also impossible who have made new film for the old polariod cameras. However it is a LOT more expensive than the instax stuff.
Finally there are portable photo printers that you can use with a digital camera. This has the advantage of being able to print a copy for the locals and keep a digital copy for yourself. Power may be an issue in some places though I guess.
Polariod's problem was it's VERY hard for companies to successfully scale down. There is still a market for analogue instant photography but it is a MUCH smaller market than it was in the days when it was the only way to get photos quickly.
ARIN has been pretty clear they don't want carrier grade NAT.
Well if the RIRs didn't want it they should have put some incentives in place to deploy IPv6. If they had made new v4 allocations to ISPs conditional on making IPv6 available to all customers and supported by all new customer premisis equipment supplied by the ISP then we wouldn't be in this mess now.
Growing ISPs are going to have no choice but to deploy some kind of mechanism for users to access v4 resources without giving those users a public V4 IP. There are basically 3 choices.
1: Run an IPv6 access network and use some mechanism (NAT64 or ds-lite, some kind of tunneled port based address sharing) to make access to the IPv4 internet available over that v6 access network. 2: Run a dual stack access network with public v6 and private v4 and an ISP level NAT 3: Run a IPv4 access network with private addresses and an ISP level NAT.
Round here (UK) most mobile providers are already giving out private v4 IPs and running NAT. Landline providers are still generally giving out public v4 IPs for the moment. Few providers seem to be showing much interest in making IPv6 available to customers. Our main telco is apparently even running a broken 6to4 relay in their network on the anycast address ( http://www2.warwick.ac.uk/fac/sci/csc/people/computingstaff/jaroslaw_zachwieja/bt_fttc_ipv6/ ). Given this situation I just don't have any confidence that ISPs will go the IPv6 route.
I suspect the ad networks don't want to go down that road because it raises the bar for putting ads on your website. Also click tracking is an issue, if it's left up to the hoster of the site then click fraud becomes much easier, if it's done by the ad networks then it provides something that can be matched by a blocker.
In England, we are lucky, most geolocation services get the city info wrong,
AIUI the free geolocation services are basically built on freely available data while the pay services supplement that with data from their own research. If the ISPs don't make the data easilly available (I don't think there is any obligation on an ISP to post where in the country and allocation is being used) the free databases won't have it. If the ISPs put users from different places in one subnet then the pay databases won't have it either.
But when I wrote that post I wasn't thinking of publically available geolocation services, I was thinking of the government (who can demand information from your ISP) and possiblly big companies (who can correlate IPs used for one activity with those used for another).
I dread to think what would happen if we had to give them the line noise that is an IP6 address.
IPv6 addresses don't HAVE to look like line noise. Yes they are longer but that length gives you more freedom to maintain an addressing pattern that matches your network rather than having to pack things in a massively dense fashion. The main thing is to avoid using stateless autoconfiguration for any IP a user is likely to need to interact with.
Having said that there is really no reason to not continue using private IPv4 for logging into boxes regardless of whether they have a v6 IP to let them access resources on v6 networks (public or private).
With conventional NAT reserving a port on the public side for each connection I doubt you'd want to go more than about a hundred customers per IP (and even that may be pushing it if your customer base is high activity). Dedicated high ratio nats that resused the same source port for connections to different servers may let go up to say a thousand customers per IP but
Still even a 1:10 ratio would mean that most ISPs wouldn't have to worry about exhaustion on the consumer side for a long time and on the hosting side SNI should become practical to deploy in a couple of years dramatically reducing IP space requirements for shared hosting.
I hope that ISPs will offer IPv6 before they start forcing users behind NAT but I wouldn't rely on it.
If you are designing a new deployment now I STRONGLY advise you to avoid relying on the ability to accept incoming connections to equipment located in homes or small offices and to minimise the number of public v4 addresses you need in your central facilities (could be just one to terminate IPv6 over UDP tunnels from the homes and small offices).
Slashdot Mirror
a load
I should clarify, by "a load" I meant a significant proportion of total IPv6 traffic at the time, it's still of course tiny compared to IPv4 traffic and pretty small compared to total IPv4 traffic now.
6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.
This statement seems kind of contradictory to me If 6to4 is causing "headaches" that means hosts must have been using it. Googles stats also indicate that a load of clients were using it at one stage though that number has dropped off more recently
6to4 provided an easy way for people to build experience with ipv6 without having to agree to a possibly onerous list of terms from some tunnel provider and provides a way for users to access v6 only resources (which aren't very numerous yet but they can only become numerous if everyone can reach them) with only a v4 internet connection.
Having said that 6to4 does have it it's problems. Firstly running over IP directly may have made it slightly more efficient but it also meant it couldn't really be run behind a NAT box, it would have made far more sense to run it over UDP which can easilly be port forwarded. Secondly and more importantly it has performance and reliability problems because ISPs don't take it seriously. If every dual stack PoP had a 6to4 relay router then 6to4 would be fast and reliable but they don't so 6to4 traffic ends up handled by benevolent third parties who may or may not provide acceptable quality of service.
BS
There was a load of talk about hierarchical routing when IPv6 was being developed but what we actualy ended up with was much the same as we have with IPv4, autonomous systems advertise prefixes over BGP which combine to produce a massive routing table. The table will have less cruft than the IPv4 one both because it's newer (The IPv4 table contains a lot of cruft like legacy allocations where an equivilent allocation wouldn't be PI under current rules, multiple seperate allocations for companies whose IP space needs have grown and so-on) and because IPv6 gives the RIRs room to make allocations sparsely allowing them to extend existing allocations rather than making new ones but that isn't really relavent here..
As with IPv4 autonomous systems are able to route things as they wish within their own networks and as with IPv4 some autonomous systems span multiple continents and as with IPv4 some users traffic may pass for considerable distances over non-ip networks (or tunneled over a non-internet ip network) before entering the providers "general routing" (for example most smaller ISPs in the UK have only on PoP).
Further allocation procedures may make geolocation worse for IPv6 than IPv4. IIRC the default allocation to an ISP is a /32 so if the ISP only gives out a /56 or smaller by default they will probably never need to get any more IPs (how many ISPs really have more than 16 million customers) which means they won't need to worry too much about keeping the RIR happy. I know when I get an IP from freenet6's dutch gateway the geoipv6 database lists it as being in canada.
normal people off the street have to jump through so many hoop to own an automatic weapon now (fingerprinting, extensive background check, letter of endorsement from local head law enforcement official, tax stamp, etc.) that VERY few do so
IIRC someone recently produced a special holder in which you could place a semi automatic gun which would cause your finger to release from the trigger when it recoiled and then spring it back pushing your finger back into the trigger giving you effectively full auto fire without the gun itself being full auto.
Dunno if anyone has used one in a crime yet though.
The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses.
That sounds like a bad idea from multiple perspectives, first there is the issue of finding hardware capable of doing it (or finding load balancing hardware). Secondly it means that if routing in the ISP network chooses a different exit point then a different NAT will be used which will break existing sessions. Thirdly if the ISP provides hosting or premium connections with public IPs and a private IP user connects to them then it may not get natted which may cause problems. Fourthly having routing to multiple NATs will break many nat traversal techniques.
If NAT has to happen (and for some ISPs NAT or a similar IP sharing system WILL have to happen) it's much better if it happens near the edge where there is only really a single route. If the ISPs management systems want to see the private addresses then that can easilly be arranged which keeping the NATs near the edge by adding an exception to the NAT rule.
This means a national scale ISP like Comcast could probably function on a /16.
Comcasts problem is they want to keep a flat network for managing their devices and there simply aren't enough private v4 IPs to do that. That is why they are working to move as much as possible to IPv6.
It's perfectly possible to run a PPP server with static mappings from logins to addresses (of course this means you can only have one client at a time per set of login details but that isn't usually too much of a problem).
The ISP determines whether the prefix is allocated statically or dynamically, the end user determines whether the addresses within the prefix are allocated statically or dynamically. If the prefix is static then trackers can use it to track down to the premisis level regardless of whether the addresses within the prefix are static or dynamic. If the prefix is dynamic then it makes network administration a massive PITA.
mmm, that IS a problem.
There are three possible soloutions to multi-ISP operation (whether for v4 or v6), none of them great.
1: have your own IP block and advertise it over BGP. The trouble with this is that the number of people who can do it without killing the core routers is limited, so noone wants to encourage people to do it who aren't already doing so.
2: use NAT, this is what everyone does for IPv4 but it's what we are trying to get away from for v6.
3: put multiple v6 addresses on each end system. The question then becomes how quickly can you get the end systems to stop using an address block if it's associated internet connection fails.
I suspect the best compromise may be a combination of 2 and 3. Stop advertising addresses whose connectivity has failed but use NAT to bridge the gap until the clients stop using them.
Any new protocol will take years to deploy, years that we don't have.
The choices going forward at this point are IPv4 ISP level NAT, IPv4 ISP level nat in dual stack with IPv6 or IPv6 with some from of transition method (NAT64, DS-LITE etc).
Mistakes were made but they mostly weren't mistakes in the design of the core protocol, they were policy mistakes such as failing to provide any real incentive to ISPs to deploy IPv6 and doing a poor job of providing transition mechanisms for users behind v4 only NAT boxes (teredo came too late and has a fragile design). Which have resulted in lots of places leaving deployment to the last minuite.
Still big improvements have happened in recent years. A significant one was when HE very generously deployed a large number of 6to4 and teredo relays and advertised them on the public internet making those transition mechanisms far more reliable for users. Another was the implementation of the "happy eyeballs" specification in many web browsers (though sadly not in IE) to reduce delays for users with broken IPv6 connectivity and hence both reduce the chances of end users disabling IPv6 as a workaround and making website operators able to be more confident in offering AAAA records.
And I'd love to tell those ISPs that they aren't getting my business.
Which side will get what they want depends on how much competition there is and how much each side wants it. For end user ISPs in some places there is little competition so end users may be forced to accept such terms. OTOH for hosting providers there is plenty of competition. If having a full /48 is important to you i'm sure you will be able to find hosting providers who offer it.
Also, organizations that use IP phones do need as many publicly routable IP addresses as they have phones
Only if they
1: use the braindead but sadly popular protocol called SIP that doesn't play nice with NAT.
2: try to route that protocol over the open internet directly from individual phones
If the organisation does the sensible thing and routes all phones through a PBX then this isn't really an issue. Only the PBX needs public IP space.
Also, the most common form of NAT used is Port Address Translation, and in this one, one needs more routable IPv4 addresses - just 1 won't do. And so even NAT can't for the long run alleviate the demand on IPv4 addresses.
There is a limit to the number of customers per IP address but it's high enough that most ISPs who deploy NAT won't be running out of IPs in the foreseeable future. If world population increases by orders of magnitude we may have a problem but frankly if world population increases that much we are likely to have bigger problems.
if you know it weighed X in 2000, and it weighs Y in 2013 whats the problem
The problem is we DON'T know that. We know that the kilogram prototypes are gradually diverging in mass but we don't know which one is most correct or whether the group as a whole is gaining or losing mass. The cleaning procedures are supposed to remove contamination (and no matter how careful you are some contaimination is inevitable) without removing the actual metal of the prototype but afaict we have no real way of knowing how effectively they achieve that goal. Nor do we really know how much wear there is from handling the things.
Isn't the definition of a gram the mass of 1 cm3 of water?
No, that was how it was initially defined but in 1799 they moved to using metal prototypes.
Would this not be a standard you could employ in any lab without the need for the international 1Kg prototypes?
It's trickier than it sounds. Between the difficulty of accurately measuring out the liquid, the fact that density changes with temperature and pressure, the fact that isotopic mixes can vary and the fact that our units of pressure are in themselves based on the kilogram making the definition recursive this becomes a difficult definition to apply accurately.
There is talk of moving to a definition based on fundamental physical units but it's difficult to get the experimental results consistent and stable enough (IIRC two different methods for determining avagadros number were giving slighly different results).
. If the physical layer is trusted, then NTLM works fine. Historically, lots of corporate networks controlled every computer on the office network, and air-gapped the internet.
To what extent did they control them though? The bigger a network gets the more chance of a rouge device getting on it either through compromise of a machine that was legitimately there or through introducing a machine illegitimately.
The sensor ports on NXT bricks use I2C for communication, allowing "sensors" to be daisy chained and referred to by address.
Third party sensors generally yes, lego sensors no. Most of the lego sensors don't use I2C and the only one i'm aware of that does (the ultrasound sensor) is not readdressable.
That is why you need a device like the hitechnic sensor mux (which you admittedly did link) that can deal with all the different types of lego sensor and then present the results as an I2C device. Not cheap though.
Want to control more motors? Simply add a I2C controlled motor controller - a simple circuit to make yourself, or buy one of the commercially available options. In most cases you would use these with an external power supply (i.e. battery box).
Indeed you have to use an external battery box.
Separating "things like device power supply from device control" is as simple as making your own cables...
Not really, the NXT has no external power connection* so you can't really run it off an external battery and you can't really run your external devices off the battery in the NXT either (there is a tiny ammount of power available on the sensor ports but it's only enough for small sensors)
Using USB for these purposes rather than I2C would be far more complex. I2C is very simple to use, and is fast enough for most motor and sensor IO.
Agreed.
Overall it's nice that lego lets this third party stuff exist but you can tell it's third party hacks not a design feature of the system and the cost adds up pretty damn quick.
* The recharable battery accessory does have a charging port which can be used to supply the NXT but you wouldn't really want to use that to supply the NXT off another battery in a mobile model. I guess you could hack up a NXT battery pack to add an external power connection but that is going beyond "just making cables"
Since typically (as far as I recall) mindstorm programs are loaded into the brick at runtime
You are kind of out of date. The RCX kept almost everything in ram (which was a PITA, take the batteries out and you had to redownload the firmware before you could program it again) but the NXT uses flash for user programs and updatable firmware.
most of the NXT sensors are just packaged up I2C sensors
Actually that is not really true at least for the lego sensors (third party sensors are another matter).
The touch sensor is a simple switch
I think the temperature sensor (not included in any kits but available for purchase seperately) is a simple thermister but i'm not positive on that.
The light and sound sensors are analog sensors with some internal electronics.
The ultrasound sensor is I2C.
I think the color sensor included in the newer NXT kits is also an analog sensor with some electronics but i'm not postive on that (note that the lego color sensor is NOT the same as the hitechnic one).
For that matter, they'd be electrically compatible with a $35 Raspberry Pi's I2C bus if they could handle 3.3V or had a 3V3-5V circuit between them.
Any one of the NXTs sensors could be easilly interfaced to a raspberry Pi. Making an interface that works with all of them is somewhat trickier. Making it work with the RCX powered sensors too is trickier still. Also I heard somewhere that lego had patents on the tricks used in the RCX powered sensor interface which may make a commerical interface that supports those sensors difficult to pull off.
It is fundamental that you can't spend more than you take in indefinitely.
Not if you can print* more.
The distinction between the federal governent and the federal reserve is little more than an accounting fiction. One that if congress agreed they could disband (of course this whole story is about congress failing to agree..............).
The reason the greeks etc are so screwed is that they gave up their financial sovereignty to the EU.
* Nowadays "printing" is something of a metaphor, most of the money in existance is created by putting numbers in databases rather than by putting numbers on bits of paper.
eSATA has a couple of practical problems. Firstly if you set the SATA mode to "ATA" for ease of installing an older OS you often lose your eSATA port. Secondly most computers with eSATA only had one port and practically speaking eSATA is limited to one device per port. Port multipliers exist in theory but not all controllers support them, you can only have one level of them and i've only ever seen them integrated in drive enclosures not as a seperate product. Thirdly power was an afterthought hacked in later (eSATAp) so most eSATA drives needed a seperate cable for power. Finally eSATA has no backwards compatibility with any previous interface standard, some drives do support both eSATA and USB but you still need different cables.
In summary eSATA is fine if you have run out of drive bays and want an extra drive or are concerned about security and want to lock your drive in your safe when you go away so you have a drive that is external but lives with a single machine. It's not a good choice for a drive that is carried around and used with many machines.
10 Gbps is probablly overkill for current storage needs but SSDs keep getting quicker. Higher speeds also raise the possibility of graphics over USB3. The recent GPU switching stuff has shown that PCs now have enough internal bandwidth and the GPU vendors can be pushed to cooperate enough that a direct path from GPU to display output is not actually needed.
End of an era.
If you want printed photos on the go there are still options available.
Fujifilm have an instant photo product, due to patent license issues it wasn't widely available in the west during polaroid's heyday but with polariod out of the picture major vendors in the west have started stocking it. Search for "instax" on amazon and you'll find it.
There is also impossible who have made new film for the old polariod cameras. However it is a LOT more expensive than the instax stuff.
Finally there are portable photo printers that you can use with a digital camera. This has the advantage of being able to print a copy for the locals and keep a digital copy for yourself. Power may be an issue in some places though I guess.
Polariod's problem was it's VERY hard for companies to successfully scale down. There is still a market for analogue instant photography but it is a MUCH smaller market than it was in the days when it was the only way to get photos quickly.
ARIN has been pretty clear they don't want carrier grade NAT.
Well if the RIRs didn't want it they should have put some incentives in place to deploy IPv6. If they had made new v4 allocations to ISPs conditional on making IPv6 available to all customers and supported by all new customer premisis equipment supplied by the ISP then we wouldn't be in this mess now.
Growing ISPs are going to have no choice but to deploy some kind of mechanism for users to access v4 resources without giving those users a public V4 IP. There are basically 3 choices.
1: Run an IPv6 access network and use some mechanism (NAT64 or ds-lite, some kind of tunneled port based address sharing) to make access to the IPv4 internet available over that v6 access network.
2: Run a dual stack access network with public v6 and private v4 and an ISP level NAT
3: Run a IPv4 access network with private addresses and an ISP level NAT.
Round here (UK) most mobile providers are already giving out private v4 IPs and running NAT. Landline providers are still generally giving out public v4 IPs for the moment. Few providers seem to be showing much interest in making IPv6 available to customers. Our main telco is apparently even running a broken 6to4 relay in their network on the anycast address ( http://www2.warwick.ac.uk/fac/sci/csc/people/computingstaff/jaroslaw_zachwieja/bt_fttc_ipv6/ ). Given this situation I just don't have any confidence that ISPs will go the IPv6 route.
I suspect the ad networks don't want to go down that road because it raises the bar for putting ads on your website. Also click tracking is an issue, if it's left up to the hoster of the site then click fraud becomes much easier, if it's done by the ad networks then it provides something that can be matched by a blocker.
Of course this move by free may force their hand.
In England, we are lucky, most geolocation services get the city info wrong,
AIUI the free geolocation services are basically built on freely available data while the pay services supplement that with data from their own research. If the ISPs don't make the data easilly available (I don't think there is any obligation on an ISP to post where in the country and allocation is being used) the free databases won't have it. If the ISPs put users from different places in one subnet then the pay databases won't have it either.
But when I wrote that post I wasn't thinking of publically available geolocation services, I was thinking of the government (who can demand information from your ISP) and possiblly big companies (who can correlate IPs used for one activity with those used for another).
I dread to think what would happen if we had to give them the line noise that is an IP6 address.
IPv6 addresses don't HAVE to look like line noise. Yes they are longer but that length gives you more freedom to maintain an addressing pattern that matches your network rather than having to pack things in a massively dense fashion. The main thing is to avoid using stateless autoconfiguration for any IP a user is likely to need to interact with.
Having said that there is really no reason to not continue using private IPv4 for logging into boxes regardless of whether they have a v6 IP to let them access resources on v6 networks (public or private).
Not millions
With conventional NAT reserving a port on the public side for each connection I doubt you'd want to go more than about a hundred customers per IP (and even that may be pushing it if your customer base is high activity). Dedicated high ratio nats that resused the same source port for connections to different servers may let go up to say a thousand customers per IP but
Still even a 1:10 ratio would mean that most ISPs wouldn't have to worry about exhaustion on the consumer side for a long time and on the hosting side SNI should become practical to deploy in a couple of years dramatically reducing IP space requirements for shared hosting.
I hope that ISPs will offer IPv6 before they start forcing users behind NAT but I wouldn't rely on it.
If you are designing a new deployment now I STRONGLY advise you to avoid relying on the ability to accept incoming connections to equipment located in homes or small offices and to minimise the number of public v4 addresses you need in your central facilities (could be just one to terminate IPv6 over UDP tunnels from the homes and small offices).