Yeah, I know that, I was just responding to the simpleminded idea that "Oh, you want an air conditioner that'll run off some solar panels with no inverter? Just get the AC unit out of a Prius and hook it up!" It's just not that simple.
The AC in a prius runs directly off of the HV DC batter pack. Go find a junked prius and loot the AC if you need some DC powered cooling.
No, the Prius air conditioner compressor is AC. The Prius inverter electronics converts the HVDC to the correct AC frequency to run the motor. So you'd need both the compressor and inverter assembly, which also includes the inverters for the motor-generators that move the car. And a 200V DC power supply. And all the right computers to get the inverter assembly to do something useful.
You'd wind up with a whole bunch of a Prius just to get a silly air conditioner.
The Prius also uses an electric air-conditioning compressor motor so that cabin cooling is maintained even when running in electric mode only. A second dc/ac inverter, with circuits located on a second ICU controller circuit board ringed with TO-packaged IGBTs, is deployed to power the electric A/C compressor from the HV battery pack. The A/C inverter IGBT packages are bolted to one face of the substantial heat-sinking enclosure of the ICU.
You must be joking. We would be in deep trouble if flash memory held its information for only about a year.
Nope, not joking. It also depends on the process size. Nice big (i.e. low capacity in a large die size) SLC flash cells hold data for quite a long time. The higher-density they get (and the less electrons per bit used to store data) the worse it gets.
So a lot of device firmwares and BIOSes, which generally use nice big chunky flash cells, will last 10-20 years. High-capacity flash storage, not so much.
That's just the way it is. Flash is currently the least worst solid state storage solution we have, but it still sucks.
(Note that if your device is powered on occasionally the flash can error-check and rewrite itself, which at least partially "resets" the time for data loss. This is only an issue for devices that are constantly powered off or devices that will not rewrite themselves as required.)
From this article here it appears that shingled hard drives are not completely random-access for writes. They will probably need some sort of flash-like translation layer to support normal file systems. (Or Seagate has provided that layer internally like SSDs do, in which case as a first-generation device it is probably buggy and will lose your data...)
The bloody MUSB driver/OMAP hardware combination caused me to have to write this horrible thing:
local kmsg = io.open('/proc/kmsg', 'r')
for line in kmsg:lines() do
--...
--elseif line:match('USB IS HORKED %- HELP PLEASE!') then
----local reset_usb =
------io.open('/sys/devices/platform/<product>-kludges/reset_usb', 'w')
----reset_usb:write('1\n')
----reset_usb:close()
----log.log('Reset USB')
--end
end
...because some (rare) USB devices would occasionally cause the harware to basically completely lock up when plugged in. I could identify this and cry for help from within the driver, but the only way I found to successfully unkludge it was to completely remove and reinstall the kernel device, thereby completely reinitializing the device and driver.
Fortunately(?) it looks like this product is unlikely to actually ship...
Yeah, Youtube now only encodes 360p and 720p single-file versions of videos at this point; if you don't support DASH, that's all you get. Notably 480p doesn't seem to be on this list generally. Firefox itself won't support enough MSE to run Youtube until (I think) v31, bug here.
Youtube uses EME for 1080p streams, no EME and you only get 720p or lower
Youtube uses Media Source Extensions for 1080p streams. That's completely different; it's a way to source data to a <video> element from Javascript. They use it to implement their dynamic HTTP streaming, where rather than just sucking down a file you suck down individual file segments allowing dynamic quality adjustments based on your available bandwidth. There's no DRM involved.
And Git's hashes are not for the sake of security. Linus made that abundantly clear when he refused to allow SHA-2 to be used, even after people were able to manufacture a Git collision using SHA-1.
Citation needed. I can't find a published example of any actual SHA-1 collision, much less one from a Git repo.
The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.
BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.
Something like a config option - 'Enable OS installation for one boot cycle.'
If the purpose of secureboot were just to secure the boot process, that's all it'd take.
That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.
The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.
Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.
Home video was traditionally 24 or fewer frames per second. (Unless by "traditionally" you mean the past few years when you could record digital video at more than 30 frames per second.)
The GP poster is correct. Super 8mm film is not "video" and hence is not "home video". NTSC VHS is absolutely 60 fields per second. The only way to get 24 FPS on VHS is with 3:2 pulldown, which no consumer cameras I know of ever did. Even getting close to a "real" simultaneously-sampled 30 frames per second instead of 60 interlaced fields would require a sample-and-hold, which again consumer VHS camcorders didn't have AFAIK.
You should have updated to IPv6, where is no such checksum in TCP.
I think you're misinformed. IPv6 has no IP header checksum, unlike IPv4. However, the higher-level protocol checksums are still there; in fact, UDP over IPv6 is required to include a valid checksum, unlike in IPv4 where it can optionally be 0x0000.
No it's not. Gmail (and most of Google's other high-profile Web stuff) is written with their Closure tools, which is JavaScript-based. Wave was GWT (their Java cross-compiler), but that was about it for public services other than the AdWords admin interface.
Even with a Facebook page, you still have an asininely-short arbitrary limit to the size of status updates that, given the length of Linus's update, doesn't appear to apply to Google+.
As an additional factor, who other than GoDaddy supports both DNSSEC and easy-and-prompt-to-configure IPv6 glue records? I specifically moved from Network Solutions to GoDaddy because it took NetSol weeks to set up my IPv6 glue. (Their interface at the time was "Email us at ipv6req@networksolutions.com and we'll get around to it eventually. Maybe." Maybe they've added it to their admin interface at this point...)
Couldn't the ISP's DNS return a bogus IPv4 address for somecorp.com and then rewrite packets sent to that address as IPv6 packets to somecorp.com's IPv6 address?
This is called NAT46 and is one of the myriad transition strategies available in both directions. It is much more complicated than NAT64, though, since you need a giant state table synchronized between a router and DNS server, and you need to "waste" some IPv4 space for the mapping, which is in short supply. (NAT64 only needs to keep state in the router, since you can embed the literal v4 address inside a v6 address.)
Or I can forward whatever protocol number to my VPN server. The fact that NAT is possible does not mean that I have to limit yourself to one external IP. If I have two VPN servers I can use two external IPs for them.
IPsec AH headers protect the integrity of the source and destination IP addresses (by design), so if those are modified in any way by NAT things will break.
Anyway, you are clearly okay with NAT's limitations. I am not; I only use it out of necessity. Different strokes...
Breaking trough NAT without port forwarding - sure. The only reason why the protocol might not work with NAT with port forwarding is if it for some reason does not trust the header of the packet and adds a copy of the IP address in the data section (like ftp does).
That's not the only reason. IPsec, for instance, has to be wrapped inside UDP (called IPsec NAT-T) to break through NATs since IPsec was designed to be run directly on top of IP, where there is no concept of ports to forward! Any attempt to go beyond TCP and UDP runs horribly afoul of NATs.
So, I can make a packet destined to 1::2 port 80 (hmm, with IPv4 I can write 1.2.3.4:80, is some other symbol used for marking the port number? 1::2:3:4:80 could be confusing?) actually go to 1::3 port 80?
(To put a literal IPv6 address in a URL you write http://[2001:db8::1]:80/. I suspect other places expecting a colon-separated port number will use a similar scheme.)
Great - it means I can still publish only one IP and do the port mappings, which makes this "almost" NAT.
So, the only thing that cannot be done is rewriting the source IP field on outgoing connections (not packets, since for port forwarding to work it has to work both ways)?
Yes, not unless you use a proxy. Simple inbound port forwarding doesn't need to be implemented as some fancy stack-level kernel feature like NAT; you just need a process listening on a port that, upon accepting, makes a connection to another IP and port and copies the data in both directions. The classic cheesy way to implement this is to throw a line in inetd.conf that calls "nc ip port", though for things like HTTP an application-specific reverse proxy will work a lot better and possibly take some of the load off of your web server(s) if it caches.
It's likely a fair amount of NAT-like behavior will be written for IPv6 to support implementing transparent proxies, which do have to happen at the stack level. I just want the amount of NATted traffic on the Internet at large to be on the opposite end of the bell curve than it is now, since with IPv6 it will be unnecessary to "share an Internet connection" in the same way as IPv4.
The point is, I do not want NAT to be imposed on everyone. I just want the option of doing whatever I want to the packets that enter and leave my network, including changing the address fields, for whatever reason. If something does not work for me because of NAT that I myself placed there, so be it, I'll find a workaround or, if it really bugs me, stop using NAT.
...
There is no reason not to have NAT as an option.
If this were the only side-effect, than sure. But a lot of protocols in use today (peer-to-peer filesharing, VOIP, VPN, etc.) have had horrible kludges built into them to ensure that they can break through NAT and still work. NAT is also a huge barrier to entry to interesting new transport layer protocols like SCTP, since it absolutely requires specialized code in the NAT router.
If you want to NAT IPv6 for no particularly good reason, and the world breaks for you, that's fine, but if anybody has to waste time abusing perfectly good future protocols to work with IPv6 NAT the damage is much more substantial than you. And if the myth that NAT provides a useful service persists, the market will demand such hacks.
As I said in reply to another post, i might want to make example.com:80 and example.com:21 connect to different physical (or virtual) servers. Without modifying DNS and doing the whole www.example.com and ftp.example.com thing.
So make your router (or other box) explicitly do port forwarding and/or load-balancing; it's effectively what you're using NAT for here and would likely be more flexible.
Slashdot Mirror
Yeah, I know that, I was just responding to the simpleminded idea that "Oh, you want an air conditioner that'll run off some solar panels with no inverter? Just get the AC unit out of a Prius and hook it up!" It's just not that simple.
No, the Prius air conditioner compressor is AC. The Prius inverter electronics converts the HVDC to the correct AC frequency to run the motor. So you'd need both the compressor and inverter assembly, which also includes the inverters for the motor-generators that move the car. And a 200V DC power supply. And all the right computers to get the inverter assembly to do something useful.
You'd wind up with a whole bunch of a Prius just to get a silly air conditioner.
From Special Issue: Inside the Toyota Prius: Part 5 - Inverter/converter is Prius' power broker:
You must be joking. We would be in deep trouble if flash memory held its information for only about a year.
Nope, not joking. It also depends on the process size. Nice big (i.e. low capacity in a large die size) SLC flash cells hold data for quite a long time. The higher-density they get (and the less electrons per bit used to store data) the worse it gets.
So a lot of device firmwares and BIOSes, which generally use nice big chunky flash cells, will last 10-20 years. High-capacity flash storage, not so much.
That's just the way it is. Flash is currently the least worst solid state storage solution we have, but it still sucks.
(Note that if your device is powered on occasionally the flash can error-check and rewrite itself, which at least partially "resets" the time for data loss. This is only an issue for devices that are constantly powered off or devices that will not rewrite themselves as required.)
From this article here it appears that shingled hard drives are not completely random-access for writes. They will probably need some sort of flash-like translation layer to support normal file systems. (Or Seagate has provided that layer internally like SSDs do, in which case as a first-generation device it is probably buggy and will lose your data...)
Wait, so now we aren't setting read/write status in fstab anymore?
How do you set filesystem read/write status for just the ntpdate process in fstab?
Ugh.
The bloody MUSB driver/OMAP hardware combination caused me to have to write this horrible thing:
...because some (rare) USB devices would occasionally cause the harware to basically completely lock up when plugged in. I could identify this and cry for help from within the driver, but the only way I found to successfully unkludge it was to completely remove and reinstall the kernel device, thereby completely reinitializing the device and driver.
Fortunately(?) it looks like this product is unlikely to actually ship...
Yeah, Youtube now only encodes 360p and 720p single-file versions of videos at this point; if you don't support DASH, that's all you get. Notably 480p doesn't seem to be on this list generally. Firefox itself won't support enough MSE to run Youtube until (I think) v31, bug here.
Youtube uses EME for 1080p streams, no EME and you only get 720p or lower
Youtube uses Media Source Extensions for 1080p streams. That's completely different; it's a way to source data to a <video> element from Javascript. They use it to implement their dynamic HTTP streaming, where rather than just sucking down a file you suck down individual file segments allowing dynamic quality adjustments based on your available bandwidth. There's no DRM involved.
Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action...
Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.
They're working on it.
And Git's hashes are not for the sake of security. Linus made that abundantly clear when he refused to allow SHA-2 to be used, even after people were able to manufacture a Git collision using SHA-1.
Citation needed. I can't find a published example of any actual SHA-1 collision, much less one from a Git repo.
They could embrace gender equality and rename themselves the Hacker Guides.
The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.
BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.
Something like a config option - 'Enable OS installation for one boot cycle.'
If the purpose of secureboot were just to secure the boot process, that's all it'd take.
That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.
The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.
Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.
What are you talking about?
Home video was traditionally 24 or fewer frames per second. (Unless by "traditionally" you mean the past few years when you could record digital video at more than 30 frames per second.)
The GP poster is correct. Super 8mm film is not "video" and hence is not "home video". NTSC VHS is absolutely 60 fields per second. The only way to get 24 FPS on VHS is with 3:2 pulldown, which no consumer cameras I know of ever did. Even getting close to a "real" simultaneously-sampled 30 frames per second instead of 60 interlaced fields would require a sample-and-hold, which again consumer VHS camcorders didn't have AFAIK.
I think you're misinformed. IPv6 has no IP header checksum, unlike IPv4. However, the higher-level protocol checksums are still there; in fact, UDP over IPv6 is required to include a valid checksum, unlike in IPv4 where it can optionally be 0x0000.
No it's not. Gmail (and most of Google's other high-profile Web stuff) is written with their Closure tools, which is JavaScript-based. Wave was GWT (their Java cross-compiler), but that was about it for public services other than the AdWords admin interface.
Even with a Facebook page, you still have an asininely-short arbitrary limit to the size of status updates that, given the length of Linus's update, doesn't appear to apply to Google+.
As an additional factor, who other than GoDaddy supports both DNSSEC and easy-and-prompt-to-configure IPv6 glue records? I specifically moved from Network Solutions to GoDaddy because it took NetSol weeks to set up my IPv6 glue. (Their interface at the time was "Email us at ipv6req@networksolutions.com and we'll get around to it eventually. Maybe." Maybe they've added it to their admin interface at this point...)
At the IPv4 burn rate of the last month, Ford's space would last only another 10 days. IPv4's done; stick a fork in it and start moving on.
They run their oil at 40C. If the dew point in your server room is that high you have other problems...
This is called NAT46 and is one of the myriad transition strategies available in both directions. It is much more complicated than NAT64, though, since you need a giant state table synchronized between a router and DNS server, and you need to "waste" some IPv4 space for the mapping, which is in short supply. (NAT64 only needs to keep state in the router, since you can embed the literal v4 address inside a v6 address.)
IPsec AH headers protect the integrity of the source and destination IP addresses (by design), so if those are modified in any way by NAT things will break.
Anyway, you are clearly okay with NAT's limitations. I am not; I only use it out of necessity. Different strokes...
That's not the only reason. IPsec, for instance, has to be wrapped inside UDP (called IPsec NAT-T) to break through NATs since IPsec was designed to be run directly on top of IP, where there is no concept of ports to forward! Any attempt to go beyond TCP and UDP runs horribly afoul of NATs.
(To put a literal IPv6 address in a URL you write http://[2001:db8::1]:80/. I suspect other places expecting a colon-separated port number will use a similar scheme.)
Yes, not unless you use a proxy. Simple inbound port forwarding doesn't need to be implemented as some fancy stack-level kernel feature like NAT; you just need a process listening on a port that, upon accepting, makes a connection to another IP and port and copies the data in both directions. The classic cheesy way to implement this is to throw a line in inetd.conf that calls "nc ip port", though for things like HTTP an application-specific reverse proxy will work a lot better and possibly take some of the load off of your web server(s) if it caches.
It's likely a fair amount of NAT-like behavior will be written for IPv6 to support implementing transparent proxies, which do have to happen at the stack level. I just want the amount of NATted traffic on the Internet at large to be on the opposite end of the bell curve than it is now, since with IPv6 it will be unnecessary to "share an Internet connection" in the same way as IPv4.
If this were the only side-effect, than sure. But a lot of protocols in use today (peer-to-peer filesharing, VOIP, VPN, etc.) have had horrible kludges built into them to ensure that they can break through NAT and still work. NAT is also a huge barrier to entry to interesting new transport layer protocols like SCTP, since it absolutely requires specialized code in the NAT router.
If you want to NAT IPv6 for no particularly good reason, and the world breaks for you, that's fine, but if anybody has to waste time abusing perfectly good future protocols to work with IPv6 NAT the damage is much more substantial than you. And if the myth that NAT provides a useful service persists, the market will demand such hacks.
So make your router (or other box) explicitly do port forwarding and/or load-balancing; it's effectively what you're using NAT for here and would likely be more flexible.