"Regarding Kim - AFAIK he was was found innocent. I'm talking about Megaupload case, not several former cases."
Nope.He's still in New Zealand, fighting extradition to the USA for criminal charges for the megaupload case. Joe On Mon, Jul 13, 2020 at 6:50 AM R.S. <r.skoru...@bremultibank.com.pl> wrote: > OK, now I understand the legal aspect. I also disgree with that, but > this is completely off-topic (and related to Kim's problems). > However "something" as a service could mean colocation, PaaS, SaaS, etc. > In some scenarios you buy working solution, not software license. In > such case you are not responsible for the licenses. That's like cloud > backup - I pay for backup, I'm not aware what backup software was used > and wether it was licensed. I also don't check driver licence in a taxi, > nor insurance policy. I pay for transfer to airport. > > Regarding Kim - AFAIK he was was found innocent. I'm talking about > Megaupload case, not several former cases. > > BTW: interesting issue with data in a cloud. I did really use > Megaupload. I don't feel uncomfortable with that, because I used it for > transfer my photographs to a person who asked me for. My pictures from > some tour. My selection of pictures with this guy and his wife (their > camere failed, so I helped them). I uploaded it to Megaupload. Used > password for privacy and sent password and link to this guy. Files were > safe - everthing was in a cloud. Suddenly someone decided to destroy the > service. Was he right? Not in case of my pictures. However he didn't > care. More: legal court sentence was it wasn't right. What about my > pictures? They gone. > What can I do? Fortunately I have my own backup, so I had to repeat > selection of the pictures and send it using other method. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 13.07.2020 o 13:25, Joe Monk pisze: > > My point is, once you rent that computer and put your stuff on it, it is > no > > longer "someone else's computer". It is now YOUR computer. YOU are > > responsible for it. > > > > Joe > > > > On Mon, Jul 13, 2020 at 5:35 AM R.S. <r.skoru...@bremultibank.com.pl> > wrote: > > > >> I heard about Kim Dotcom, but I don't understand what you mean. > >> I'm not talking here about legal issues, so there is nothing to love. > >> And the cloud is still someone else's computer, isn't it? > >> Keeping data in cloud is still keeping data on someone else's media like > >> disk or tape. Usually tape for large amounts and reasonable prices (with > >> horrible access times). The main difference is you don't know where is > >> your data. > >> > >> (off topic drift) > >> Of course cloud is valuable in man cases, especially for smal and medium > >> businesses. Sometimes "don't do it, use our services" is true. You don't > >> buy brewery to have a beer to a dinner or you don't buy taxi car to get > >> to airport. However many companies still have their own truck fleet. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> W dniu 09.07.2020 o 16:22, Joe Monk pisze: > >>> Im sure that Kim Dotcom would love your legal theory... > >>> > >>> Joe > >>> > >>> On Thu, Jul 9, 2020 at 7:51 AM R.S. <r.skoru...@bremultibank.com.pl> > >> wrote: > >>>> Azure? Cloud? > >>>> There is no cloud. It is just someone else's computer. ;-) > >>>> > >>>> -- > >>>> Radoslaw Skorupka > >>>> Lodz, Poland > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> W dniu 08.07.2020 o 17:46, Joe Monk pisze: > >>>>> I do a backup to spinning storage, then a copy of that backup to > Azure > >>>> for > >>>>> long term. > >>>>> > >>>>> Joe > >>>>> > >>>>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz <sme...@gmu.edu> > wrote: > >>>>> > >>>>>> I've always gone with dual* backups, with one copy off site. Remote > >>>>>> mirroring is a good option where policy permits, and even if > >>>> retensioning > >>>>>> is no longer relevant, rereading backups periodically will give you > a > >>>> heads > >>>>>> up if one copy goes south. I would consider even correctable errors > to > >>>> be > >>>>>> red flags. > >>>>>> > >>>>>> Any medium you use will have failure modes. > >>>>>> > >>>>>> Multiple PiT recovery is good for "whoops!" moments and possibly for > >>>>>> audits. > >>>>>> > >>>>>> Large or small, each shop must do it's own risk assessments in the > >>>> context > >>>>>> of its own obligations and priorities. > >>>>>> > >>>>>> * Depending on the value of the data, you might want more than 2. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Shmuel (Seymour J.) Metz > >>>>>> http://mason.gmu.edu/~smetz3 > >>>>>> > >>>>>> ________________________________________ > >>>>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >>>> behalf > >>>>>> of Bill Ogden [og...@us.ibm.com] > >>>>>> Sent: Wednesday, July 8, 2020 9:27 AM > >>>>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>>>> Subject: Re: Storage & tape question > >>>>>> > >>>>>> Probably many others will chime in on this. I have lost RAID 5 > arrays > >>>> with > >>>>>> two disk failures within an hour of each other. RAID is nice, but > one > >>>> must > >>>>>> allow for failures. > >>>>>> > >>>>>> Long ago I was involved with reading archived tapes and transferring > >> the > >>>>>> data to CDs. The programs involved were home-written and the project > >>>> ended > >>>>>> up going nowhere. However, we discovered that tapes kept too long > >>>> started > >>>>>> having errors. (At that point, for the CD copy, we just logged the > >> error > >>>>>> and accepted the corrupt data; what else could we do?) How long is > >> "too > >>>>>> long"?? It was variable, but measured in a few years. The advice > then > >>>> was > >>>>>> to minimally read the tapes every year or so to "retension" them. > >> Don't > >>>>>> know if this would apply to more modern tape media. (We also > >> discovered > >>>>>> that locally "burned" CDs are not expected last forever.) > >>>>>> > >>>>>> IMHO, the key point for tape backups are (1) off-site storage, (2) > >>>>>> multiple PiT recovery, (3) logical error recovery. All this can be > >> done > >>>>>> with disk-only environments involving remote copy and lots of disk > >>>> space, > >>>>>> but all that becomes expensive for smaller shops. > >>>>>> > >>>>>> Bill Ogden > >>>>>> > >>>>>> > >>>> > >> > > > ====================================================================== > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2020 r. wynosi 169.401.468 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.401.468 as at 1 January 2020. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
