RE: VSphere client on Linux
From: discuss-boun...@blu.org [mailto:discuss-boun...@blu.org] On Behalf Of Jerry Feldman What I personally do is to run a windows VM for this purpose (and any other purpose that requires windows.) We're actually running ESX 4 Update 2. This machine was configured by our Toronto IT people, and other than physical access I don't yet know any of the passwords. I'm sorry, what I meant was - Because of expecting the vsphere client is only available to run on windows, yet I'm not running windows on my laptop... I run windows inside a VM on the laptop, in order to run vsphere client on the laptop. I am running ESXi 4u2, and if I simply browse to http://vmhost then there is a download link for the windows vsphere client and no others. Um... Depending on what you want to do, certain operations including VM guest startup shutdown can be done via command line (for which a linux client certainly does exist) or ssh command line (if you have sshd enabled on the server), without using the vsphere client. 'Course it's best if you are able to get the root password on the server. Cuz none of those clients are going to work unless you can login to the server. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: VSphere client on Linux
On 04/23/2011 07:44 AM, Edward Ned Harvey wrote: From: discuss-boun...@blu.org [mailto:discuss-boun...@blu.org] On Behalf Of Jerry Feldman What I personally do is to run a windows VM for this purpose (and any other purpose that requires windows.) We're actually running ESX 4 Update 2. This machine was configured by our Toronto IT people, and other than physical access I don't yet know any of the passwords. I'm sorry, what I meant was - Because of expecting the vsphere client is only available to run on windows, yet I'm not running windows on my laptop... I run windows inside a VM on the laptop, in order to run vsphere client on the laptop. I am running ESXi 4u2, and if I simply browse to http://vmhost then there is a download link for the windows vsphere client and no others. Um... Depending on what you want to do, certain operations including VM guest startup shutdown can be done via command line (for which a linux client certainly does exist) or ssh command line (if you have sshd enabled on the server), without using the vsphere client. 'Course it's best if you are able to get the root password on the server. Cuz none of those clients are going to work unless you can login to the server. One of our requirements is that everyone in our office be able to start up their VMs. The IT guy in New York told me that he would give me what I need,, but at the present time, Toronto is in charge. I've got about 10 more VMs that need to be migrated, and I'll let the Toronto people move them since I have a couple of development projects. -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
RE: ZFS and block deduplication
From: discuss-boun...@blu.org [mailto:discuss-boun...@blu.org] On Behalf Of Mark Woodward I have been trying to convince myself that the SHA2/256 hash is sufficient to identify blocks on a file system. Is anyone familiar with this? I am intimately familiar with this. And on planet Earth, yes it is sufficient. However, the cost of explaining your decision to anyone who is skeptical outweighs the cost of enabling verification. So as long as there's even a possibility that anybody might challenge your decision, you should enable verification. But if you're the boss and nobody will second-guess you, then you can safely rely on just the hash. If you'd like to read more about it, try this search... Google for zfs-discuss collision http://www.google.com/search?q=zfs-discuss+collisionie=utf-8oe=utf-8aq=t; rls=org.mozilla:en-US:officialclient=firefox-a Mostly in the extremely long thread, (Fletcher+Verification) versus (Sha256+No Verification) PS. Safely is a relative term. The probability of collision is non-zero, but the probability is essentially zero relative to Human Extinction Events, which means you can (relatively) safely rely on just the sha256 hash. If you want to calculate the actual probability of a collision, assume a 4k (2^12 bytes) block size (worst case) and every single block is precisely the same size (which isn't realistic, but is worst case) and every single block is unique (in which case why have you enabled dedup. So again, unrealistically evil-clown scenario worst case) and if your data pool size is the largest in the world (again worst case) say ... 2PB (2^41 bytes)... that would be physically impossible to hold the dedup tables using hardware currently available in the world, but again... Evil clown worst case for accidental collision. Then the number of blocks is 2^41 / 2^12 = 2^29 unique blocks. The formula on wikipedia for the birthday problem is: p(n;d) ~= 1-( (d-1)/d )^( 0.5*n*(n-1) ) In this case, n=2^29 d=2^256 Using bc to calculate the answer: bc -l n=2^29 d=2^256 scale=1024 1-e( ( 0.5*n*(n-1)*l((d-1)/d) ) ) .00012446030 I manually truncated here (precision goes out 1024 places). This is 1.24E-60 Notice: There are estimated 1E50 atoms in Earth. So in the evil clown worst case for sha256 collision, the probability for collision is about the same as randomly selecting the same atom twice consecutively from 1000 Earths. Note: I had to repeat the calculation many times in bc, setting a larger and larger scale. The default scale of 20, and even 64 and 70 and 80 were not precise enough to produce a convergent answer around the -57th decimal place. So I just kept going larger, and in retrospect, anything over 100 would have been fine. I wrote 1024 above, so who cares. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: Speaking of on-line/cloud storage... Wuala
I am paying $100/year for 50G on Drop box. Wuala offer the same amount for $80. Right now I am using 25G. If you have a server on 24/7 like one of those computers at the last meeting, then you could go for the $30 plan. Let wuala have 100G of that server for storage, and you have 100G of shared storage. There is the cost of running that box 24/7 which I don't know how to estimate. The security looks better. All files are encrypted, then shipped around. Is the UI that different? I have been impressed by the simplicity of Dropbox. Doug ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: Speaking of on-line/cloud storage... Wuala
Once you go pro and provide storage, then only the $30/year plan makes sense. Nice. Does Wuala do any better with conflicting files, or have you been luck enough to avoid the problem? Doug ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: ZFS and block deduplication
On 04/23/2011 08:31 AM, Edward Ned Harvey wrote: From: discuss-boun...@blu.org [mailto:discuss-boun...@blu.org] On Behalf Of Mark Woodward I have been trying to convince myself that the SHA2/256 hash is sufficient to identify blocks on a file system. Is anyone familiar with this? I am intimately familiar with this. And on planet Earth, yes it is sufficient. However, the cost of explaining your decision to anyone who is skeptical outweighs the cost of enabling verification. So as long as there's even a possibility that anybody might challenge your decision, you should enable verification. But if you're the boss and nobody will second-guess you, then you can safely rely on just the hash. If you'd like to read more about it, try this search... Google for zfs-discuss collision http://www.google.com/search?q=zfs-discuss+collisionie=utf-8oe=utf-8aq=t; rls=org.mozilla:en-US:officialclient=firefox-a Mostly in the extremely long thread, (Fletcher+Verification) versus (Sha256+No Verification) PS. Safely is a relative term. The probability of collision is non-zero, but the probability is essentially zero relative to Human Extinction Events, which means you can (relatively) safely rely on just the sha256 hash. If you want to calculate the actual probability of a collision, assume a 4k (2^12 bytes) block size (worst case) and every single block is precisely the same size (which isn't realistic, but is worst case) and every single block is unique (in which case why have you enabled dedup. So again, unrealistically evil-clown scenario worst case) and if your data pool size is the largest in the world (again worst case) say ... 2PB (2^41 bytes)... that would be physically impossible to hold the dedup tables using hardware currently available in the world, but again... Evil clown worst case for accidental collision. Then the number of blocks is 2^41 / 2^12 = 2^29 unique blocks. The formula on wikipedia for the birthday problem is: p(n;d) ~= 1-( (d-1)/d )^( 0.5*n*(n-1) ) In this case, n=2^29 d=2^256 Using bc to calculate the answer: bc -l n=2^29 d=2^256 scale=1024 1-e( ( 0.5*n*(n-1)*l((d-1)/d) ) ) .00012446030 I manually truncated here (precision goes out 1024 places). This is 1.24E-60 Notice: There are estimated 1E50 atoms in Earth. So in the evil clown worst case for sha256 collision, the probability for collision is about the same as randomly selecting the same atom twice consecutively from 1000 Earths. Note: I had to repeat the calculation many times in bc, setting a larger and larger scale. The default scale of 20, and even 64 and 70 and 80 were not precise enough to produce a convergent answer around the -57th decimal place. So I just kept going larger, and in retrospect, anything over 100 would have been fine. I wrote 1024 above, so who cares. You know, I've read the same math and I've worked it out myself. I agree it sounds so astronomical as to be unrealistic to even imagine it, but no matter how astronomical the odds, someone usually wins the lottery. I'm just trying to assure myself that there isn't some probability calculation missing. I guess my gut is telling me this is too easy. We're missing something. Besides, personally, I'm looking at 16K blocks which increases the probability a bit. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: Speaking of on-line/cloud storage... Wuala
On Sat, Apr 23, 2011 at 10:34 AM, Hsuan-Yeh Chang hsuan...@yahoo.com wrote: Just out of curiosity, how does cloud storage like Wuala and Dropbox works? Do they just put your files on the server (like googledoc) and provide a convenient user interface, or do they make copies (i.e., sync) of files in each device? Hsuanyeh from what I can tell, it uses something like rsync under the covers, puts a copy on the central server and on each 'client' machine. There is an optimizer that will sync from the 'closest source', so if you have 3 machines at home and one at the office, if you change or add a file on one machine at home, they will 'share' the file directly with each other and the central server, and the office machine will appear to share the file a bit more slowly. That is only by observation, not from any real vendor information. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
kdepim source
Hello, I'm trying to make a few modifications to kmail for a paper I would like to publish. Anyway, I want to do as little work as possible and I would like to start with the Fedora 14 source package and I'm having a tough time finding it. Anyway, does anyone know where I can find the kdepim source package that is matched with Fedora 14? Thanks - I appreciate the help, Anthony ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: Speaking of on-line/cloud storage... Wuala
On Apr 23, 2011, at 12:36 PM, Doug wrote: Once you go pro and provide storage, then only the $30/year plan makes sense. Nice. It's semantics, but Wuala's use of the phrase go pro means trading storage, paying for storage, or both. One can go pro without paying a cent to Wuala and LaCie. Does Wuala do any better with conflicting files, or have you been luck enough to avoid the problem? I have not yet run into problems of this sort, yet. --Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: Speaking of on-line/cloud storage... Wuala
On Apr 23, 2011, at 11:34 AM, Hsuan-Yeh Chang wrote: Just out of curiosity, how does cloud storage like Wuala and Dropbox works? Do they just put your files on the server (like googledoc) and provide a convenient user interface, or do they make copies (i.e., sync) of files in each device? The simple answer to the question is that both use local copies for storage. These are not network file systems like NFS or AFS. Dropbox works a lot like rsync or Unison. It has a directory that it monitors for changes. Any changes are synchronized with an Amazon S3 bucket. Any changes to that bucket are mirrored to other Dropbox clients on the same account. Wuala works a little differently. It creates a Cryptree file system and mounts it like a removable drive via FUSE (Linux, Mac) or CBFS (Windows). Changes to the FUSE/CBFS are encrypted and chunked, and these chunks are sent first to the Wuala storage servers in Europe and second to the Wuala cloud. This cloud is composed of other Wuala clients trading storage. Changes to the Cryptree are downloaded by other Wuala clients on the same account. Wuala layers automated backups and sync on top of the mounted Cryptree so there is a greater local storage overhead with Wuala if you use these features. On the other hand, Wuala offers substantially better privacy and security than Dropbox. --Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
