The main problem is that it's currently impossible to send binary data via XHR in Chrome without it getting eaten. What appears to happen is that everything gets "encoded" in UTF-8, which obviously is going to be a dog's breakfast. Even when using a BlobBuilder I just could *not* prevent things getting eaten when passing to xhr.send().
Firefox has a xhr.sendAsBinary() method that "just works". Nothing more needs to be said. Use xhr.sendAsBinary() instead of xhr.send() and all your problems are gone overnight. Oh, except for the fact that sendAsBinary() is non-standard and not supported in Chrome.
I ended up choosing the latter of two workarounds: using FileReader.readAsDataURL() (which encodes into base64) and unpacking the data: URL on the remote end, or using a FormData() object and using FormData.append() to place my File inside there.
Yeah, I have a Motorola Milestone (GSM version of the same device) and it is also 550 MHz. My battery is about 30-40% when I plug it in at night, and if an app decides to misbehave, the phone is sometimes flat even before I get home from work.
McAfee is second only to Norton in the amount of effort required to remove it, and the resources it hogs.
MCPR.exe hasn't failed for me yet. That said, with regards to resource hogging -- I'll give you that. One of the many reasons we have switched to Sophos at work. 50 PCs now running Sophos -- we're never looking back.
In a perfect world, we'd be running some kind of Unix that doesn't encourage you to run as root all day long, but until that day arrives, we're stuck with supporting those that haven't yet made the switch.
(If your router is anything like my OpenWrt one, if you don't run DHCPv6-PD, you'll get a dynamic/64 address on the ppp0 interface, but nothing on your LAN interface. You *could* then manually advertise that on the eth0 interface
My apologies — the end of my message seems to have been cut off. I can't remember what I was going to write, but hey. You should get the gist.
You do not need to sign up for Internode's IPv6 trial.
All you have to do is change the domain in your username from "internode.on.net" to "ipv6.internode.on.net". Then, make sure IPv6 is enabled in your pppd config (e.g. check the "IPv6" box on your router, or on Debian, just add a line "ipv6," to/etc/ppp/peers/dsl-provider) and you should be away.
You'll also need to run a DHCPv6-PD client if you want the static/60 subnet, which if you bought one of the IPv6-ready routers from Internode wiil already be supported. Or on, say, Debian, just install the wide-dhcpv6-client software and you will get the static/60 subnet they are allocating.
(If your router is anything like my OpenWrt one, if you don't run DHCPv6-PD, you'll get a dynamic/64 address on the ppp0 interface, but nothing on your LAN interface. You *could* then manually advertise that on the eth0 interface
My only complaint is that it doesn't remember passwords the way AndFTP does (another excellent tool, by the way). I'd like to not have to type in the darned password every time, but oh well, it's a lot better than no ssh.
I've never typed a password to log on to any of my machines with ConnectBot. Nor am I planning to. There is no need for a password remembering feature (nor can I imagine there ever will be), because SSH keys makes that redundant.
Yes, but for those examples there are other barriers to entry.
To own your own home, you have to make a large financial investment.
And hire a qualified electrician to install cabling inside the house, to reinforce your point.
People try to draw a line between electric cabling and using a computer, based on the false assumption that if you screw up electric cabling you die, whereas if you screw up your own computer, it only affects you.
That's a bogus assumption because the reality is that we have this thing called the "Internet". You know, a community of networks, where computers actually talk to each other. And, you know, cause havoc on each other's networks.
If you crash the car in your own paddock, that's okay -- it's your car, and your paddock. But if you drive irresponsibly on the road, especially a highway, which is a commons of road drivers, you suddenly have the ability to cause a lot more harm.
It's the same with the Internet. If you own a PC, and you connect it to the Internet, you have a responsibility as a citizen of the Internet (and the world, pretty much) to be conscientious to others. An infected PC is not a laughing matter — you’re actively harming someone or something whether you’re aware of it or not. If you're not prepared to take due care, you should be treated like the cops would treat you if you were an unlicensed drive — you shouldn't be allowed on the Internet.
Its 2010 and the fact you still have to explain to people how a digital connection works is getting old.
Yes, the data going through the USB may be digital, but as I have shown, the USB power, not data can cause interference.
For a vinyl ripper, the USB power has the ability to interfere with the audio while it's still analogue, before its conversion to digital prior to being sent over USB.
One would hope a vinyl ripper would use an external source of power and shield the USB well.
Uh, what? USB means that the ADC is outside the computer, which means that you get less possibility of EM noise from the electronics in the case interfering with the analogue signal.
In theory, maybe, but in practice I get noticeable EM noise from USB.
I have a USB-powered speaker (uses a normal 3.5 mm jack for audio) for my computer which also has an earphone port on the side, which is handy. It used to be part of a HP LCD monitor (L1740 if you must know), which had a USB port for plugging the speaker into for power. Why you would design the speakers to get their power off a monitor they were specially designed to be an accessory for with USB I do not know -- surely a normal DC plug would have done the job. But I digress.
Anyway, I no longer use that monitor, but kept the USB speakers. To power them, I now plug them directly into my desktop PC's USB port for the power. Now when I plug my earphones into the side of the speaker bar, there is a noticeable hum that is directly correlated with the CPU usage. Normally it's like "bzzt zzt zzt". But if I drag a window around or compile something, it goes like "BZZT THH ZZT THH ZZT TTH ZZT".quite loudly.
It does that with two separate motherboards with two separate PSUs. However, it does not do that if I plug the USB power into my Eee PC (laptop) instead.
So there you have it. USB does suffer from EM noise. If you have a solution, I'd like to know -- it drives me batty some days.
But the truth is, sometimes you *have* to break the back button. Sometimes, you have to update portions of a page in order to keep it "fresh". Sadly, doing so breaks the back button.
A bit like how Gmail, Twitter, or many other sites don't use the document fragment identifier to do such a thing. Or a bit like how there's no such thing as history.pushState() to implement that (and because it doesn't exist, it doesn't work in Google Chrome, but if it did, it would work perfectly).
The issue isn't that it's not possible, the issue is that HTML5 seems to tend towards HTML markup over XML markup.
I don't get why that is an issue. If you want to write clean markup, write clean markup. And today's browsers are perfectly capable of handling all manner of weird and wonderful markup.
The only situation I can think of where lax HTML5 markup would cause you a problem is if you're deploying to a custom mobile device or custom-written browser for a specific deployment. But in that case, you'd likely have control over both the input and output, in which case what I said above -- just write damn clean markup -- still applies.
If I saw problems with my browser struggling to render all the HTML5 content out there, I'd agree with you. But the reality is that browsers are mature, and can deal with the markup out there. And those that are writing markup are testing. It's a cycle that is working in practice, not just theory.
There is nothing stopping you from using well-formed XML in your HTML5, or serving your document as application/xhtml+xml (explicitly stated in the HTML5 spec). Serving HTML5 as proper XML is dubbed "XHTML 5". It uses the same doctype. All the new tags -- video, audio, section, header, etc. are supported, but obviously the lax markup features of HTML5 (like being able to omit most tags) no longer apply.
Mac OS X optionally includes a case-sensitive file-system, so as with OpenGL, once ported to OS X, it should be trivial to port that area to Linux.
That said, one of the Adobe CS versions crash when installing on a case-sensitive file system (find a link yourself -- I can't be bothered at this time of the morning), and Haiku won't build unless you build on a case-sensitive file system.
Where did you get that number? The IETF slides say something like 0.07%.
I don't have that Google statistic, but I do know that Wikimedia run similar tests on Wikipedia. Here are the test results, updated daily. As of today, 2010-03-28, an AAAA breaks the request 0.39% of the time for Wikipedia users.
Those tests are done in the background to users at random by a snippet of JavaScript on Wikipedia articles.
This Google presentation says Google would lose 0.1% of traffic if they added AAAA, though it's not presented particularly prominently, so take that with a grain of salt.
Either way, adding AAAA's will break your website for some people. In my opinion, though, the number is so small it's not worth worrying about, but each to his own, I guess. All this pain will be over soon anyway. Hopefully.
For the record, I do not hate you. I just hate the tremendous stupidity that you have shown.
Such as my ability to determine that in one of your aforementioned videos, they are actually still serving the Flash widget, despite being opted-in to the HTML5 beta. (I suspect that videos that they haven't transcoded to H.264 get served as Flash still, but that's just a guess.) Right-click on it and see.
Could have double-checked that before flinging the word "stupid" at me, but hey -- takes one to know one.
Some of the stuff on YouTube is most definitely NOT H.264 because Opera plays some of it while using YouTube's test HTML5 mode.
Because your personal testimony counts for...oh wait. Nothing. You've already been told not to guess once. Take this as your second warning.
I'll believe it when I see it. Until you provide some sort of proof (URL to non-H.264 and non-FLV YouTube video would be nice), I won't believe that.
Opera usesGStreamer as a backend, and 'will also be able to use "anything that Gstreamer can handle,"'. What quite likely actually happened was that the video in fact was H.264, and was using the H.264 decoder in your system's GStreamer.
Basically, with IPv4, if you have a dynamic address (say 5.6.7.8), and then your connection drops out, and now you are a different address (say 5.8.7.6), then the machines behind your NAT aren't affected, because they're still using a 192.168.0.x 192.168.0.1 gateway thingy.
But in IPv6, what subnet your ISP allocates you (e.g. 2001:db8:1:5678::/64) influences what machines in your LAN (i.e. what would be behind your IPv4 NAT) have as their IP address.
So if your subnet your ISP gives you is 2001:db8:1:5678::/64, then a machine on your network may have an IP address of 2001:db8:1:5678:aaaa:bbbb:cccc:1234. Then, if your connection drops out, and you get a new dynamic subnet, say, 2001:db8:1:9876::/64, then your machines on the LAN will not get the new address scheme immediately, and have the wrong IP address when sending to the Internet. A whole world of hurt.
Really short durations set on the Router Advertisements may help, but there is still a window of breakage, and thus a whole world of hurt that you just don't want to foist onto your customers.
Just think -- you can give out dynamic subnets and conserve address space, but you'll have all hell break loose with the support calls. (My ISP, Internode, is sane and gives out static/60 subnets.)
Slashdot Mirror
$ php -r ::
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
Rest they can try and fill up w/ OpenStreetMaps, and hope that it fills in the difference.
You may be interested to find out that Apple are already using OpenStreetMap in iOS 6 Maps.
Yep, that's the one.
The main problem is that it's currently impossible to send binary data via XHR in Chrome without it getting eaten. What appears to happen is that everything gets "encoded" in UTF-8, which obviously is going to be a dog's breakfast. Even when using a BlobBuilder I just could *not* prevent things getting eaten when passing to xhr.send().
Firefox has a xhr.sendAsBinary() method that "just works". Nothing more needs to be said. Use xhr.sendAsBinary() instead of xhr.send() and all your problems are gone overnight. Oh, except for the fact that sendAsBinary() is non-standard and not supported in Chrome.
I ended up choosing the latter of two workarounds: using FileReader.readAsDataURL() (which encodes into base64) and unpacking the data: URL on the remote end, or using a FormData() object and using FormData.append() to place my File inside there.
It's supported, but only available to subscribers. If you're not logged on as a subscriber, it redirects you to the insecure version.
Nice touch, eh?
We don't have dust devils in Australia.
Where did you get a 300 MHz Droid?
Yeah, I have a Motorola Milestone (GSM version of the same device) and it is also 550 MHz. My battery is about 30-40% when I plug it in at night, and if an app decides to misbehave, the phone is sometimes flat even before I get home from work.
McAfee is second only to Norton in the amount of effort required to remove it, and the resources it hogs.
MCPR.exe hasn't failed for me yet. That said, with regards to resource hogging -- I'll give you that. One of the many reasons we have switched to Sophos at work. 50 PCs now running Sophos -- we're never looking back.
In a perfect world, we'd be running some kind of Unix that doesn't encourage you to run as root all day long, but until that day arrives, we're stuck with supporting those that haven't yet made the switch.
(If your router is anything like my OpenWrt one, if you don't run DHCPv6-PD, you'll get a dynamic /64 address on the ppp0 interface, but nothing on your LAN interface. You *could* then manually advertise that on the eth0 interface
My apologies — the end of my message seems to have been cut off. I can't remember what I was going to write, but hey. You should get the gist.
You do not need to sign up for Internode's IPv6 trial.
All you have to do is change the domain in your username from "internode.on.net" to "ipv6.internode.on.net". Then, make sure IPv6 is enabled in your pppd config (e.g. check the "IPv6" box on your router, or on Debian, just add a line "ipv6 ," to /etc/ppp/peers/dsl-provider) and you should be away.
You'll also need to run a DHCPv6-PD client if you want the static /60 subnet, which if you bought one of the IPv6-ready routers from Internode wiil already be supported. Or on, say, Debian, just install the wide-dhcpv6-client software and you will get the static /60 subnet they are allocating.
(If your router is anything like my OpenWrt one, if you don't run DHCPv6-PD, you'll get a dynamic /64 address on the ppp0 interface, but nothing on your LAN interface. You *could* then manually advertise that on the eth0 interface
My only complaint is that it doesn't remember passwords the way AndFTP does (another excellent tool, by the way). I'd like to not have to type in the darned password every time, but oh well, it's a lot better than no ssh.
You've never heard of SSH keys?
I've never typed a password to log on to any of my machines with ConnectBot. Nor am I planning to. There is no need for a password remembering feature (nor can I imagine there ever will be), because SSH keys makes that redundant.
[citation needed]
Yes, but for those examples there are other barriers to entry.
To own your own home, you have to make a large financial investment.
And hire a qualified electrician to install cabling inside the house, to reinforce your point.
People try to draw a line between electric cabling and using a computer, based on the false assumption that if you screw up electric cabling you die, whereas if you screw up your own computer, it only affects you.
That's a bogus assumption because the reality is that we have this thing called the "Internet". You know, a community of networks, where computers actually talk to each other. And, you know, cause havoc on each other's networks.
If you crash the car in your own paddock, that's okay -- it's your car, and your paddock. But if you drive irresponsibly on the road, especially a highway, which is a commons of road drivers, you suddenly have the ability to cause a lot more harm.
It's the same with the Internet. If you own a PC, and you connect it to the Internet, you have a responsibility as a citizen of the Internet (and the world, pretty much) to be conscientious to others. An infected PC is not a laughing matter — you’re actively harming someone or something whether you’re aware of it or not. If you're not prepared to take due care, you should be treated like the cops would treat you if you were an unlicensed drive — you shouldn't be allowed on the Internet.
It's a social problem, not a technical one.
Its 2010 and the fact you still have to explain to people how a digital connection works is getting old.
Yes, the data going through the USB may be digital, but as I have shown, the USB power, not data can cause interference.
For a vinyl ripper, the USB power has the ability to interfere with the audio while it's still analogue, before its conversion to digital prior to being sent over USB.
One would hope a vinyl ripper would use an external source of power and shield the USB well.
Uh, what? USB means that the ADC is outside the computer, which means that you get less possibility of EM noise from the electronics in the case interfering with the analogue signal.
In theory, maybe, but in practice I get noticeable EM noise from USB.
I have a USB-powered speaker (uses a normal 3.5 mm jack for audio) for my computer which also has an earphone port on the side, which is handy. It used to be part of a HP LCD monitor (L1740 if you must know), which had a USB port for plugging the speaker into for power. Why you would design the speakers to get their power off a monitor they were specially designed to be an accessory for with USB I do not know -- surely a normal DC plug would have done the job. But I digress.
Anyway, I no longer use that monitor, but kept the USB speakers. To power them, I now plug them directly into my desktop PC's USB port for the power. Now when I plug my earphones into the side of the speaker bar, there is a noticeable hum that is directly correlated with the CPU usage. Normally it's like "bzzt zzt zzt". But if I drag a window around or compile something, it goes like "BZZT THH ZZT THH ZZT TTH ZZT".quite loudly.
It does that with two separate motherboards with two separate PSUs. However, it does not do that if I plug the USB power into my Eee PC (laptop) instead.
So there you have it. USB does suffer from EM noise. If you have a solution, I'd like to know -- it drives me batty some days.
If you're going to spend money why don't you just buy a damn SBS and use AD?
The GP did use AD. Re-read this quote from the GP, my friend:
This meant it had to be AD.
If that doesn't convince you, read this quote, then read up up on the description for the likewise-open package.
The first thing I tried was likewise-open which I had a number of problems with.
If the GP wasn't using AD, then what the heck were they doing using a tool that provides "authentication services for Active Directory domains"?
But the truth is, sometimes you *have* to break the back button. Sometimes, you have to update portions of a page in order to keep it "fresh". Sadly, doing so breaks the back button.
A bit like how Gmail, Twitter, or many other sites don't use the document fragment identifier to do such a thing. Or a bit like how there's no such thing as history.pushState() to implement that (and because it doesn't exist, it doesn't work in Google Chrome, but if it did, it would work perfectly).
Yep, sometimes you have to break the back button.
The issue isn't that it's not possible, the issue is that HTML5 seems to tend towards HTML markup over XML markup.
I don't get why that is an issue. If you want to write clean markup, write clean markup. And today's browsers are perfectly capable of handling all manner of weird and wonderful markup.
The only situation I can think of where lax HTML5 markup would cause you a problem is if you're deploying to a custom mobile device or custom-written browser for a specific deployment. But in that case, you'd likely have control over both the input and output, in which case what I said above -- just write damn clean markup -- still applies.
If I saw problems with my browser struggling to render all the HTML5 content out there, I'd agree with you. But the reality is that browsers are mature, and can deal with the markup out there. And those that are writing markup are testing. It's a cycle that is working in practice, not just theory.
There is nothing stopping you from using well-formed XML in your HTML5, or serving your document as application/xhtml+xml (explicitly stated in the HTML5 spec). Serving HTML5 as proper XML is dubbed "XHTML 5". It uses the same doctype. All the new tags -- video, audio, section, header, etc. are supported, but obviously the lax markup features of HTML5 (like being able to omit most tags) no longer apply.
That's a very encouraging statistic. To the GP: Jeff Rosen (one of the guys behind Wolfire) wrote an enlightening blog post ("Linux users contribute twice as much as Windows users") on the subject too.
You should definitely read more of the Wolfire Blog. One of my favourite posts is about their reasoning for why you should support Mac OS X and Linux.
Mac OS X optionally includes a case-sensitive file-system, so as with OpenGL, once ported to OS X, it should be trivial to port that area to Linux.
That said, one of the Adobe CS versions crash when installing on a case-sensitive file system (find a link yourself -- I can't be bothered at this time of the morning), and Haiku won't build unless you build on a case-sensitive file system.
Except OpenVPN doesn't support IPv6 transport yet. You can run IPv6 inside the tunnel, but not outside.
Though there is a patch or two floating around that does add this feature (and will presumably be added to OpenVPN unstable soon if not already).
Where did you get that number? The IETF slides say something like 0.07%.
I don't have that Google statistic, but I do know that Wikimedia run similar tests on Wikipedia. Here are the test results, updated daily. As of today, 2010-03-28, an AAAA breaks the request 0.39% of the time for Wikipedia users.
Those tests are done in the background to users at random by a snippet of JavaScript on Wikipedia articles.
This Google presentation says Google would lose 0.1% of traffic if they added AAAA, though it's not presented particularly prominently, so take that with a grain of salt.
Either way, adding AAAA's will break your website for some people. In my opinion, though, the number is so small it's not worth worrying about, but each to his own, I guess. All this pain will be over soon anyway. Hopefully.
For the record, I do not hate you. I just hate the tremendous stupidity that you have shown.
Such as my ability to determine that in one of your aforementioned videos, they are actually still serving the Flash widget, despite being opted-in to the HTML5 beta. (I suspect that videos that they haven't transcoded to H.264 get served as Flash still, but that's just a guess.) Right-click on it and see.
Could have double-checked that before flinging the word "stupid" at me, but hey -- takes one to know one.
Some of the stuff on YouTube is most definitely NOT H.264 because Opera plays some of it while using YouTube's test HTML5 mode.
Because your personal testimony counts for...oh wait. Nothing. You've already been told not to guess once. Take this as your second warning.
I'll believe it when I see it. Until you provide some sort of proof (URL to non-H.264 and non-FLV YouTube video would be nice), I won't believe that.
Opera uses GStreamer as a backend, and 'will also be able to use "anything that Gstreamer can handle,"'. What quite likely actually happened was that the video in fact was H.264, and was using the H.264 decoder in your system's GStreamer.
They should be static, if they have any sense. See a blog post of mine on the subject.
Basically, with IPv4, if you have a dynamic address (say 5.6.7.8), and then your connection drops out, and now you are a different address (say 5.8.7.6), then the machines behind your NAT aren't affected, because they're still using a 192.168.0.x 192.168.0.1 gateway thingy.
But in IPv6, what subnet your ISP allocates you (e.g. 2001:db8:1:5678::/64) influences what machines in your LAN (i.e. what would be behind your IPv4 NAT) have as their IP address.
So if your subnet your ISP gives you is 2001:db8:1:5678::/64, then a machine on your network may have an IP address of 2001:db8:1:5678:aaaa:bbbb:cccc:1234. Then, if your connection drops out, and you get a new dynamic subnet, say, 2001:db8:1:9876::/64, then your machines on the LAN will not get the new address scheme immediately, and have the wrong IP address when sending to the Internet. A whole world of hurt.
Really short durations set on the Router Advertisements may help, but there is still a window of breakage, and thus a whole world of hurt that you just don't want to foist onto your customers.
Just think -- you can give out dynamic subnets and conserve address space, but you'll have all hell break loose with the support calls. (My ISP, Internode, is sane and gives out static /60 subnets.)