EV charging is inherently either a dumb load or an algorithmic ADAPTIVE& Smart- citizen of the grid.
The problem is to be an "algorithmic ADAPTIVE& Smart- citizen of the grid." requries information the charger simply doesn't have. There are a handful of clues, frequency tells you about total load vs generation on the grid as a whole but tells you nothing about local conditions. Volt drop may give you some clue as to how stressed the local system is but it won't tell you about a cable that is short but thin coming up towards it's maximum load and it's very likely to give false positives (where the car thinks the system is stressed when it isn't) on long cables.
To really make a smart load relies on infrastructure that doesn't currently exist. You need sensors at the house intake to indicate when the house wiring is overstressed, then sensors in the neighbourhood to indicate when neighbourhood wiring is overstressed and so-on back through the distribution grid. Then you need some way of feeding that information to the smart loads.
The problem is not the succesful compiles, hardware is cheap enough as you say.
The problem is when you build with a new and exotic set of options (and sometimes even when you don't) you WILL run into software that fails to build. You have to work out why, then come out with a fix, then either carry that fix locally forever forward porting it with each new version or convince upstream that your fix is worthwhile to accept. Even if upstream do accept your fix you may find that they break it again later.
x32 is especially fun because a lot of software sees it as "x86 like" or "x64 like" and proceeds to try and fail to use inline assembler.
When you are building one or two apps this isn't too much of a problem, when you are trying to rebuild something the size of a major desktop/server linux distro it can become decidedly nontrivial
Given that linux already allows 32-bit x86 processes on a 64-bit kernel to use the full 32-bit address space I don't see why they wouldn't allow x32 processes to do the same.
Windows limits 32-bit processes on a 64-bit kernel to 2GB by default as a precaution against sloppy pointer handling but this can be turned off by makring the program as large address aware.
32-bit kernels generally limit user processes to significantly less than 4GB because it is more efficient to have kernel and user memory in different parts of the same address space than to perform an addresses space switch every time the kernel needs to read data from user mode memory. Having said that there did at one stage exist "4G/4G patches" for linux to allow user processes to use nearly all the adress space at the cost of making kernel access to user memory slower.
* Specfically consider what happens if you convert two pointers to signed integers and then compare them.
I thought the interest in this was coming from vendors of budget VM/cloud hosting. When you are stacking massive numbers of VMs on a host ram can become a limiting factor on how many VMs you can put on a host but at the same time it would be nice to actually take advantage of those x64 cores and since you are running lots of different things rather than lots of copies of one big thing fixing the software to be less pointer heavy is not really a practical option.
BUT having to have two copies of all the libraries in each VM would kill the advantages, so to really take advantage of this they need to first get a good quality port of a full linux userland, then fight through the politics of actually getting it included in at least one major distro (an unofficial port of sid isn't going to cut it for pursuading people it's a viable and maintainable option for their servers).
One complication with x32 is that in terms of conditional defines it looks much like x86-64. So this means that a lot of software will try and fail to use x86-64 assembler and will therefore need fixing (either to port or disable the assembler, prefferablly the former).
What mass market devices are that that need or are likely to need in the forseeable future more than USB3 (which the new mac pro also offers) can deliver.
I would expect thunderbolt to remain a niche product much like firewire did but also like firewire I would not expect it to go away any time soon.
One nice thing about thunderbolt is it's PCIe derived. So it is relatively easy to design and make high performance adaptors from thunderbolt to virtually anything. There are already thunderbolt to fiber channel, thunderbolt to firewire, thunderbolt to SAS, thunderbolt to gigabit ethernet and thunderbolt to PCIe slot adaptors out there.
I understand that there are significant variations between CPU architectures. For example, the Xeon supports ECC memory, whereas the i7 does not. That's a notable difference between these two processors, and relevant to this thread.
AIUI High end desktop and 1-4 socket workstation/server are basically the same designs but with the crippling set differently* The 1-4 socket server parts have overclocking locked out, the desktop parts have dual socket support and ECC memory support locked out. The ammount of enabled cache also varies a little. But fundamentally it's the same core and bus design and in most applications one would expect similar performance.
* Afaict you can't by a version with everything enabled at any price.
Maybe this is an opportunity for mac shops to refurbish those old pro's, and put the new hardware in there?
This brings an interesting question of "what part is legally the computer"
That is if you replace the motherboard in a mac pro with a non-apple one is it still legally a mac and can you still legally sell it with mac os X installed? Would you want to spend a heck of a lot of money designing a motherboard that would fit easilly in a mac pro case only to have a court rule that your motherboard replacement made the computer no longer legally a mac?
If you can't replace the motherboard then you are stuck putting in better components from the same era. That might extend the machines life a little bit but it's not a long term soloution.
Total memory is the significant metric, not the number of slots it fits into. And that's 12/16 GB vs 6/12GB for the older versions.
According to wikipedia at least the old model supported 64GB (8x4GB) officially and 128GB (8x8GB) unofficially while the new model only supports 64GB (4x8GB).
So it's no improvement if you look at the ofifical apple numbers and a downgrade if you look at what the aftermarket vendors found was actually possible.
Apple used to have the server line for people with rack mount needs
And when they discontinued it they suggested that people put mac pros on shelves in racks as an alternative, dunno if anyone actually did or not (the density was horriblly low but if you are dependent on mac os X servers and mac minis are insufficient. what else do you do?)
Windows 7 is still available. You can still buy retail, retail upgrade and system builder copies of win7, you can also downgrade from OEM and volume license copies of windows 8 pro/ultimate/enterprise (IIRC for some silly reason you can't downgrade from retail or retail upgrade copies).
This is partly AMD's fault. They decided that 64-bit mode would not include Virtual 8086 mode. [wikipedia.org]
That is true and would have made it difficult to support DOS apps.
It does not affect running 16 bit windows apps. AIUI the only reason 16 bit windows apps are not supported on 64-bit windows is because microsoft could not be bothered debugging the compbination of WoW64 with WoW. Amusingly 64-bit linux can run 16 bit windows apps.
I don't think that is the big issue though, I don't think there is that much win16 code still floating arround and if you really need it you can get 32-bit editions of up to date versions of windows. The real problem afaict is that app developers tied into bits of the OS that were never supposed to be public interfaces or relied on undocumented behaviours or ignored guidelines on how to work with windows security. MS put in a lot of hacks in win7 to support such applications while improving the general security situation but ultimately those hacks were not perfect and there will often be something in a large and poorly coded application that doesn't work. If that something is something you rely on you have a problem.
the problem is while there may be some people who would either keep the systems away from the internet and other infection sources or pay the fee for updates the vast majority of home and small buisness users wont. They will just take the risk and keep using those systems on the internet.
Which brings us back to the problem, on the one hand it's not reasonable to expect a software vendor to support something for free forever, on the other hand the realistic alternative to supporting it free forever is an internet full of machines with no security patches making life easier for botnet operators.
Even with the "internet of things" I wonder how well this will work, if you make migration dependent on asking the "losing" carrier then that losing carrier has every motivation to make that process as slow and difficult as possible. If you allow the "gaining" carrier to grab the device you run the risk of devices being migrated without the owners permission by dodgy carriers.
Note: the lock tab on a SD card doesn't actually do anything inside the card, it merely activates a contact on the socket.
Whether that contact is used to implement a hardware write lock, a software write lock or no write lock at all is entirely dependent on the designer of the system you plug the SD card into.
I'm not convinced of that. Swapping a sim is something I can do myself quickly and easilly/. ill I be able to reprogram these myself or will I have to call up one or possiblly both of the carriers involved and ask them to do it? how long will that take? hours? days? will scummy "virtual carriers" be able to "hijack" devices and bring them onto their "network" without the owners permission? will it be reasonablly possible to transfer a device between carriers in different countries?
An address isn't actually a public key, it's the hash of a public key. So what you actually need to find to spend the bitcoins is an ECDSA keypair where the public key hashes to the address. I presume they did it this way to make addresses shorter (at the cost of making transactions in the blockchain longer).
But the principle remains, it's not "impossible" to go from a bitcoin address to a set of keys that can be used to spend coins from that addresses but it is "computationally infeasible" given current public knowledge of the crypto primitives involved and current or reasonablly forseable computing power.
What really matters is both the ammount of current through the body and the path it takes. With shocks from low impedance sources (like the mains) the current through the body is determined by the supply voltage and the resistance of the body. So while voltage isn't the only factor it certainly does make a big difference. Double the supply voltage and you will double the current increasing the risk of the current being high enough to be fatal.
Voltages under about 50V (the exact limit varies by what regulatory body you look at) are classed as "extra low voltage" and generally regarded
220VAC 60Hz at 30A on the other hand, would more than likely result in muscle seizures and likely clamping, eventually followed by death by one of the previously mentioned methods.
I know plenty of people who have had shocks of UK 240V mains (heck i've had several myself when I was younger and less careful). It certainly can kill but it's not "certain death".
POTS phone lines run power at 5 V DC, but the ring signal is generated by increasing the voltage. The spec is to bump the voltage up to 20 or 30 V DC (it's been a while since I worked with these).
Do you have a source for that claim
My understanding was that POTS lines were about 48V DC idle with the phone on hook, dropping to about 10V-20V when the phone is off hook and with an 90V or so AC voltage superimposed on the DC voltage during ringing.
In the UK they fortify food but rather than putting a full selection in each food they only put a subset in. For example bread is usually forified with vitamin C but no others. Cereals seem to be fortified with a load of vitamins but not C. So if you eat a lot of different foods you get a reasonable coverage but if you eat a diet with little variety then you can easilly end up missing some out.
Phone and cable TV services are required to do certain things that were considered to be in the public interest. Phone companies were required to put in place special infrastructure for priority emergency calls. TV companies were required to carry local broadcast channels if the channel asked for it. Historically this made sense, when the cable networks were built in the US* they were providing totally different services, so it made sense for them to be subject to different regulations.
However since then techology has changed, you can use the phone over your cable modem using VOIP and you can watch TV over your telco provided internet connection and you can watch TV and use VOIP over your IP based fiber connection. In many cases the VOIP and IPTV services are even bundled with the internet connection.
So you have three groups of companies providing effectively the same services but subject to vastly different regulations. IMO there is a need to decide if those regulations are still in the public interest and if they are deemed to be in the public interest to figure out how to apply them fairly to last mile communication providers who use vastly different infrastructures.
So I would agree with you that the regs need to be reviewed and updated but I also agree with the GP that google seem to want a privilage that is given to telcos and cablecos without taking on the responsibilities that come with being either being a telco or begin a cableco and I could see why existing telcos and cablecos would be rightly pissed off about that.
* Here in the UK things played out a bit differently, our cable companies were also phone companies from the start and ran analog phone pairs alongside the cable TV coax.
Rural electrification doesn't require a separate circuit for each customer.
Electricity supply requires progressively higher capacity circuits as you combine more customers. Rural electricity supply also requires a substantial outdoor transformer for every isolated customer or cluster of customers.
Most* FTTH deployments i've read details of seem to be going for a PON system where a fiber from the exchange is shared between about 30 subscribers through a passive splitter. So in terms of number of circuits from the exchange it's probablly less than the party lines of old.
* B4RN being an exception, they went for seperate fibers from their switching locations to the end users.
Slashdot Mirror
EV charging is inherently either a dumb load or an algorithmic ADAPTIVE& Smart- citizen of the grid.
The problem is to be an "algorithmic ADAPTIVE& Smart- citizen of the grid." requries information the charger simply doesn't have. There are a handful of clues, frequency tells you about total load vs generation on the grid as a whole but tells you nothing about local conditions. Volt drop may give you some clue as to how stressed the local system is but it won't tell you about a cable that is short but thin coming up towards it's maximum load and it's very likely to give false positives (where the car thinks the system is stressed when it isn't) on long cables.
To really make a smart load relies on infrastructure that doesn't currently exist. You need sensors at the house intake to indicate when the house wiring is overstressed, then sensors in the neighbourhood to indicate when neighbourhood wiring is overstressed and so-on back through the distribution grid. Then you need some way of feeding that information to the smart loads.
I would have been blaming the WRONG PARTY
Is it really wrong to blame the company who told you they had your package when they didn't?
The problem is not the succesful compiles, hardware is cheap enough as you say.
The problem is when you build with a new and exotic set of options (and sometimes even when you don't) you WILL run into software that fails to build. You have to work out why, then come out with a fix, then either carry that fix locally forever forward porting it with each new version or convince upstream that your fix is worthwhile to accept. Even if upstream do accept your fix you may find that they break it again later.
x32 is especially fun because a lot of software sees it as "x86 like" or "x64 like" and proceeds to try and fail to use inline assembler.
When you are building one or two apps this isn't too much of a problem, when you are trying to rebuild something the size of a major desktop/server linux distro it can become decidedly nontrivial
Given that linux already allows 32-bit x86 processes on a 64-bit kernel to use the full 32-bit address space I don't see why they wouldn't allow x32 processes to do the same.
Windows limits 32-bit processes on a 64-bit kernel to 2GB by default as a precaution against sloppy pointer handling but this can be turned off by makring the program as large address aware.
32-bit kernels generally limit user processes to significantly less than 4GB because it is more efficient to have kernel and user memory in different parts of the same address space than to perform an addresses space switch every time the kernel needs to read data from user mode memory. Having said that there did at one stage exist "4G/4G patches" for linux to allow user processes to use nearly all the adress space at the cost of making kernel access to user memory slower.
* Specfically consider what happens if you convert two pointers to signed integers and then compare them.
I thought the interest in this was coming from vendors of budget VM/cloud hosting. When you are stacking massive numbers of VMs on a host ram can become a limiting factor on how many VMs you can put on a host but at the same time it would be nice to actually take advantage of those x64 cores and since you are running lots of different things rather than lots of copies of one big thing fixing the software to be less pointer heavy is not really a practical option.
BUT having to have two copies of all the libraries in each VM would kill the advantages, so to really take advantage of this they need to first get a good quality port of a full linux userland, then fight through the politics of actually getting it included in at least one major distro (an unofficial port of sid isn't going to cut it for pursuading people it's a viable and maintainable option for their servers).
One complication with x32 is that in terms of conditional defines it looks much like x86-64. So this means that a lot of software will try and fail to use x86-64 assembler and will therefore need fixing (either to port or disable the assembler, prefferablly the former).
What mass market devices are that that need or are likely to need in the forseeable future more than USB3 (which the new mac pro also offers) can deliver.
I would expect thunderbolt to remain a niche product much like firewire did but also like firewire I would not expect it to go away any time soon.
One nice thing about thunderbolt is it's PCIe derived. So it is relatively easy to design and make high performance adaptors from thunderbolt to virtually anything. There are already thunderbolt to fiber channel, thunderbolt to firewire, thunderbolt to SAS, thunderbolt to gigabit ethernet and thunderbolt to PCIe slot adaptors out there.
I understand that there are significant variations between CPU architectures. For example, the Xeon supports ECC memory, whereas the i7 does not. That's a notable difference between these two processors, and relevant to this thread.
AIUI High end desktop and 1-4 socket workstation/server are basically the same designs but with the crippling set differently* The 1-4 socket server parts have overclocking locked out, the desktop parts have dual socket support and ECC memory support locked out. The ammount of enabled cache also varies a little. But fundamentally it's the same core and bus design and in most applications one would expect similar performance.
* Afaict you can't by a version with everything enabled at any price.
According to apple max memory is 64GB (4x16GB), has anyone tried larger configurations yet? (AIUI apple often understates max memory)
Maybe this is an opportunity for mac shops to refurbish those old pro's, and put the new hardware in there?
This brings an interesting question of "what part is legally the computer"
That is if you replace the motherboard in a mac pro with a non-apple one is it still legally a mac and can you still legally sell it with mac os X installed? Would you want to spend a heck of a lot of money designing a motherboard that would fit easilly in a mac pro case only to have a court rule that your motherboard replacement made the computer no longer legally a mac?
If you can't replace the motherboard then you are stuck putting in better components from the same era. That might extend the machines life a little bit but it's not a long term soloution.
Total memory is the significant metric, not the number of slots it fits into. And that's 12/16 GB vs 6/12GB for the older versions.
According to wikipedia at least the old model supported 64GB (8x4GB) officially and 128GB (8x8GB) unofficially while the new model only supports 64GB (4x8GB).
So it's no improvement if you look at the ofifical apple numbers and a downgrade if you look at what the aftermarket vendors found was actually possible.
Apple used to have the server line for people with rack mount needs
And when they discontinued it they suggested that people put mac pros on shelves in racks as an alternative, dunno if anyone actually did or not (the density was horriblly low but if you are dependent on mac os X servers and mac minis are insufficient. what else do you do?)
Windows 7 is still available. You can still buy retail, retail upgrade and system builder copies of win7, you can also downgrade from OEM and volume license copies of windows 8 pro/ultimate/enterprise (IIRC for some silly reason you can't downgrade from retail or retail upgrade copies).
This is partly AMD's fault. They decided that 64-bit mode would not include Virtual 8086 mode. [wikipedia.org]
That is true and would have made it difficult to support DOS apps.
It does not affect running 16 bit windows apps. AIUI the only reason 16 bit windows apps are not supported on 64-bit windows is because microsoft could not be bothered debugging the compbination of WoW64 with WoW. Amusingly 64-bit linux can run 16 bit windows apps.
I don't think that is the big issue though, I don't think there is that much win16 code still floating arround and if you really need it you can get 32-bit editions of up to date versions of windows. The real problem afaict is that app developers tied into bits of the OS that were never supposed to be public interfaces or relied on undocumented behaviours or ignored guidelines on how to work with windows security. MS put in a lot of hacks in win7 to support such applications while improving the general security situation but ultimately those hacks were not perfect and there will often be something in a large and poorly coded application that doesn't work. If that something is something you rely on you have a problem.
the problem is while there may be some people who would either keep the systems away from the internet and other infection sources or pay the fee for updates the vast majority of home and small buisness users wont. They will just take the risk and keep using those systems on the internet.
Which brings us back to the problem, on the one hand it's not reasonable to expect a software vendor to support something for free forever, on the other hand the realistic alternative to supporting it free forever is an internet full of machines with no security patches making life easier for botnet operators.
Even with the "internet of things" I wonder how well this will work, if you make migration dependent on asking the "losing" carrier then that losing carrier has every motivation to make that process as slow and difficult as possible. If you allow the "gaining" carrier to grab the device you run the risk of devices being migrated without the owners permission by dodgy carriers.
SD cards have the same.
Note: the lock tab on a SD card doesn't actually do anything inside the card, it merely activates a contact on the socket.
Whether that contact is used to implement a hardware write lock, a software write lock or no write lock at all is entirely dependent on the designer of the system you plug the SD card into.
I'm not convinced of that. Swapping a sim is something I can do myself quickly and easilly/. ill I be able to reprogram these myself or will I have to call up one or possiblly both of the carriers involved and ask them to do it? how long will that take? hours? days? will scummy "virtual carriers" be able to "hijack" devices and bring them onto their "network" without the owners permission? will it be reasonablly possible to transfer a device between carriers in different countries?
If they planned to do that then they were dumb to collect them into a single address like that.
An address isn't actually a public key, it's the hash of a public key. So what you actually need to find to spend the bitcoins is an ECDSA keypair where the public key hashes to the address. I presume they did it this way to make addresses shorter (at the cost of making transactions in the blockchain longer).
But the principle remains, it's not "impossible" to go from a bitcoin address to a set of keys that can be used to spend coins from that addresses but it is "computationally infeasible" given current public knowledge of the crypto primitives involved and current or reasonablly forseable computing power.
What really matters is both the ammount of current through the body and the path it takes. With shocks from low impedance sources (like the mains) the current through the body is determined by the supply voltage and the resistance of the body. So while voltage isn't the only factor it certainly does make a big difference. Double the supply voltage and you will double the current increasing the risk of the current being high enough to be fatal.
Voltages under about 50V (the exact limit varies by what regulatory body you look at) are classed as "extra low voltage" and generally regarded
220VAC 60Hz at 30A on the other hand, would more than likely result in muscle seizures and likely clamping, eventually followed by death by one of the previously mentioned methods.
I know plenty of people who have had shocks of UK 240V mains (heck i've had several myself when I was younger and less careful). It certainly can kill but it's not "certain death".
POTS phone lines run power at 5 V DC, but the ring signal is generated by increasing the voltage. The spec is to bump the voltage up to 20 or 30 V DC (it's been a while since I worked with these).
Do you have a source for that claim
My understanding was that POTS lines were about 48V DC idle with the phone on hook, dropping to about 10V-20V when the phone is off hook and with an 90V or so AC voltage superimposed on the DC voltage during ringing.
It depends,
In the UK they fortify food but rather than putting a full selection in each food they only put a subset in. For example bread is usually forified with vitamin C but no others. Cereals seem to be fortified with a load of vitamins but not C. So if you eat a lot of different foods you get a reasonable coverage but if you eat a diet with little variety then you can easilly end up missing some out.
out of interest what aspect(s) of it do you find to be a PITA?
Phone and cable TV services are required to do certain things that were considered to be in the public interest. Phone companies were required to put in place special infrastructure for priority emergency calls. TV companies were required to carry local broadcast channels if the channel asked for it. Historically this made sense, when the cable networks were built in the US* they were providing totally different services, so it made sense for them to be subject to different regulations.
However since then techology has changed, you can use the phone over your cable modem using VOIP and you can watch TV over your telco provided internet connection and you can watch TV and use VOIP over your IP based fiber connection. In many cases the VOIP and IPTV services are even bundled with the internet connection.
So you have three groups of companies providing effectively the same services but subject to vastly different regulations. IMO there is a need to decide if those regulations are still in the public interest and if they are deemed to be in the public interest to figure out how to apply them fairly to last mile communication providers who use vastly different infrastructures.
So I would agree with you that the regs need to be reviewed and updated but I also agree with the GP that google seem to want a privilage that is given to telcos and cablecos without taking on the responsibilities that come with being either being a telco or begin a cableco and I could see why existing telcos and cablecos would be rightly pissed off about that.
* Here in the UK things played out a bit differently, our cable companies were also phone companies from the start and ran analog phone pairs alongside the cable TV coax.
Rural electrification doesn't require a separate circuit for each customer.
Electricity supply requires progressively higher capacity circuits as you combine more customers. Rural electricity supply also requires a substantial outdoor transformer for every isolated customer or cluster of customers.
Most* FTTH deployments i've read details of seem to be going for a PON system where a fiber from the exchange is shared between about 30 subscribers through a passive splitter. So in terms of number of circuits from the exchange it's probablly less than the party lines of old.
* B4RN being an exception, they went for seperate fibers from their switching locations to the end users.