I spent this evening trying to get it to encrypt a clean install of Windows XP SP2.
First, there is a problem with creating a recovery CD. If you try to burn the image TC gives you with Alcohol 120% or PowerISO, it will not work. Alcohol burns it, but validation fails. PowerISO doesn't even want to burn that image. You have to use InfraRecorder that their website links to. I have no idea what they are doing with that image, but there is no reason why I should have to go out and get some other piece of software to do the same thing as Alcohol or PowerISO.
That's not the major problem though. So far, I could not encrypt my drive. The process goes to about 21% then dies with a "Data error (cyclic redundancy check)." Very descriptive, as you can tell. I just finished running checkdisk to see if this could be caused by bad disk sectors - nope. The hard drive is perfectly fine. I'm not the only one having the same problem. There are a number of people on wilderssecurity forums that have the same issue.
I have that 21% of the disk encrypted, and pre-boot authentication works fine... now if it could only work for the entire disk. The other thing I found out is that apparently encrypting your system drive will disable hibernation. Not a great thing for my laptop (Fujitsu P7010, in case you were interested). I could live without hibernation for a while, assuming that it will come eventually in a later release. The encryption problem is another story.
I wrote a php xmpp client and server a few months back. In my humble opinion it is a poorly-designed protocol.
For one thing, it is an example of how NOT to use namespaces in XML. Many elements are needlessly separated out, causing a lot of confusion and problems for simple xml parsers. Namespaces do not solve the problem of name conflicts, as the xmpp site still has a registry of namespace names. Separating out extensions - maybe, but the whole point of namespaces is to avoid conflicts when two _disjoint_ entities are working with the same schema. Here we have a central authority on the protocol trying to partition itself. This makes no sense to me. Even if you want to separate extensions from the core, there is still a better way to do it and keep everything simple and elegant - two things xmpp is not.
The protocol is bloated. Again - my opinion. But compared to something like XML-RPC (in terms of syntax and structure), XMPP feels like everything was an afterthought that didn't fully fit together with the original design. The separation between presence, iq, and message stanzas feels extremely awkward and arbitrary to me. Why not have a single stanza, with an attribute that defines its type? Get rid of namespaces, and have a registry of node types I you wish. Think of how much cleaner the protocol would be.
Likewise, this protocol seems like it was designed for humans - having a computer use it doesn't seem to be on the agenda. This comes out in the fact that no abbreviations are used to try and make XML data a bit smaller in size. Why would you design a protocol for use in real-time and keep things stanzas? Yes, you can use compression, but not all clients and servers support it. Think of how much bandwidth is wasted transporting useless information between computers. If I was designing the protocol I'd try and shorten all of the most commonly-used elements - instead of . Put computers and resource limitations before human convenience. You get rid of 6 additional bytes from the message stanza and processing is also faster. You may think I'm just going on about nothing here, that it doesn't make any real difference, but consider what a change like that would do to servers processing several thousand message stanzas every second.
On the same topic of being designed for humans, an xmpp session (from start to end) looks like a perfectly valid xml document. You have a root element (which is closed at the end), and stanzas in the middle. Again, this is appealing for a human, but it makes code very ugly. Why in the world would you design it this way? Why should I have some special code to deal with an opening element that is never complete till the session is over? I already have an xml parser that deals with complete xml structures, and a piece of code that waits until a full stanza is received before processing it. Why not make it easy FOR COMPUTERS to deal with, and allow me to use that code for ALL xmpp communications. Hell, make each stanza a separate document. This is again a case where the designers thought "what would a human find most pleasing," and completely ignored the needless complexity in implementation added by their decisions.
I could go on and on describing problems with xmpp, but you have a rough idea here. Personally, I would hate for this protocol to become the standard for IM communications. It is bloated, needlessly complicated, and very awkward to use and implement. Sadly, I think with Google's support it will become the standard, and sooner or later something else will come along with another protocol causing a continuation of the IM wars.
I'm with you. I've been with SunRocket for over 2 years now, and have actually been fairly happy with their service. Good thing I read Slashdot because they don't seem to be going out of their way to notify the customers about this. Can't call their support either, so I guess all we can do is wait until our accounts have been transferred and hope that the phone numbers are not lost. When you say subscribers have been moving to ViaTalk, do you mean that's where SunRocket is moving them or just those customers who were able to move before support went offline?
I don't know what your parents taught you, but for me sharing isn't "I have some cookies and I'd be glad to give you some, but only if you promise to share with others." No, it's "I have some cookies, here have some."
If you want to share, you'll do what the developer of SQLite does and place your work in the public domain. BSD is one step away from that, and GPL is not even close. It doesn't benefit anyone when you start adding artificial restrictions on your work. Create it, be proud of it, and let others use it as they wish. That's my philosophy.
I don't see this as something of great value. Right now I'm working on my laptop which is running FreeBSD under full disk encryption using GELI and AES-256. I have the boot splice unencrypted, that only has the kernel and the boot code, and everything else, including swap, is on the encrypted slice. A slight performance hit due to software encryption? Yes. But is the weaker hardware encryption worth extra money? Not to me. In fact, I would much rather spend the money on a separate hardware encryption solution rather than one which is built-in to the drive. That way, any old drive you may have lying around could be fully-encrypted and used for storing sensitive data. Making this sort of encryption as part of the drive doesn't make sense to me.
On my windows machines it would probably be of more use since I can't encrypt the system drive, but everything else is encrypted via TrueCrypt. In order words, all my data which needs to be protected, is. And like I said before, with software I can use AES-256 which makes me more comfortable than 128-bit. You can probably argue that today it doesn't matter, the latter is good enough. It's more about psychology, I think.
Take a look at virgin mobile. I used to have Verizon and paid almost $50 each month. With virgin I have the $0.18 per minute plan and pay only $20 per 90 days. The idea is that you have to pay at least $20 every 90 days to keep the service, and since I talk very rarely I haven't ever needed to pay more. What I really like about them is that you don't need to worry about payments, you can set it up to automatically charge your credit care either every 90 days, or when you have less than $5 left.
On the down-side, the service is worse than Verizon (actual reception that is). In places with strong signal it's fine, but at my house it's a bit worse, for example. This depends on your location though, so just take a look at their coverage map. I've been with them for almost 3 months now and am overall very happy.
Slashdot Mirror
I spent this evening trying to get it to encrypt a clean install of Windows XP SP2.
First, there is a problem with creating a recovery CD. If you try to burn the image TC gives you with Alcohol 120% or PowerISO, it will not work. Alcohol burns it, but validation fails. PowerISO doesn't even want to burn that image. You have to use InfraRecorder that their website links to. I have no idea what they are doing with that image, but there is no reason why I should have to go out and get some other piece of software to do the same thing as Alcohol or PowerISO.
That's not the major problem though. So far, I could not encrypt my drive. The process goes to about 21% then dies with a "Data error (cyclic redundancy check)." Very descriptive, as you can tell. I just finished running checkdisk to see if this could be caused by bad disk sectors - nope. The hard drive is perfectly fine. I'm not the only one having the same problem. There are a number of people on wilderssecurity forums that have the same issue.
I have that 21% of the disk encrypted, and pre-boot authentication works fine... now if it could only work for the entire disk. The other thing I found out is that apparently encrypting your system drive will disable hibernation. Not a great thing for my laptop (Fujitsu P7010, in case you were interested). I could live without hibernation for a while, assuming that it will come eventually in a later release. The encryption problem is another story.
I wrote a php xmpp client and server a few months back. In my humble opinion it is a poorly-designed protocol.
For one thing, it is an example of how NOT to use namespaces in XML. Many elements are needlessly separated out, causing a lot of confusion and problems for simple xml parsers. Namespaces do not solve the problem of name conflicts, as the xmpp site still has a registry of namespace names. Separating out extensions - maybe, but the whole point of namespaces is to avoid conflicts when two _disjoint_ entities are working with the same schema. Here we have a central authority on the protocol trying to partition itself. This makes no sense to me. Even if you want to separate extensions from the core, there is still a better way to do it and keep everything simple and elegant - two things xmpp is not.
The protocol is bloated. Again - my opinion. But compared to something like XML-RPC (in terms of syntax and structure), XMPP feels like everything was an afterthought that didn't fully fit together with the original design. The separation between presence, iq, and message stanzas feels extremely awkward and arbitrary to me. Why not have a single stanza, with an attribute that defines its type? Get rid of namespaces, and have a registry of node types I you wish. Think of how much cleaner the protocol would be.
Likewise, this protocol seems like it was designed for humans - having a computer use it doesn't seem to be on the agenda. This comes out in the fact that no abbreviations are used to try and make XML data a bit smaller in size. Why would you design a protocol for use in real-time and keep things stanzas? Yes, you can use compression, but not all clients and servers support it. Think of how much bandwidth is wasted transporting useless information between computers. If I was designing the protocol I'd try and shorten all of the most commonly-used elements - instead of . Put computers and resource limitations before human convenience. You get rid of 6 additional bytes from the message stanza and processing is also faster. You may think I'm just going on about nothing here, that it doesn't make any real difference, but consider what a change like that would do to servers processing several thousand message stanzas every second.
On the same topic of being designed for humans, an xmpp session (from start to end) looks like a perfectly valid xml document. You have a root element (which is closed at the end), and stanzas in the middle. Again, this is appealing for a human, but it makes code very ugly. Why in the world would you design it this way? Why should I have some special code to deal with an opening element that is never complete till the session is over? I already have an xml parser that deals with complete xml structures, and a piece of code that waits until a full stanza is received before processing it. Why not make it easy FOR COMPUTERS to deal with, and allow me to use that code for ALL xmpp communications. Hell, make each stanza a separate document. This is again a case where the designers thought "what would a human find most pleasing," and completely ignored the needless complexity in implementation added by their decisions.
I could go on and on describing problems with xmpp, but you have a rough idea here. Personally, I would hate for this protocol to become the standard for IM communications. It is bloated, needlessly complicated, and very awkward to use and implement. Sadly, I think with Google's support it will become the standard, and sooner or later something else will come along with another protocol causing a continuation of the IM wars.
I'm with you. I've been with SunRocket for over 2 years now, and have actually been fairly happy with their service. Good thing I read Slashdot because they don't seem to be going out of their way to notify the customers about this. Can't call their support either, so I guess all we can do is wait until our accounts have been transferred and hope that the phone numbers are not lost. When you say subscribers have been moving to ViaTalk, do you mean that's where SunRocket is moving them or just those customers who were able to move before support went offline?
I don't know what your parents taught you, but for me sharing isn't "I have some cookies and I'd be glad to give you some, but only if you promise to share with others." No, it's "I have some cookies, here have some."
If you want to share, you'll do what the developer of SQLite does and place your work in the public domain. BSD is one step away from that, and GPL is not even close. It doesn't benefit anyone when you start adding artificial restrictions on your work. Create it, be proud of it, and let others use it as they wish. That's my philosophy.
I don't see this as something of great value. Right now I'm working on my laptop which is running FreeBSD under full disk encryption using GELI and AES-256. I have the boot splice unencrypted, that only has the kernel and the boot code, and everything else, including swap, is on the encrypted slice. A slight performance hit due to software encryption? Yes. But is the weaker hardware encryption worth extra money? Not to me. In fact, I would much rather spend the money on a separate hardware encryption solution rather than one which is built-in to the drive. That way, any old drive you may have lying around could be fully-encrypted and used for storing sensitive data. Making this sort of encryption as part of the drive doesn't make sense to me.
On my windows machines it would probably be of more use since I can't encrypt the system drive, but everything else is encrypted via TrueCrypt. In order words, all my data which needs to be protected, is. And like I said before, with software I can use AES-256 which makes me more comfortable than 128-bit. You can probably argue that today it doesn't matter, the latter is good enough. It's more about psychology, I think.
Take a look at virgin mobile. I used to have Verizon and paid almost $50 each month. With virgin I have the $0.18 per minute plan and pay only $20 per 90 days. The idea is that you have to pay at least $20 every 90 days to keep the service, and since I talk very rarely I haven't ever needed to pay more. What I really like about them is that you don't need to worry about payments, you can set it up to automatically charge your credit care either every 90 days, or when you have less than $5 left.
On the down-side, the service is worse than Verizon (actual reception that is). In places with strong signal it's fine, but at my house it's a bit worse, for example. This depends on your location though, so just take a look at their coverage map. I've been with them for almost 3 months now and am overall very happy.