but no amount of computing power would give them the ability to change the rules (because cryptography).
That depends.
If you have more than half the hashing power then you can unilaterally make the rules tighter. Blocks contining transactions that do not satisfy your rules will not be used as a base to mine on by your miners and so will be quickly forked off. For example you could require a transaction fee of a minimum percentage of the transaction value or you could require that all bitcoin addresses were registered in a govrnment database.
On the other hand you cannot unilaterally make the rules looser without forking the network.
My guess is that they are trying to catch people who intend to or have in the past worked illegally in the USA while pretending to be tourists. Some fraction of those people will be dumb enough to blab about it on social media and dumb enough to give details of said social media account to the border gaurds.
No really, the Romans build it, since those pesky Picts wanted their independence so badly. It's called Hadrian's wall and you can walk along it.
And if you had ever walked along it you would know in it's present state it's more of a ruin than an effective barrier wall. You would also know it doesn't line up with the modern England/Scotland border.
So you believe they're buying routers and switches that can't do ipv6, rather than that they simply haven't changed a config file to turn it on for the end user?
As I understand it reality is somewhere between those two extremes.
Afaict pushing out IPv6 consists of
1. Making sure the hardware and software in your network (including CPE if you provide it) *really* supports it, not just has a checkbox on the feature list for "IPv6" but can handle IPv6 with comparable features, performance and reliability to IPv4. Some hardware can have a long lifecycle so this can take a while. 2. Coming up with a plan for allocating addresses and distributing addresses to customers and routes to routers. Since NAT is strongly discouraged you need to have a system that hands out not just individual addresses but blocks and that tells your routers which customer has which block. 3. Training all your suppport and admin staff on IPv6. 4. Running limited trials to make sure you actually did 1-3 successfully and you can turn it on without breaking things and causing a massive support load. 5. Actually pushing it out.
That's doable but it's a fair bit of work. Until recently there was little motivation to do so. Now with IPv4 exhaustion actually upon us the ISPs are starting to take IPv6 more seriously.
I don't know about medical products but there are loads of cheap chinese suppliers selling dangerous electronic goods into the UK through amazon and ebay.
The rule you are thinking of only applies to cabin baggage, not to hold baggage or cargo. If you had put your diet coke in your hold baggage it would have been perfectly acceptable.
but something named "Amazing Liquid Fire" can?
If it's in a cardboard shipping box they will probablly never see the name on the bottle. An x-ray may tell them there is some liquid in there but it's unlikely to tell them more than that.
* NAT tends to fail closed, if the NAT rules aren't loaded then traffic simply doesn't get through. Tradtional firewalling can easilly fail open. * Lack of NAT means potential attackers get clues about the layout of your internal network. * NAT lets you manage the addressing on your internal network without being subserviant to an ISP (PI space does the same but getting PI space is quite a beuracratic process and if everyone got PI space we would have a routing table disaster on our hands)
On the weekend people use home and mobile networks more, during the week they use corporate networks more.
For mobile the client device (phone) connects directly to the ISP. So the ISP just has to turn on v6. For home the client device connects to a home router. This device is usually supplied by the ISP and it's firmware can be updated to automate IPv6 rollout. For corporate network the corps network admins need to understand IPv6, come up with a plan for deploying it and then actually deploy it.
A number of large home and mobile providers (comcast, T-mobile USA, sky UK, free.fr) have been pushing out IPv6 by default over the past few years. Afaict there has been no similar push among corporate network admins.
Thus, a given/32 will be doled out only to a single RIR, who can break it up into smaller units to LIR's, to eventually be broken into/48,/64, and/56's for destination routers.
RIRs get allocated blocks much bigger than a/32 which they then split up into/32 (or sometimes larger) blocks to allocate to LIRs (LIRs are normally ISPs, hosting providers etc). The RIRs also allocate provider independent/48 blocks to end networks. Each of those LIRs and each of those networks with PI space will advertise it's addresses into the global routing table.
There were proposals for a more heirachical allocation and routing scheme but they never really worked out because the internet is NOT a heirachy. It's a collection of networks with constantly shifting relationships.
For many years you could not get IPv6 PI space. The proposal instead was that you ran multiple prefixes in paralell and relied on experimental DNS features (look up A6 and DNAME) to put the multiple addresses in DNS. End hosts would then have to decide which IP it was best to use to contact a given other end host even though end hosts normally have no clue about internet routing. As you can imagine that idea went down like a lead balloon. In the mid to late 2000s (afaict ARIN did it in 2006, APNIC in 2007 and RIPE in 2009) the RIRs relented and made provider independent IPv6 space available.
According to the site you linked the IPv6 routing table is currently about half the size of the IPv4 one. It will be interesting to see how big the IPv6 routing table ends up if/when the world completes the move to IPv6. On the one hand there will be less legacy crap and less need to make extra allocations because a network ran out of addresses. On the other hand since NAT is discouraged I would expect more companies to go for PI space.
Not nobody but certainly a lot less than is desirable.
This has been the steady state for what, 20 years?
Unfortunately people don't do stuff until there is real pressure to do so. As the IPv4 crunch has started to bite harder providers have started to take IPv6 more seriously. Theres still a long way to go but there has been a real increase in adoption over the past few years. https://www.google.com/intl/en...
We probably should re-do the thing and skip to IPv9 with a less grandiose than this second system but a nice and functional third.
Yes the IPv6 proponents had some grandiose but half-baked ideas. To name a few Heirachical routing, abandonment of NAT, mandatory IPsec, site local addresses, A6 and DNAME, Stateless mac-address based autoconfiguration.
But yet another new system isn't going to help anyone, the problems can and have been solved while keeping the core protocol compatible.
The heirachical routing crap has already been dropped in favor of using the same routing methods as are used for IPv4. A6 and DNAME have been abandoned in favour of letting companies get PI space like they can for IPv4. NAT is still discouraged but there are implementations available for those who want/need it and protocols have been put in place to delegate prefixes to customer networks automatically. Mandatory ipsec has been abandoned. Site local addresses have been replaced by the far more sensible "unique local addresses" which acknowlage that "site" is an ill-defined concept. Mechanisms have been put in place that allow running a V6 only access network while still providing limited IPv4 functionality for clients (there are two competing options for this DS-Lite and NAT64) . We have privacy extensions to avoid MAC address based tracking with stateless autoconfiguration or alteratively you can use DHCPv6 instead.
Perhaps with a different crew this time. That'd be nice.
I think we already have a different crew, we now have people who work at real ISPs designing IPv6 soloutions that really work.
I guess there just isn't much to say about this story, debian point releases are not exactly massively interesting things. So all that's left are those with an axe to grind about Debian in general.
The big question for those looking to upgrade "broadband" speeds is whether it's a good idea to install active outdoor infrastructure to go from fiber to faster shorter DSL lines or whether it makes more sense to take fiber all the way to the customer premisis.
How many compilers support multi-threaded compiling? I can't find any reference that says Visual C++ complies using multiple threads, but of course that doesn't mean that it doesn't (just that I'm not hitting on the right question) but I'm curious if it does?
At least in the C/C++ world paralellism isn't done in the compiler itself, it's done by running multiple instances of the compiler at once working on different files. gnu make can easilly do this, dunno what things are like in the MS world but I'd be surprised if they don't have a soloution.
Most references that I found mentioned that compiling a large project is pretty disk intensive and people recommended a SSD and more ram to speed compilation?
Yes if you build a buildbox round one of these you will need to make sure the rest of the system is up to supporting the CPU cores. What that entails will depend on what exactly it is you are building. The platform supports 128GB of ram which I would imagine would be more than adequate to support 10 paralell compilers and at the same time have a ramdisk for the build tree to avoid IO bottlenecks.
At least in the C/C++ world most compiles are done on a per-file basis and then linked together at the end. So it's no problem to compile multiple files at once (provided your memory and storage can keep up).
So make it a 35% flat tax on gross income, no deductions. You know, what it works out to for regular people when you stack in VAT/sales tax, corporate fees passed off as taxes (USF, etc).
Say hello to a world where vertically integrated megacorps rule because their income is only taxed once while money flowing through a series of smaller less-integrated buisnesses is taxed multiple times.
That is why for buisnesses we tax profits rather than income, so it is transparent to the tax system whether the value is created in one large megacorp or a chain of smaller buisnesses.
The drugs used in current "leathal injection executions" are tightly controlled and tracked and there are only a handful of manufacturers for each drug. So a handful of manufacturers can put a spanner in the works.
Trying to stop a US state getting it's hands on nitrogen would be much harder. It's about 80% of the air and pretty easy to seperate.
Machines with 64+GB of memory are still quite rare.
16GB desktop (unregistered non-ecc ddr4) modules are now available at reasonable prices, so you should be able to do 64GB on a mainstream desktop platform and 128GB on a high end desktop platform now.
I figure about £750 for the bits to build a computer with 64GB and about £1500 for the bits to build a computer with 128GB. Compared to the cost of pro camera equipment that is quite cheap.
The VPU code is a blob but the arm-side code is open.
However there is indeed an issue, communication between the driver in the kernel and the VPU is broken with the current experimental 64-bit kernels because the system assumes a kernel pointer can fit in 32 bits. It's probablly possible to fix this from the arm side with some tricks though.
The arm cores on the Raspberry Pi 3 are 64-bit capable (it's a quad-core A53 cluster). The core bus system and memory controller are limited to 1GB (it uses the upper bits as flags). By default the firmware starts the arm cores in 32-bit mode. There is an option in config.txt to change this. There is a small peice of arm-side init code that normally runs after the firmware brings the arm out of reset but before the kernel loads. This is 32-bit only but can be disabled by options in config.txt. Community members have got a 64-bit kernel and u-boot working (u-boot replaces the functionality that was provided by the arm-side init code). AIUI it's still pretty experimental though.
No, Mike and I built Raspbian. The raspberry pi foundation then built their images from raspbian packages and their own customisations on top (just as prior to raspbian they had built images from Debian with their own customisations on top). Gradually the volume of customisations they apply has increased.
This article is entirely about customisations they apply on top of raspbian.
They basically boil down to if the package builds and noone reports that it's broken (either because it's not broken on because noone actually tried it) then it gets shipped. Some packages have build time test suites but of course that only tests that the package works on the CPU the autobuilder happens to have, not on the minimum CPU for the port. Maintainers usually do some testing before uploading but generally only on one architecture unless they are working on an architecture specific bug.
The south doesn't seem a whole lot better. I just looked up watford to hertford on google. Half an hour by car, an hour and a half by daytime public transport (and worse at this time of night).
Slashdot Mirror
but no amount of computing power would give them the ability to change the rules (because cryptography).
That depends.
If you have more than half the hashing power then you can unilaterally make the rules tighter. Blocks contining transactions that do not satisfy your rules will not be used as a base to mine on by your miners and so will be quickly forked off. For example you could require a transaction fee of a minimum percentage of the transaction value or you could require that all bitcoin addresses were registered in a govrnment database.
On the other hand you cannot unilaterally make the rules looser without forking the network.
My guess is that they are trying to catch people who intend to or have in the past worked illegally in the USA while pretending to be tourists. Some fraction of those people will be dumb enough to blab about it on social media and dumb enough to give details of said social media account to the border gaurds.
No really, the Romans build it, since those pesky Picts wanted their independence so badly. It's called Hadrian's wall and you can walk along it.
And if you had ever walked along it you would know in it's present state it's more of a ruin than an effective barrier wall. You would also know it doesn't line up with the modern England/Scotland border.
So you believe they're buying routers and switches that can't do ipv6, rather than that they simply haven't changed a config file to turn it on for the end user?
As I understand it reality is somewhere between those two extremes.
Afaict pushing out IPv6 consists of
1. Making sure the hardware and software in your network (including CPE if you provide it) *really* supports it, not just has a checkbox on the feature list for "IPv6" but can handle IPv6 with comparable features, performance and reliability to IPv4. Some hardware can have a long lifecycle so this can take a while.
2. Coming up with a plan for allocating addresses and distributing addresses to customers and routes to routers. Since NAT is strongly discouraged you need to have a system that hands out not just individual addresses but blocks and that tells your routers which customer has which block.
3. Training all your suppport and admin staff on IPv6.
4. Running limited trials to make sure you actually did 1-3 successfully and you can turn it on without breaking things and causing a massive support load.
5. Actually pushing it out.
That's doable but it's a fair bit of work. Until recently there was little motivation to do so. Now with IPv4 exhaustion actually upon us the ISPs are starting to take IPv6 more seriously.
I don't know about medical products but there are loads of cheap chinese suppliers selling dangerous electronic goods into the UK through amazon and ebay.
My Diet Coke can't make it past airport security
The rule you are thinking of only applies to cabin baggage, not to hold baggage or cargo. If you had put your diet coke in your hold baggage it would have been perfectly acceptable.
but something named "Amazing Liquid Fire" can?
If it's in a cardboard shipping box they will probablly never see the name on the bottle. An x-ray may tell them there is some liquid in there but it's unlikely to tell them more than that.
Sorry I was wrong about table sizes, the IPv4 table is currently about 20 times the size of the IPv6 one, not twice the size.
To be fair I can understand why.
* NAT tends to fail closed, if the NAT rules aren't loaded then traffic simply doesn't get through. Tradtional firewalling can easilly fail open.
* Lack of NAT means potential attackers get clues about the layout of your internal network.
* NAT lets you manage the addressing on your internal network without being subserviant to an ISP (PI space does the same but getting PI space is quite a beuracratic process and if everyone got PI space we would have a routing table disaster on our hands)
On the weekend people use home and mobile networks more, during the week they use corporate networks more.
For mobile the client device (phone) connects directly to the ISP. So the ISP just has to turn on v6.
For home the client device connects to a home router. This device is usually supplied by the ISP and it's firmware can be updated to automate IPv6 rollout.
For corporate network the corps network admins need to understand IPv6, come up with a plan for deploying it and then actually deploy it.
A number of large home and mobile providers (comcast, T-mobile USA, sky UK, free.fr) have been pushing out IPv6 by default over the past few years. Afaict there has been no similar push among corporate network admins.
Thus, a given /32 will be doled out only to a single RIR, who can break it up into smaller units to LIR's, to eventually be broken into /48, /64, and /56's for destination routers.
RIRs get allocated blocks much bigger than a /32 which they then split up into /32 (or sometimes larger) blocks to allocate to LIRs (LIRs are normally ISPs, hosting providers etc). The RIRs also allocate provider independent /48 blocks to end networks. Each of those LIRs and each of those networks with PI space will advertise it's addresses into the global routing table.
There were proposals for a more heirachical allocation and routing scheme but they never really worked out because the internet is NOT a heirachy. It's a collection of networks with constantly shifting relationships.
For many years you could not get IPv6 PI space. The proposal instead was that you ran multiple prefixes in paralell and relied on experimental DNS features (look up A6 and DNAME) to put the multiple addresses in DNS. End hosts would then have to decide which IP it was best to use to contact a given other end host even though end hosts normally have no clue about internet routing. As you can imagine that idea went down like a lead balloon. In the mid to late 2000s (afaict ARIN did it in 2006, APNIC in 2007 and RIPE in 2009) the RIRs relented and made provider independent IPv6 space available.
According to the site you linked the IPv6 routing table is currently about half the size of the IPv4 one. It will be interesting to see how big the IPv6 routing table ends up if/when the world completes the move to IPv6. On the one hand there will be less legacy crap and less need to make extra allocations because a network ran out of addresses. On the other hand since NAT is discouraged I would expect more companies to go for PI space.
Everybody should be using it, but nobody does.
Not nobody but certainly a lot less than is desirable.
This has been the steady state for what, 20 years?
Unfortunately people don't do stuff until there is real pressure to do so. As the IPv4 crunch has started to bite harder providers have started to take IPv6 more seriously. Theres still a long way to go but there has been a real increase in adoption over the past few years. https://www.google.com/intl/en...
We probably should re-do the thing and skip to IPv9 with a less grandiose than this second system but a nice and functional third.
Yes the IPv6 proponents had some grandiose but half-baked ideas. To name a few Heirachical routing, abandonment of NAT, mandatory IPsec, site local addresses, A6 and DNAME, Stateless mac-address based autoconfiguration.
But yet another new system isn't going to help anyone, the problems can and have been solved while keeping the core protocol compatible.
The heirachical routing crap has already been dropped in favor of using the same routing methods as are used for IPv4. A6 and DNAME have been abandoned in favour of letting companies get PI space like they can for IPv4. NAT is still discouraged but there are implementations available for those who want/need it and protocols have been put in place to delegate prefixes to customer networks automatically. Mandatory ipsec has been abandoned. Site local addresses have been replaced by the far more sensible "unique local addresses" which acknowlage that "site" is an ill-defined concept. Mechanisms have been put in place that allow running a V6 only access network while still providing limited IPv4 functionality for clients (there are two competing options for this DS-Lite and NAT64) . We have privacy extensions to avoid MAC address based tracking with stateless autoconfiguration or alteratively you can use DHCPv6 instead.
Perhaps with a different crew this time. That'd be nice.
I think we already have a different crew, we now have people who work at real ISPs designing IPv6 soloutions that really work.
Score 0 is what ACs get by default.
I guess there just isn't much to say about this story, debian point releases are not exactly massively interesting things. So all that's left are those with an axe to grind about Debian in general.
DSL can go faster if the distances are short.
The big question for those looking to upgrade "broadband" speeds is whether it's a good idea to install active outdoor infrastructure to go from fiber to faster shorter DSL lines or whether it makes more sense to take fiber all the way to the customer premisis.
How many compilers support multi-threaded compiling? I can't find any reference that says Visual C++ complies using multiple threads, but of course that doesn't mean that it doesn't (just that I'm not hitting on the right question) but I'm curious if it does?
At least in the C/C++ world paralellism isn't done in the compiler itself, it's done by running multiple instances of the compiler at once working on different files. gnu make can easilly do this, dunno what things are like in the MS world but I'd be surprised if they don't have a soloution.
Most references that I found mentioned that compiling a large project is pretty disk intensive and people recommended a SSD and more ram to speed compilation?
Yes if you build a buildbox round one of these you will need to make sure the rest of the system is up to supporting the CPU cores. What that entails will depend on what exactly it is you are building. The platform supports 128GB of ram which I would imagine would be more than adequate to support 10 paralell compilers and at the same time have a ramdisk for the build tree to avoid IO bottlenecks.
At least in the C/C++ world most compiles are done on a per-file basis and then linked together at the end. So it's no problem to compile multiple files at once (provided your memory and storage can keep up).
So make it a 35% flat tax on gross income, no deductions. You know, what it works out to for regular people when you stack in VAT/sales tax, corporate fees passed off as taxes (USF, etc).
Say hello to a world where vertically integrated megacorps rule because their income is only taxed once while money flowing through a series of smaller less-integrated buisnesses is taxed multiple times.
That is why for buisnesses we tax profits rather than income, so it is transparent to the tax system whether the value is created in one large megacorp or a chain of smaller buisnesses.
The drugs used in current "leathal injection executions" are tightly controlled and tracked and there are only a handful of manufacturers for each drug. So a handful of manufacturers can put a spanner in the works.
Trying to stop a US state getting it's hands on nitrogen would be much harder. It's about 80% of the air and pretty easy to seperate.
Machines with 64+GB of memory are still quite rare.
16GB desktop (unregistered non-ecc ddr4) modules are now available at reasonable prices, so you should be able to do 64GB on a mainstream desktop platform and 128GB on a high end desktop platform now.
I figure about £750 for the bits to build a computer with 64GB and about £1500 for the bits to build a computer with 128GB. Compared to the cost of pro camera equipment that is quite cheap.
The VPU code is a blob but the arm-side code is open.
However there is indeed an issue, communication between the driver in the kernel and the VPU is broken with the current experimental 64-bit kernels because the system assumes a kernel pointer can fit in 32 bits. It's probablly possible to fix this from the arm side with some tricks though.
To clarify
The arm cores on the Raspberry Pi 3 are 64-bit capable (it's a quad-core A53 cluster).
The core bus system and memory controller are limited to 1GB (it uses the upper bits as flags).
By default the firmware starts the arm cores in 32-bit mode. There is an option in config.txt to change this.
There is a small peice of arm-side init code that normally runs after the firmware brings the arm out of reset but before the kernel loads. This is 32-bit only but can be disabled by options in config.txt.
Community members have got a 64-bit kernel and u-boot working (u-boot replaces the functionality that was provided by the arm-side init code). AIUI it's still pretty experimental though.
No, Mike and I built Raspbian. The raspberry pi foundation then built their images from raspbian packages and their own customisations on top (just as prior to raspbian they had built images from Debian with their own customisations on top). Gradually the volume of customisations they apply has increased.
This article is entirely about customisations they apply on top of raspbian.
To be really pedantic it's about the stuff the raspberry pi foundation build on top of raspbian.
I thought the RPI was a tiny little ARM computer that you could do embedded stuff with.
The aim was to be a computer that kids could treat as their own and experiment on.
Plently of people used them to do embedded stuff with but that wasn't the primary goal.
Now it's got its own, distinct UI?
Yeah, stock LXDE carried them through the first few years but more recently they have decided to start customising things.
I'm not privy to Debian release standards
They basically boil down to if the package builds and noone reports that it's broken (either because it's not broken on because noone actually tried it) then it gets shipped. Some packages have build time test suites but of course that only tests that the package works on the CPU the autobuilder happens to have, not on the minimum CPU for the port. Maintainers usually do some testing before uploading but generally only on one architecture unless they are working on an architecture specific bug.
The south doesn't seem a whole lot better. I just looked up watford to hertford on google. Half an hour by car, an hour and a half by daytime public transport (and worse at this time of night).