It claims to be modular but is effectively monolithic due to myriad cross dependencies (some of which are poorly documented) and a terrible thread management system.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source (witness the number of ISO based all in one installation solutions).
I'm in the process of reading up on FreeSwitch with a view to shifting to it.
That's the short term fix. Near term: initiate "Streisand effect" and hope that's enough to get Mediacom to change their ways. Long term: agitate for net neutrality laws!
No idea. When I looked at it (admittedly a long time ago) the only way to get Dropbox to sync a Truecrypt container after you changed the contents was to take the container out of the Dropbox folder and then move it back in. Even then, Dropbox would invariably upload the whole container rather than just the delta.
Apparently you can work around the syncing problem by getting Truecrypt to update the file modified time stamp when you change the container contents. However, it seems incremental backups are still flaky as any non-trivial changes to a container's content forces Dropbox to re-sync the whole file.
Incremental backups that work 100% of the time for a start. Also, duplicati is a windows port of duplicity (or you can use the free windows client from rsync.net).
Admittedly, there is no free option with rsync.net but you can't do much with 2GB...
Dump Dropbox and use something like rsync.net + duplicity. You lose the ability to remotely browse backed up files via a web interface but that's the price you pay if you don't want your backup provider to be able to browse your files.
I think the problem is that if you use a Truecrypt container and back that up to Dropbox, the Dropbox client is not always able to tell if any data has changed as changing the contents of the container does not always change the containers binary size on the disk. This means you can't do an incremental backup and instead have to force a full backup every time you alter what is inside the container, which isn't funny if your container is larger than a few hundred MBs.
As far as I can tell this doesn't work for Full Tilt.
I might be wrong (only checked it quickly) but if you hit netcraft and feed it www.fulltiltpoker.com you get 91.211.98.20. Banging that in still gets you redirected to the FBI boilerplate. This is probably because Fulltilt have setup their default Vhost (for all requests that don't match any other Vhost) to redirect everything to www.fulltiltpoker.com (which in turn now seems to point to 50.17.223.71, inside an Amazon EC2 netblock).
I particularly liked: "white-collar gambling on stock market derivatives" - the SEC has done a fucking piss poor job of regulating Wall Street over the last decade or so, laying the path for Madoff and friends to take some of the biggest gambles and pull off some of the largest frauds in corporate history. If that's government regulation at work, I'll take my chances with the self-regulation of the online poker world.
This domain seizure trend is getting out of hand. If the FBI, ICE and DOJ keep this up, it's going to finish with the UN administering the root servers.
I'm a paying, European customer of Full Tilt Poker... I hope this domain seizure doesn't interfere with FTPs non-US operations. What jurisdiction do they have to decide whether or not I can exercise my legal right to engage in an online card game for money?
Free spotify I can just about see the value of: you get a quick and free way to sample music you don't already own (assuming the artist is on the system). But the pro package is basically a system to rent music.... what's the point?? I mean how many worthwhile albums come out each year? Surely you're better off using the free version to check you like something and then, for the few albums you actually end up liking, go buy them off amazon. At least you then end up with an album that's yours to keep forever and do with as you please. Also, if remote streaming is really that fucking important to you, you've got their cloud player as well.
Surely that's better than pissing your money away *renting* music... ???
AFAIK, this problem has largely gone away now thanks to anycast and Google dumping resolvers all over the globe (admittedly Africa and SE Asia still may be under served).
From the Google DNS FAQ:
I've read claims that Google Public DNS can slow down multimedia applications such as iTunes and Apple TV. Are these true?
Many sites that provide downloadable or streaming multimedia host their content with DNS-based third-party content distribution networks (CDNs), such as Akamai. When a DNS resolver queries an authoritative nameserver for a CDN's IP address, the nameserver returns an address which is closest (in network distance) to the resolver, not the user. In some cases, for ISP-based resolvers as well as public resolvers such as Google Public DNS, the resolver may not be in close proximity to the users. In such cases, the browsing experience could be slowed down somewhat. Google Public DNS is no different from other DNS providers in this respect.
To help reduce the distance between DNS servers and users, Google Public DNS has deployed its servers all over the world. In particular, users in Europe should be directed to CDN content servers in Europe, users in Asia should be directed to CDN servers in Asia, and users in the eastern, central and western U.S. should be directed to CDN servers in those respective regions. We have also published this information (see Where are your servers currently located? for details) to help CDNs provide good DNS results for multimedia users.
In addition, Google Public DNS engineers have proposed a technical solution to the issue in an IETF draft, Client subnet information in DNS requests. This proposal defines an EDNS0 extension which allows resolvers to pass in part of the client's IP address as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver. We have prototyped an implementation of the proposal as an experiment for Google Public DNS and Google properties. We look forward to working with other public resolvers and other content networks to conduct further experiments.
>Does anyone here know if there is a way to tell it to keep all entries for at least some length of time (e.g. 1 day) before considering the info stale?
AFAIK, you can only override TTL values if you use a broken or modified resolver. Also, it is generally a bad idea to second guess the domain owners intention (e.g. upping the TTL will probably screw up their load balancing/maintenance assumptions).
Slashdot Mirror
It claims to be modular but is effectively monolithic due to myriad cross dependencies (some of which are poorly documented) and a terrible thread management system.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source (witness the number of ISO based all in one installation solutions).
I'm in the process of reading up on FreeSwitch with a view to shifting to it.
Have a read of: http://www.freeswitch.org/node/117
That's the short term fix. Near term: initiate "Streisand effect" and hope that's enough to get Mediacom to change their ways. Long term: agitate for net neutrality laws!
I use and wholeheartedly recommend www.dyndns.com
I've never had to deal with a DMCA takedown request but I'm pretty confident that the guys at Dyn would talk to me first before doing anything rash.
No idea. When I looked at it (admittedly a long time ago) the only way to get Dropbox to sync a Truecrypt container after you changed the contents was to take the container out of the Dropbox folder and then move it back in. Even then, Dropbox would invariably upload the whole container rather than just the delta.
Apparently you can work around the syncing problem by getting Truecrypt to update the file modified time stamp when you change the container contents. However, it seems incremental backups are still flaky as any non-trivial changes to a container's content forces Dropbox to re-sync the whole file.
YMMV (I am not a current dropbox user)
Incremental backups that work 100% of the time for a start. Also, duplicati is a windows port of duplicity (or you can use the free windows client from rsync.net).
Admittedly, there is no free option with rsync.net but you can't do much with 2GB...
Looks interesting. Similar to my setup which is rsync.net + duplicity
Having said that, it apparently can still be a bit painful: http://news.ycombinator.com/item?id=1392765
Looks like things have moved on since I last tried Dropbox with Truecrypt:
http://forums.dropbox.com/topic.php?id=14332
It does appear to be possible providing you tell Truecrypt not to preserve file modification timestamps
Dump Dropbox and use something like rsync.net + duplicity. You lose the ability to remotely browse backed up files via a web interface but that's the price you pay if you don't want your backup provider to be able to browse your files.
I think the problem is that if you use a Truecrypt container and back that up to Dropbox, the Dropbox client is not always able to tell if any data has changed as changing the contents of the container does not always change the containers binary size on the disk. This means you can't do an incremental backup and instead have to force a full backup every time you alter what is inside the container, which isn't funny if your container is larger than a few hundred MBs.
If you have a Nexus phone, WhisperCore is probably worth investigating:
http://www.whispersys.com/whispercore.html
lol good point. Looks like I need a KISS refresher course :D
Or Slashdot should just auto re-write all urls from shortening services (e.g. http://tinyurl.com/6gabfug becomes http://slashurl.com/tinyurl/6gabfug) and then give you an intermediary page where the url is expanded to show the real source.
Those would be the friends of Madoff. Very nicely put though :)
As far as I can tell this doesn't work for Full Tilt.
I might be wrong (only checked it quickly) but if you hit netcraft and feed it www.fulltiltpoker.com you get 91.211.98.20. Banging that in still gets you redirected to the FBI boilerplate. This is probably because Fulltilt have setup their default Vhost (for all requests that don't match any other Vhost) to redirect everything to www.fulltiltpoker.com (which in turn now seems to point to 50.17.223.71, inside an Amazon EC2 netblock).
Couldn't agree more. I didn't mean to imply that handing root control to the UN was a good thing :)
Bad form to reply to my own post I know but FYI www.fulltiltpoker.org is still up as are the .fr and .it sites (as one would hope)
How so? A lot of his points seem valid to me.
I particularly liked: "white-collar gambling on stock market derivatives" - the SEC has done a fucking piss poor job of regulating Wall Street over the last decade or so, laying the path for Madoff and friends to take some of the biggest gambles and pull off some of the largest frauds in corporate history. If that's government regulation at work, I'll take my chances with the self-regulation of the online poker world.
This domain seizure trend is getting out of hand. If the FBI, ICE and DOJ keep this up, it's going to finish with the UN administering the root servers.
I'm a paying, European customer of Full Tilt Poker... I hope this domain seizure doesn't interfere with FTPs non-US operations. What jurisdiction do they have to decide whether or not I can exercise my legal right to engage in an online card game for money?
I noticed that the forums are still up: http://pokerforums.fulltiltpoker.com/
Free spotify I can just about see the value of: you get a quick and free way to sample music you don't already own (assuming the artist is on the system). But the pro package is basically a system to rent music.... what's the point?? I mean how many worthwhile albums come out each year? Surely you're better off using the free version to check you like something and then, for the few albums you actually end up liking, go buy them off amazon. At least you then end up with an album that's yours to keep forever and do with as you please. Also, if remote streaming is really that fucking important to you, you've got their cloud player as well.
Surely that's better than pissing your money away *renting* music... ???
As an FYI, PHP also offers this.
AFAIK, this problem has largely gone away now thanks to anycast and Google dumping resolvers all over the globe (admittedly Africa and SE Asia still may be under served).
From the Google DNS FAQ:
I've read claims that Google Public DNS can slow down multimedia applications such as iTunes and Apple TV. Are these true?
Many sites that provide downloadable or streaming multimedia host their content with DNS-based third-party content distribution networks (CDNs), such as Akamai. When a DNS resolver queries an authoritative nameserver for a CDN's IP address, the nameserver returns an address which is closest (in network distance) to the resolver, not the user. In some cases, for ISP-based resolvers as well as public resolvers such as Google Public DNS, the resolver may not be in close proximity to the users. In such cases, the browsing experience could be slowed down somewhat. Google Public DNS is no different from other DNS providers in this respect.
To help reduce the distance between DNS servers and users, Google Public DNS has deployed its servers all over the world. In particular, users in Europe should be directed to CDN content servers in Europe, users in Asia should be directed to CDN servers in Asia, and users in the eastern, central and western U.S. should be directed to CDN servers in those respective regions. We have also published this information (see Where are your servers currently located? for details) to help CDNs provide good DNS results for multimedia users.
In addition, Google Public DNS engineers have proposed a technical solution to the issue in an IETF draft, Client subnet information in DNS requests. This proposal defines an EDNS0 extension which allows resolvers to pass in part of the client's IP address as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver. We have prototyped an implementation of the proposal as an experiment for Google Public DNS and Google properties. We look forward to working with other public resolvers and other content networks to conduct further experiments.
New Zealand is a bit of an edge case but you may at least get some mileage out of running http://code.google.com/p/namebench/
>Does anyone here know if there is a way to tell it to keep all entries for at least some length of time (e.g. 1 day) before considering the info stale?
AFAIK, you can only override TTL values if you use a broken or modified resolver. Also, it is generally a bad idea to second guess the domain owners intention (e.g. upping the TTL will probably screw up their load balancing/maintenance assumptions).