Hmmm, I guess we cross our fingers that they'll release a formal specification for all the bits that count so others can reimplement it if they choose?
I have no opinion language-wise for this really, but running on a basic LAMP stack, at least with the A being Apache is a must. I could swallow the megabytes of Ruby gems if needs be, but only if sufficient versions are available in Debian stable. As a sysadmin I do not need any extra headache of trying to keep lots of tiny little packages up to date myself (disclaimer, never touched/adminned Ruby so far... for all I know it has some nice way of doing this...).
*checks the git repository quickly* Ah yes, Debian packaging for Diaspora itself would be nice too.
In typical/. inhabitant behaviour I'd not even read all the summary before commenting...
So, they asked about 'ultraviolent or sexually violent' ? Way to load the question. Of course a majority are likely to say 'yes' just because of the words 'sexually violent' !
Anyone thinking such games have a truly adverse effect on more than a very small minority of kids (who likely already had problems) should go watch this "Penn & Teller's Bullshit!" episode: http://www.imdb.com/title/tt1471881/
Sadly there's no synopsis or the like on that URL but from memory one thing they did was have a 10 year old who loves playing something like Modern Warfare on his console go and actually shoot a rifle (AR-1 I think). The kid doesn't enjoy the experience at all. Yeah, the games sooooooo made him likely to grab a gun and go on a real killing spree....
Maybe after a thousand or so years, UTC time will be offset enough from the solar day that it will be irritating, but if people still care about the relationship between noon and midday then they can add a leap-minute or two to compensate.
The usual objection I see to this is that you've then introduce a very special event that no-one will have programmed for at all. It's far better to have more regular such events so programmers know they have to handle them...
BetterPrivacy - "super-cookie safeguard" Permanently opt-out cookies to stop behavioral advertising by 100+ different advertising networks, including Google, Yahoo, Microsoft, all members of the Network Advertising Initiative, and many others.
Hmmm, the BetterPrivacy FF extension I know (and use when in FF) is for controlling storage of Flash Cookies. Perhaps you had some other extension in mind ?
All I'd been reading so far was no transfers for X days after a new registration or expiry. But I'll check and make sure, thanks.
I'll also mention that name.com also support both DNSSEC and IPv6 Glue now. They've only done so for a week and haven't yet updated their FAQs. I'd even read the TheRegister article about this just last week!
I should have mentioned I started with the pir.org list. Most of the registrars listed there have awful websites that fail to mention anything about either service.
Also many of them seem to be 'mere' resellers using the same software package for the website. They even have identical FAQ and Support pages!
Thanks for confirming godaddy have full support for both features. Unless I hear something bad about them that puts me off, or something awesome about another registrar, I think I'll be transferring to them when there's about a month left to expiry.
That depends on if the registry for your TLD supports DNSSEC. There has to be a chain of trust all the way down from the root nameservers to yours..ORG does support DNSSEC now.
I'm currently trying to find a registrar that definitely has DNSSEC support in their web management interface for.ORG domains. GoDaddy looks like a good bet on this point, but I'd also like IPv6 glue support (i.e. so I can create a new A record with an IPv6 address and then also set that as an NS record and have that data in the.ORG nameservers as glue for my domain).
Oh and also it's insane that the whole RealID thing revolves around your battle.net account email. Firstly you might not want to give that out to anyone else, secondly it's the ACCOUNT CONNECTED EMAIL, so wonderful to combine with a bit of social engineering to hack an account.
Blizzard REALLY need to rethink this.
Firstly allow specifying a global 'screen name' to be shown instead of real name.
Secondly make the primary (only?) method to add a RealID friend being right-click of the character in-game. If you don't have any game in common then why would you even want to add them as a RealID friend? Failing that have some numeric ID you can use. I used to use that method for Steam adding without the problems it seemed prone to doing it any other way (go to your own profile, copy the URL with numeric ID that can't be anyone but you, paste to friend somehow... now you can have a 'nice' URL form too).
And even with both of those two I'd like an opt out from the 'friends of friends' listing.
Requiring revealing your email address (not everyone will have thought to, or be able to, use an address for battle.net that they don't use for anything else) and real name for a game/social thing is insane.
I've already sent them an angry message via battle.net support pointing out how insane it is to 1) Require real names show when you add a RealID friend, 2) Allow friends of friends to also see your real name, 3) Show the real names on forums.
You can still play their games and not given the info away, but it means never posting on the forums or making use of RealID friending (you can still do per-game single-character friending).
If it's to a well-defined area I see no problem, especially if you can set a quota on it to head off a DoS by full-disk. So long as you know not to implicitly trust anything in that location, given its sole purpose is for this storage, that is.
However I am puzzled by:
On the downside, these databases are buried deeply in the system folder, so making backups may not be the simplest step.
Why can't it be in a per-user folder inside their profile ? I thought we were finally getting away from the Windows pain of apps keeping settings, logs, saved files, screenshots etc. inside the application installation itself. Is this just one or two browsers having a stupid implementation at this stage ?
A quick search through visible comments (sorry I couldn't be arsed to click enough times to load them) all showed no mention of 'Loading', so I assume no yet mentioned the awesome LoadingReadyRun's rebuttal:
Does interference destroy the entanglement which might be discvovered by traditional communication later because the deterministic relationship of the pair no longer held?
if you can distinguish between these possibilities, cant you use this information for faster than light transmission?
again the fundamental reason this (FTL comms) can't work is because the actual state you get is random. The useful part is it will be the same for both kept and transmitted photon/qubit. You can't choose what you transmit. You can't even use "measured yet or not" because the initial measurement, at either end, causes waveform collapse, so the answer to "has this been measured yet?" is always "yes, you just did".
Except each entangled pair is one-use only. You measure the state of one half of it, which instantly sets the same state in the other pair, and then they're no longer entangled (due to you having observed).
Also you can't predict or set the state of half an entangled pair, only measure it, causing the waveform to randomly collapse. The only thing this gets you is secure transmission of a random sequence (many entangled pairs) of states, which you can then use as a one-time pad/key for conventional encryption over a conventional link. If anyone tried to eavesdrop in the middle they interfere in a measurable manner.
This might make things a little clearer for the Intel case. Certainly it gives more detail about how it works (for one thing it's not just a "base speed or Turbo speed" thing, there are multiple boost steps depending on the exact situation).
Neither of those stop your IP from being listed on the tracker(s).
Encryption only stops Man-In-The-Middle snooping, but practically speaking that would have to be by either your ISP or the ISP for the other end of the connection, which seems unlikely without court orders. A 'bad' IP can still connect to you (or place itself on the tracker so there's a chance you'll connect to it). What this *might* buy you, together with using ports other than the standard BitTorrent ones is obfuscation of what your traffic is for the purposes of avoiding ISP bandwidth shaping.
PeerGuardian, assuming the lists have all the relevant IPs, will stop people from being able to connect with you. But you're still in the tracker. However, I see a prior comment has said 'most' trackers include some random 'junk' IPs so as to confuse things. Obviously this makes the protocol slightly less efficient, but I doubt it makes any practical difference.
To sum up: Encryption is mostly to try and avoid ISP bandwidth shaping. PeerGuardian, together with trackers listing 'junk' IPs offers some protection against being fingered in this way.
Does anyone know if it's possible/practical to read from a tracker's list to get a list of IPs to connect to, but not place your IP in the list? You'd be limiting yourself to outbound connections only. Without checking I don't know if simply retrieving a tracker's data for a torrent places your IP in its list for subsequent retrieval. Either way this is an obnoxious thing to do (yes, for any torrent I join, whatever its content, I stay at least until ratio 1.00, and typically to 2.00 and beyond as local resources allow).
...the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?]
But that's counting each and every file system, each and every architecture and most significantly each and every hardware driver. The amount of code you need to understand to be able to, for instance, write a new network driver, is substantially less than the totality of the Linux kernel source.
Out of ~25k *.[ch] files I count ~9k in drivers alone, plus ~1k in sound. There's ~1.5k in fs and kernel has ~200. Although arch has ~10k only ~700 of those are for x86. Yes, this is a very rough and ready, not to mention incomplete, set of figures, but you get the idea.
Slashdot Mirror
If Facebook works as 'free' then I can see some enterprising people setting up Diaspora hosting on the same footing (i.e. ad and affiliate supported).
Hmmm, I guess we cross our fingers that they'll release a formal specification for all the bits that count so others can reimplement it if they choose?
I have no opinion language-wise for this really, but running on a basic LAMP stack, at least with the A being Apache is a must . I could swallow the megabytes of Ruby gems if needs be, but only if sufficient versions are available in Debian stable. As a sysadmin I do not need any extra headache of trying to keep lots of tiny little packages up to date myself (disclaimer, never touched/adminned Ruby so far... for all I know it has some nice way of doing this...).
*checks the git repository quickly* Ah yes, Debian packaging for Diaspora itself would be nice too.
In typical /. inhabitant behaviour I'd not even read all the summary before commenting...
So, they asked about 'ultraviolent or sexually violent' ? Way to load the question. Of course a majority are likely to say 'yes' just because of the words 'sexually violent' !
So, yeah, even more Bullshit! than I thought.
Anyone thinking such games have a truly adverse effect on more than a very small minority of kids (who likely already had problems) should go watch this "Penn & Teller's Bullshit!" episode: http://www.imdb.com/title/tt1471881/
Sadly there's no synopsis or the like on that URL but from memory one thing they did was have a 10 year old who loves playing something like Modern Warfare on his console go and actually shoot a rifle (AR-1 I think). The kid doesn't enjoy the experience at all. Yeah, the games sooooooo made him likely to grab a gun and go on a real killing spree....
This is really just bad wording in his opening paragraph.
Really it's that:
The Universe Today article is worded a little better: http://www.universetoday.com/73536/nasa-considering-rail-gun-launch-system-to-the-stars/
Science fiction ? Star Wars is more like future fantasy, and Star Trek is more future fiction.
A long time ago....
The usual objection I see to this is that you've then introduce a very special event that no-one will have programmed for at all. It's far better to have more regular such events so programmers know they have to handle them...
... not that it's worked so far....
And let us not forget that many of the machines affected by SC2 showing their GPU cooling was crap were laptops....
BetterPrivacy - "super-cookie safeguard" Permanently opt-out cookies to stop behavioral advertising by 100+ different advertising networks, including Google, Yahoo, Microsoft, all members of the Network Advertising Initiative, and many others.
Hmmm, the BetterPrivacy FF extension I know (and use when in FF) is for controlling storage of Flash Cookies. Perhaps you had some other extension in mind ?
I just checked and it'll still give out a full agent string (NB: I use latest dev channel). So IP + User Agent tracking will still work.
All I'd been reading so far was no transfers for X days after a new registration or expiry. But I'll check and make sure, thanks.
I'll also mention that name.com also support both DNSSEC and IPv6 Glue now. They've only done so for a week and haven't yet updated their FAQs. I'd even read the TheRegister article about this just last week!
I should have mentioned I started with the pir.org list. Most of the registrars listed there have awful websites that fail to mention anything about either service.
Also many of them seem to be 'mere' resellers using the same software package for the website. They even have identical FAQ and Support pages!
Thanks for confirming godaddy have full support for both features. Unless I hear something bad about them that puts me off, or something awesome about another registrar, I think I'll be transferring to them when there's about a month left to expiry.
That depends on if the registry for your TLD supports DNSSEC. There has to be a chain of trust all the way down from the root nameservers to yours. .ORG does support DNSSEC now.
I'm currently trying to find a registrar that definitely has DNSSEC support in their web management interface for .ORG domains. GoDaddy looks like a good bet on this point, but I'd also like IPv6 glue support (i.e. so I can create a new A record with an IPv6 address and then also set that as an NS record and have that data in the .ORG nameservers as glue for my domain).
Oh and also it's insane that the whole RealID thing revolves around your battle.net account email. Firstly you might not want to give that out to anyone else, secondly it's the ACCOUNT CONNECTED EMAIL, so wonderful to combine with a bit of social engineering to hack an account.
Blizzard REALLY need to rethink this.
Firstly allow specifying a global 'screen name' to be shown instead of real name.
Secondly make the primary (only?) method to add a RealID friend being right-click of the character in-game. If you don't have any game in common then why would you even want to add them as a RealID friend? Failing that have some numeric ID you can use. I used to use that method for Steam adding without the problems it seemed prone to doing it any other way (go to your own profile, copy the URL with numeric ID that can't be anyone but you, paste to friend somehow... now you can have a 'nice' URL form too).
And even with both of those two I'd like an opt out from the 'friends of friends' listing.
Requiring revealing your email address (not everyone will have thought to, or be able to, use an address for battle.net that they don't use for anything else) and real name for a game/social thing is insane.
From http://eu.battle.net/realid/faq.html
I've already sent them an angry message via battle.net support pointing out how insane it is to 1) Require real names show when you add a RealID friend, 2) Allow friends of friends to also see your real name, 3) Show the real names on forums.
You can still play their games and not given the info away, but it means never posting on the forums or making use of RealID friending (you can still do per-game single-character friending).
He's obviously planning to cheat on some exams.
If it's to a well-defined area I see no problem, especially if you can set a quota on it to head off a DoS by full-disk. So long as you know not to implicitly trust anything in that location, given its sole purpose is for this storage, that is.
However I am puzzled by:
Why can't it be in a per-user folder inside their profile ? I thought we were finally getting away from the Windows pain of apps keeping settings, logs, saved files, screenshots etc. inside the application installation itself. Is this just one or two browsers having a stupid implementation at this stage ?
A quick search through visible comments (sorry I couldn't be arsed to click enough times to load them) all showed no mention of 'Loading', so I assume no yet mentioned the awesome LoadingReadyRun's rebuttal:
http://www.escapistmagazine.com/videos/view/loadingreadyrun/1629-Scientists-Rebuttal-to-ICP
I was more thinking of a riff on the sketch along the lines of "He's not dead, he's just drunk".
Briefly "yes".
If you want the nitty-gritty, then high thee to : http://en.wikipedia.org/wiki/Quantum_cryptography
As for:
again the fundamental reason this (FTL comms) can't work is because the actual state you get is random. The useful part is it will be the same for both kept and transmitted photon/qubit. You can't choose what you transmit. You can't even use "measured yet or not" because the initial measurement, at either end, causes waveform collapse, so the answer to "has this been measured yet?" is always "yes, you just did".
Except each entangled pair is one-use only. You measure the state of one half of it, which instantly sets the same state in the other pair, and then they're no longer entangled (due to you having observed).
Also you can't predict or set the state of half an entangled pair, only measure it, causing the waveform to randomly collapse. The only thing this gets you is secure transmission of a random sequence (many entangled pairs) of states, which you can then use as a one-time pad/key for conventional encryption over a conventional link. If anyone tried to eavesdrop in the middle they interfere in a measurable manner.
This might make things a little clearer for the Intel case. Certainly it gives more detail about how it works (for one thing it's not just a "base speed or Turbo speed" thing, there are multiple boost steps depending on the exact situation).
Neither of those stop your IP from being listed on the tracker(s).
Encryption only stops Man-In-The-Middle snooping, but practically speaking that would have to be by either your ISP or the ISP for the other end of the connection, which seems unlikely without court orders. A 'bad' IP can still connect to you (or place itself on the tracker so there's a chance you'll connect to it). What this *might* buy you, together with using ports other than the standard BitTorrent ones is obfuscation of what your traffic is for the purposes of avoiding ISP bandwidth shaping.
PeerGuardian, assuming the lists have all the relevant IPs, will stop people from being able to connect with you. But you're still in the tracker. However, I see a prior comment has said 'most' trackers include some random 'junk' IPs so as to confuse things. Obviously this makes the protocol slightly less efficient, but I doubt it makes any practical difference.
To sum up: Encryption is mostly to try and avoid ISP bandwidth shaping. PeerGuardian, together with trackers listing 'junk' IPs offers some protection against being fingered in this way.
Does anyone know if it's possible/practical to read from a tracker's list to get a list of IPs to connect to, but not place your IP in the list? You'd be limiting yourself to outbound connections only. Without checking I don't know if simply retrieving a tracker's data for a torrent places your IP in its list for subsequent retrieval. Either way this is an obnoxious thing to do (yes, for any torrent I join, whatever its content, I stay at least until ratio 1.00, and typically to 2.00 and beyond as local resources allow).
...the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?]
But that's counting each and every file system, each and every architecture and most significantly each and every hardware driver. The amount of code you need to understand to be able to, for instance, write a new network driver, is substantially less than the totality of the Linux kernel source.
Out of ~25k *.[ch] files I count ~9k in drivers alone, plus ~1k in sound. There's ~1.5k in fs and kernel has ~200. Although arch has ~10k only ~700 of those are for x86. Yes, this is a very rough and ready, not to mention incomplete, set of figures, but you get the idea.
And a bug in SELinux was precisely one way in which it was possible to map page zero.