[01:12] https://www.flickr.com/photos/55408069@N04/ [01:15] Archive.org's been concentrating on just staying ahead of the flood. [01:16] I really broke them, you know. [01:16] Bringing on this shit, the shit I was doing, etc. [01:16] Broke their rules, broke the limits, caused crashes [01:16] So the more intense grabbing we're doing everywhere, that's new [01:38] alright [01:40] Ravenloft, see image sizes, lovely quality :D - https://nymph.seedboxes.cc/skitty/flickr_55408069_N04/ - love flickr for such things [01:45] ohhdemgir: don't love it too much [01:45] :P [01:46] ohhdemgir: also, I presume that's being archived? [01:47] is now [01:47] ufufufu [01:49] say wut [01:50] conspiratorial laugh [01:50] huhuhuhu [01:51] ahh, I'm forever learning this internet malarky [03:26] i know i break lots of limits with IA [03:53] Wayback Machine saves the day again :) [04:20] hmm [04:20] "2.2. Your use of the [Redis To Go] Service must comply with all applicable laws, regulations and ordinances, including any laws regarding the export of data or software. You agree not to use the Service in the design, development, production, or use of missiles or the design, development, production, stockpiling, or use of chemical or biological weapons." [04:20] guess running my hyperloglog-based kill count simulation on redis to go is out :( [04:29] yipdw: 'MURRICA [04:30] joepie91_: I have this idea of someone using Redis to keep count of, like, VX canisters [04:30] they have a program to decrement/increment the count, but it doesn't use MULTI/EXEC/WATCH properly [04:30] so the count is all fucked due to concurrent operation [04:30] and they try to blame Redis To Go [04:30] it's really funny on its own :P but it's actually a fairly common TOS clause [04:30] yeah [04:31] it is [04:32] the idea of someone using a cloud service to manage weapons of mass destruction is something I find hilarious [04:33] "what do you mean, there's a box of nuclear warheads missing? I thought we used the Cloud?" [04:34] we can't access those shipping records because us-east-1d is down again [04:34] THIS IS WAR, AMERICA [04:35] Pixorial is deleting the photos of our stockpile [04:35] CONCLUSION: Archive Team aids terrorists [04:39] Weapons of Mass Archiving. [04:42] ? [04:42] WHAT is Pixoral doing? [04:43] shutting down July 18, 2014 [04:43] db48x is working on fetch code [06:12] yipdw: "We can create a ZIP file containing all of your media files for you to download." [06:12] well that's something at least [06:12] that said, obligatory bashing [06:12] "Pixorial Photo & Video Sharing Without Limits" [06:12] ... without limits, until we shut down [06:13] you can share anything at pixorial [06:13] the only limit is yourself [09:36] ha [09:36] ISP in NL offering 'cloud storage' screwed up and baleeted user data [09:36] and is found to be liable for compensation [09:37] and their "no liability" clause was overruled in the case, because the provider had screwed up [09:41] url to more details? this is relevant [09:43] joepie91_? [09:43] Atluxity: http://blog.iusmentis.com/2014/06/24/kpn-aansprakelijk-voor-verloren-clouddata-ondanks-algemene-voorwaarden/ [09:43] (lawyer blog) [09:43] thanks [09:48] joepie91_: im not so fond about that [09:48] because i used to do alot of online backup [09:48] and we explained to our clients that if they loose the encryption key we would not be able to reset the data [09:48] midas: ISP screwed up, data was lost, customer had negative consequences - I don't see how there's any reasonable conclusion other than "ISP is liable" [09:48] um [09:48] you haven't read the article well enough [09:49] go read it again :P [09:49] Toen kwam er een harddiskcrash bij haar bedrijf, maar gelukkig had ze de online backup nog. Helaas geen logingegevens meer. KPN heeft dan het beleid dat ze een nieuw account aanmaken en de bestanden overzetten. [09:49] SHE didnt have her login credentials [09:49] SHE [09:49] not KPN, the client [09:50] midas: again, you did not read the article well enough [09:51] joepie91_: im sorry, but you didnt read it well enough in this case. [09:51] * joepie91_ sighs [09:51] midas: I really should not have to point this out to you, you're a native Dutch speaker [09:51] "Dit vonnis betekent niet dat Ã©lke cloudprovider nu automatisch onbeperkt aansprakelijk is voor alle schade. Er moet nog steeds wel een fout zijn gemaakt bij de dienstverlener. En niet elke fout zal zo ernstig zijn als wat KPN hier voor elkaar kreeg." [09:51] WHICH MEANS THAT IF YOU USE CLIENT-SIDE CRYPTO, THIS DOES NOT EVEN APPLY. [09:51] seriously, this isn't legalese [09:52] the explicit requirement is that /the ISP makes a mistake/ [09:52] if you provide client-side encrypted stuff that you literally cannot access, and the customer loses their key [09:52] then /you did not make a mistake/ [09:53] still, the blogpost is wrong and should be changed [09:53] just call the NSA they always have the backup key [09:53] they are stating that the client lost the keys, KPN should fix it [09:54] which is pure bullcrap [09:54] midas: no, the blogpost isn't wrong, that's not what they're stating, and you should learn to read [09:54] people should be aware that backups are the responsability of the client [09:54] context, dude [09:55] Lets agree to disagree on this [09:55] "omg but this sentence said that the customer lost the key and that's not a valid reason" [09:55] which is exactly WHY it's qualified latero n [09:55] no [09:55] it's very simple, you're complaining about a statement while completely ignoring the qualification later on [09:55] your complaint is logically unsound [09:56] so please get off your fucking horse and read it in context [09:56] I love my fucking horse and shall stay on it. Like it or not. [09:57] rather than just reading that single paragraph and concluding that it's "wrong" while entirely ignoring the rest of the article around it [12:46] awesome old shit on FTP's [12:46] Here's version 0.4e of UUDEVIEW (MS-DOS and MS-Windows versions). It's a [12:47] *very* good program for uu- and base-64 (de)coding. The newest version of [12:47] the program, as well as the Unix version and lots of information can be [12:47] found at UUDEVIEW's Home Page: [12:47] 1996 [14:53] ooooo tinyback is back? [16:35] midas: it will be shipped tomorrow, i guess the shop is swamped. usually they are faster [16:35] shipped to me, not you yet :) [16:46] anyone here going to OKFest? [18:21] ok :) [18:22] where is OKfest? [18:22] berlin [18:22] berlin! [18:22] hmm should think about it [18:23] should get my work to sponsor me [18:29] so i'm uploading 1901 of The Sydney Morning Herald [18:29] i'm also uploading missing files in my 2007-01 cbsnews.com video uploads [18:30] there missing cause i got slowdown errors [22:06] hi, FYI [22:06] https://www.webhostingtalk.com/showthread.php?s=cd7d7e7514c11de3534bae7eb21fbde7&p=9155713 [22:06] OpenVZ container breakout vulnerability [22:06] affects a number of common openvz setups [22:06] if your openvz provider hasn't emailed you about a reboot or patch yet, send them this [23:15] i got my own dedicated server [23:35] on a related note, did you see the world-readable IPMI folder on Supermicro servers? [23:36] dashcloud, link? [23:40] give me a minute [23:41] this: http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ and this: http://threatpost.com/plaintext-supermicro-ipmi-credentials-exposed