A proper flow-based layout could work for both a small screen and a large one. Think more scrolling for the small screen, while text and other elements flow into the available space for the large screen. Just like good HTML + CSS; content can look great on a wide variety of screen sizes.
To answer your question, there are a few GUI Builders like this one, but they aren't great [yet].
Carrier/handset device fragmentation does mean the developer needs to account for different sizes/resolutions of screens. Using flow-based layouts, this allows the developer to create one UI and apply it to many devices (phones, tablets, laptops, TVs, etc.)
Do you have to create two exact UIs, one for iphone/ipod and the other for the ipad using the XCode Interface Builder (assuming you don't just "scale" the smaller UI to the larger screen)? And what if you were able to run your app on AppleTV someday.. would you then need to create a third exact layout?
Unfortunately, many CAs charge an extra fee for each Subject Alternative Name added to the certificate. It is also a pain for server admins to re-install a re-issued cert when SANs are added/removed from the cert.
That said, SAN is still better than one IP to hostname.
Why would you use the website on your Android phone and not the Market app?
The only purpose for the [ugly] market.android.com website is to bypass the phone for app research and installs.
Though if you're browsing a website not on the phone, why not use AppBrain instead? At least it supports rudimentary sorts and filters.
I'd really love to browse a market by filtering-away apps that require permissions X (where X includes reading browser history, contacts, etc.). Then I could sort by number of downloads as well as ratings. (Not just average rating but number of ratings.)
The android market is a joke, both on the device and off.
I do like how the 'read more comments' link goes directly to the #comments anchor. Just remember to copy the URL of the summary title when passing the story link on to friends! Otherwise they might not scroll up to read the summary.
Agreed. Seeing the number of comments a story has on the front page helps me decide to browse or enter a discussion.
Also, the javascript thread that keeps loading new stories on the front page should update the previous story's comment counts. (It's probably too much to ask to have similar javascript update the user's slashbox showing comment replies. This would prevent manual refreshing of the front page entirely.)
Ah, thanks for the reply. Now I understand how you got to the ECC part -- you want to periodically (or perhaps instantaneously via ZFS / check-on-write) check for file corruption.
So by copying the complete directory tree, you *may* have a lower chance of losing a file to corruption. But I would think the second (or third) backup copy to a removable drive(s) would cover the chance of file corruption.
Unless you are comparing multiple copies all the time, you will never know about corruption until you restore a backed-up file. By then, you might have copied the corrupted file around.
I see how you want to verify the integrity of a backup -- but even with a check-on-write scenario, a faulty read (bad disk block, DMA error, bad cable, etc) would be difficult to detect. You could copy your tree, do a successful diff, and the copy would have the corrupted file.
However, a check-on-write would catch faulty writes. Your tree copy diff would fail, and you would immediately know there was a problem. Good thing rsync does this for us!
From the rsync man page:
Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred...
In summary, if you are backing up your backups to an external drive with rsync, I don't see the need to ever create a new tree on the backup server / partition.
Any time you discover corruption from a particular media, I would quickly replace that device (and your multiple copy scenario should save you).
Um, the whole point of Public Key Cryptography is that the public key and the algorithm can be known by the attacker.
If this was implemented over plain HTTP, the problem would still exist. The attacker (government in this case) would overwrite Facebook's public key in javascript with their public key, decrypt the password, then pass it on to Facebook just like any old Man In The Middle attack.
I'm curious why you create a new directory tree every three months, instead of just continuing to link to the old one? (I'm assuming you're using hardlinks and running rsync with --link-dest). I just link to my old tree and periodically purge old "copies". For instance, I might keep the last 7 days, but then only 2 weeks before that, and maybe quarterly before that.
I thought that was the beauty of hard links... that you could remove the oldest "full" file, but as long as you have at least one link to it, the data will remain. Am I missing something by not recreating my tree?
Those figures do not account for all of the costs Netflix incurs for providing a user some content.
The Hollywood Reporter article states that licensing fees are not included in the distribution price of $1/disc, $0.05/stream:
That means licensing fees can keep climbing as Netflix moves more of its business to streaming and away from DVDs. Sending a disc round-trip can cost as much as $1, and Netflix mails about 2 million DVDs a day, whereas streaming a movie costs the company about a nickel.
Also, the figures quote "as much as $1" -- I bet that is not the avg/mean price per roundrip mailing.
I question the source of the streaming figure: Is it five cents just for the bandwidth? Or does it count the complete infrastructure of data centers housing encoding and streaming servers, peering agreements, and technical staff?
Netflix would stream everything if they could. It is a licensing issue. See the original hollywood reporter article, not the stub linked from the summary:
There seems to be a few 3rd party services that rely on Wikipedia's data. I'm sure there are many commercial services too (I've seen many pay-per-click sites simply barf wikipedia content surrounded by ads).
Instead of ads, could Wikimedia charge for a it's APIs to allow access to Wikipedia's data? Like most services, you get your developer key for a limited number of queries, but as the request volume goes up, you pay more. Bulk-exporting several pages? Pay a small fee. If the fees are low and reasonable, maybe businesses would pay for them and not result to screen-scraping?
The data itself is still covered under CC/FDL licenses; the charge is just for friendly access to it.
Right. You'd want to many the same query to many peers, and compare the results. Due to the expense of this, you'd want to heavily cache responses and always be re-querying hostnames in the background if you want to honor the original TTL.
Any idea if something like DNS Curve could be useful here? It relies on the domain/zone owner to have a private key.. I don't see how you could ensure the integrity of a DNS response, unless the P2P network simply routed your queries to the domain/zone owner's nameservers.
DNSCurve looks pretty sweet; especially how it encrypts packets, instead of just signing them (like DNSSEC). Hiding the query and response seems very useful to avoid prying eyes.
Slashdot Mirror
You mean this site? https://panopticlick.eff.org/
Maybe you should try noscript to block unwanted 3rd party scripts.
A proper flow-based layout could work for both a small screen and a large one. Think more scrolling for the small screen, while text and other elements flow into the available space for the large screen. Just like good HTML + CSS; content can look great on a wide variety of screen sizes.
To answer your question, there are a few GUI Builders like this one, but they aren't great [yet].
Carrier/handset device fragmentation does mean the developer needs to account for different sizes/resolutions of screens. Using flow-based layouts, this allows the developer to create one UI and apply it to many devices (phones, tablets, laptops, TVs, etc.)
Do you have to create two exact UIs, one for iphone/ipod and the other for the ipad using the XCode Interface Builder (assuming you don't just "scale" the smaller UI to the larger screen)? And what if you were able to run your app on AppleTV someday.. would you then need to create a third exact layout?
Pretty sure they're only counting updates (each computer, virtual machine, usb run FF instance, etc.) not humans.
No, use TabKit and put tabs on the side (grouped, colored, and nested) where they belong.
Unfortunately, it doesn't work with FF4, but the next best thing seems to be either: Tree Style Tab or: Vertical Tabs.
Click the [?] button at the top of the link you just posted.
TL;DR : Yes, upgrades / auto-updates count as downloads.
Unfortunately, many CAs charge an extra fee for each Subject Alternative Name added to the certificate. It is also a pain for server admins to re-install a re-issued cert when SANs are added/removed from the cert.
That said, SAN is still better than one IP to hostname.
It's obvious PayPal doesn't give a shit about PR.
What about versions before 9.7.1? Looks like this vulnerability affects only Bind servers within the specific range: 9.7.1-9.7.2-P3
Why would you use the website on your Android phone and not the Market app?
The only purpose for the [ugly] market.android.com website is to bypass the phone for app research and installs.
Though if you're browsing a website not on the phone, why not use AppBrain instead? At least it supports rudimentary sorts and filters.
I'd really love to browse a market by filtering-away apps that require permissions X (where X includes reading browser history, contacts, etc.). Then I could sort by number of downloads as well as ratings. (Not just average rating but number of ratings.)
The android market is a joke, both on the device and off.
I do like how the 'read more comments' link goes directly to the #comments anchor. Just remember to copy the URL of the summary title when passing the story link on to friends! Otherwise they might not scroll up to read the summary.
Agreed. Seeing the number of comments a story has on the front page helps me decide to browse or enter a discussion.
Also, the javascript thread that keeps loading new stories on the front page should update the previous story's comment counts. (It's probably too much to ask to have similar javascript update the user's slashbox showing comment replies. This would prevent manual refreshing of the front page entirely.)
I don't feel much like Picasso at the moment...
Zooming in either Firefox or Opera does not affect the vertical space.
If only everything scaled as it should, like when using 'em' instead of 'px'.
Ah, thanks for the reply. Now I understand how you got to the ECC part -- you want to periodically (or perhaps instantaneously via ZFS / check-on-write) check for file corruption.
So by copying the complete directory tree, you *may* have a lower chance of losing a file to corruption. But I would think the second (or third) backup copy to a removable drive(s) would cover the chance of file corruption.
Unless you are comparing multiple copies all the time, you will never know about corruption until you restore a backed-up file. By then, you might have copied the corrupted file around.
I see how you want to verify the integrity of a backup -- but even with a check-on-write scenario, a faulty read (bad disk block, DMA error, bad cable, etc) would be difficult to detect. You could copy your tree, do a successful diff, and the copy would have the corrupted file.
However, a check-on-write would catch faulty writes. Your tree copy diff would fail, and you would immediately know there was a problem. Good thing rsync does this for us!
From the rsync man page:
Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred...
In summary, if you are backing up your backups to an external drive with rsync, I don't see the need to ever create a new tree on the backup server / partition.
Any time you discover corruption from a particular media, I would quickly replace that device (and your multiple copy scenario should save you).
Um, the whole point of Public Key Cryptography is that the public key and the algorithm can be known by the attacker.
If this was implemented over plain HTTP, the problem would still exist. The attacker (government in this case) would overwrite Facebook's public key in javascript with their public key, decrypt the password, then pass it on to Facebook just like any old Man In The Middle attack.
I was thinking the same thing. A cool, dry, relatively constant temperature basement would be better.
Instead of FUSE + ECC, you could try ZFS Checksums.
I'm curious why you create a new directory tree every three months, instead of just continuing to link to the old one? (I'm assuming you're using hardlinks and running rsync with --link-dest). I just link to my old tree and periodically purge old "copies". For instance, I might keep the last 7 days, but then only 2 weeks before that, and maybe quarterly before that.
I thought that was the beauty of hard links... that you could remove the oldest "full" file, but as long as you have at least one link to it, the data will remain. Am I missing something by not recreating my tree?
Those figures do not account for all of the costs Netflix incurs for providing a user some content.
The Hollywood Reporter article states that licensing fees are not included in the distribution price of $1/disc, $0.05/stream:
Also, the figures quote "as much as $1" -- I bet that is not the avg/mean price per roundrip mailing.
I question the source of the streaming figure: Is it five cents just for the bandwidth? Or does it count the complete infrastructure of data centers housing encoding and streaming servers, peering agreements, and technical staff?
Netflix would stream everything if they could. It is a licensing issue. See the original hollywood reporter article, not the stub linked from the summary:
http://www.hollywoodreporter.com/news/hollywood-execs-privately-netflix-71957
There seems to be a few 3rd party services that rely on Wikipedia's data. I'm sure there are many commercial services too (I've seen many pay-per-click sites simply barf wikipedia content surrounded by ads).
Instead of ads, could Wikimedia charge for a it's APIs to allow access to Wikipedia's data? Like most services, you get your developer key for a limited number of queries, but as the request volume goes up, you pay more. Bulk-exporting several pages? Pay a small fee. If the fees are low and reasonable, maybe businesses would pay for them and not result to screen-scraping?
The data itself is still covered under CC/FDL licenses; the charge is just for friendly access to it.
Just a thought.
RoundCube does not display images by default. It is a modern web mail application used by hundreds of ISPs and thousands of end users.
Right. You'd want to many the same query to many peers, and compare the results. Due to the expense of this, you'd want to heavily cache responses and always be re-querying hostnames in the background if you want to honor the original TTL.
Any idea if something like DNS Curve could be useful here? It relies on the domain/zone owner to have a private key.. I don't see how you could ensure the integrity of a DNS response, unless the P2P network simply routed your queries to the domain/zone owner's nameservers.
DNSCurve looks pretty sweet; especially how it encrypts packets, instead of just signing them (like DNSSEC). Hiding the query and response seems very useful to avoid prying eyes.