Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 117 reacties

Een eigenaar van een kleine hostingprovider meldde dat hij alle data van het bedrijf, inclusief backups, met het bash-script rm -rf {foo}/{bar} verwijderd had. Hij zou de gegevens met hulp van een bedrijf voor dataherstel terug kunnen krijgen, maar zijn verhaal roept vragen op.

Het bedrijf zou de hosting van 1535 klanten regelen. Dat de eigenaar, Marco Marsala, ook zijn back-ups meenam bij zijn ongelukkige actie, kwam volgens hem omdat het script ook de partities waar de back-ups opstonden, weer koppelde. Marsala vroeg op het Server Fault-forum of zijn fout te herstellen was. Hij schrijft daar dat hij een bash-script met rm -rf {foo}/{bar} via Ansible draaide. Dat de variabelen ongedefinieerd waren, zou zijn gekomen door een fout in de regel code die vooraf aan het rm-commando ging, al schrijft hij niet wat dat dan was.

De reden dat hij het commando uitvoerde, zou zijn omdat het onderdeel van zijn back-upprocedure was. Het zou blijkbaar bedoeld zijn om oude back-ups te verwijderen. Omdat er niet specifiek aangegeven was wat te verwijderen, ging alles naar de kelder.

De antwoorden op de hulpvraag van Marsala op Server Fault of zijn actie ongedaan te maken was, waren over het algemeen niet heel behulpzaam. Veel reacties kwamen erop neer dat hij zijn eigen bedrijf om zeep geholpen had. Ook is niet duidelijk welke van de adviezen hij opgevolgd heeft. Wel bericht Marsala dat er een bedrijf in de arm genomen is dat aan dataherstel doet. Die zou een van de meer dan 1500 serverschijven geanalyseerd hebben en erin geslaagd zijn data te herstellen. Volgens dat niet met name genoemde bedrijf, zijn alle bestanden terug te halen, schrijft Marsala, alias 'bleemboy', op het forum. Hij claimt bezig te zijn met het verzamelen van het geld dat nodig is om alle schijven te laten behandelen.

Bij het verhaal zijn vraagtekens te zetten en op zijn minst laat Marsala wel erg veel details weg, stelt Tweakers' systeembeheerder Kees Hoekzema. Om het rm -rf-commando uit te kunnen voeren zonder de toevoeging --no-preserve-root, moet GNU core utilities van voor 2006 op de servers draaien. Marsala claimt CentOS 7 te draaien, waar die optie in ieder geval in zit. Sinds core utils uit 2006 moet namelijk die optie meegegeven worden aan het rm-commando om juist te voorkomen dat het hele bestandssysteem in één keer vernietigd wordt.

Er is verder op internet nergens iets terug te vinden over klagende gebruikers van het hostingbedrijf, wat anno 2016 wel te verwachten zou zijn. Het verhaal is hoe dan ook aanleiding om het maken van back-ups weer eens onder de aandacht te brengen.

rm -rf delete all files

Moderatie-faq Wijzig weergave

Reacties (117)

Volgens mij is dit gewoon een troll... Zoals je zelf al zegt werkt het commando rm -rf / helemaal niet op CentOS7. Het is hoogstens een leuke overdenking van een "wat als" scenario met mogelijke remedies tegen deze stupiditeit. Aan zijn StackOverflow vragen te zien klooit hij af en toe wat aan met servers maar een hostingbedrijf lijkt me onwaarschijnlijk...
We hadden idd. geconstateerd dat het een troll was ;) Maar we vonden het na wat gepuzzel toch ook wel weer aardig om te brengen, zeker omdat het op zo veel plekken tegelijk gepost werd. Beetje nuance brengen. En natuurlijk is het aloude rf-commando weer eens vermelden, altijd de moeite waard :)
Idd, rm heeft een leuke staart. Niet op trappen... Zo werd ik al een keertje gepakt met rm. Ik wou rm -r foobar* uitvoeren. Na typen van rm -r foob en een tab vond de console een bestand. De resultaat was dus rm -r foobar.foo * . De spatie betekende dat de directory geleegd werd. Gelukkig was het een source directory waarvan weinig van de bestanden niet ingecheckt waren. Het liep dus af met alleen maar een scheur in mijn broek en een pareltje zweet gespaard door de ervaring die opgedaan is. Voor de rest is de beschikbaar undelete tools niet te onderschatten.

Dit verhaal is natuurlijk een stuk leuker te lezen dan de troll zijn verhaal

[Reactie gewijzigd door NTwoO op 15 april 2016 15:49]

Dit geeft gewoon gratis reclame. Slechte reclame, kan ook reclame zijn. Lijkt me meer iets voor op GoT dan op de frontpage. De auteur van het artikel interviewt aan de ene kant de systeembeheerder van Tweakers, maar aan de andere kant is het artikel niet stellig genoeg. De titel (en die is belangrijk ivm RSS readers) is al helemaal suggestief.
Ik denk dat rm -rf / wel werkt, het systeem zal idd niet worden verwijderd, maar wel alle data, genoeg om in zo'n situatie te belanden.

Ik stel wel vragen bij het verhaal omdat hij later dd if= of= fout zette ...
Nee, het verwijdert niet al je data. Het verwijdert helemaal niks.
# rm -rf /
rm: it is dangerous to operate recursively on ‘/’
rm: use --no-preserve-root to override this failsafe
Wat wel zou kunnen is dat {bar} evalueert naar *, dan wordt wel al je data verwijderd.

Er is trouwens weinig verschil tussen "je hele systeem" en "al je data".
Nou een systeem is lang niet zo erg als je data, het boeit je niks dat je CentOS bak nog netjes draait maar alles in /var/mail of /var/www weg is (als hosting provider). Dan is er toch echt een groot verschil
/bin/bash is ook data. Je partitietabel zelf is data (een van de weinige dingen rie rm -rf /* overleeft)
FreeBSD hier. Ik heb het nooit geprobeerd maar zou kunnen dat ie het gaat proberen. Totdat rm de de runtime dll's die het systeem in de lucht houden en daarom in gebruik zijn tegen komt. Ook niet echt bestaande bestanden zoals /dev/*, /proc/* en /var/run/* gaan denk ik wel problemen opleveren.

Maar je zou er een simpel fixje voor kunnen maken door een shellscript met de naam rm via het shell PATH bereikbaar te maken en dan eerder dan /usr/bin waar bash normaalgesproken staat. Dat script vervolgens laten breken als er "rm -rf" in $@ voorkomt en zo niet de echte rm callen met dezelfde parameters. Of gewoon de source van rm aanpassen en de -rf / combinatie negeren.

Maar wie hanteert er nou de backups op hetzelfde systeem, en als ik het goed begrijp zelfs op dezelfde harddisk? Dat doe je er bij als 1e veiligheidsmaatregel maar dat noem ik geen echte backup.

[Reactie gewijzigd door blorf op 15 april 2016 16:43]

Neen, een rm -rf / word gewoon niet uitgevoerd zonder expliciete toestemming. Wat geloof ik wel werkt is een rm -rf /* .
Het is terecht om vraagtekens te zetten bij dit verhaal, maar is het voor tweakers niet juist leuk om over het theoretische scenario na te denken? Nadenken over wat je zelf zou doen in zo'n situatie is nuttig, het kan bewustzijn creŽren over het gebruik van tools om commando's op een volledige serverfarm tegelijk uit te voeren, en over de gebruikte manier van backups maken.

Al met al, hoogst waarschijnlijk een verzonnen verhaal, maar een waar naar mijn idee wel degelijk nuttige aspecten aan zitten. De kans dat er kleine hostingproviders zijn die Ansible gebruiken ťn hun backups doen zoals beschreven in dit verhaal, lijkt mij reeŽl.
Als je als hostingbedrijf je backups naar een remote mounted FS kan je beter opdoeken, het spijt me. Daar zijn veel betere tools voor die deze risico's niet met zich meebrengen. rsync bijvoorbeeld.

Desalniettemin zijn er ook bij professionelere aanpakken vast nog wel rampscenario's te verzinnen waarbij het misgaat, maar dan moet je toch wel iets meer je best doen dan wat er hier gebeurt is (of waarschijnlijk, wat er hier niet echt gebeurt is).
Jammer dat je omlaag wordt gemod, want je link maakt het wel overduidelijk idd.

"Oh nee ik heb per ongeluk rm -f / gedaan, hoe kan ik het terugkrijgen?"
- "<als deel van recovery verhaal> dd gebruiken om je partitie te clonen"
"Oh nee ik heb per ongeluk 'if' en 'of' omgedraaid bij de argumenten voor dd, dus nu zijn mijn schijven compleet overschreven met nullen"

Obvious troll is obvious }:|

(In other news: welke idioot verzint het nu dat de input en output argumenten van dd zo enorm veel op elkaar lijken |:()

[Reactie gewijzigd door .oisyn op 15 april 2016 12:44]

Niet alleen dat. Met een beetje zoeken kom je op zijn bedrijf uit (http://www.thenetworksolution.it/) welke gewoon draait en nergens een 'oops' melding geeft (wat je wel zou verwachten met 1500 klanten).

Maar het vreemde is dat hij dan vervolgens wel weer doorpraat over hoe hij een bedrijf heeft gevonden die het kan restoren maar dat het teveel geld kost. Vreemde troll.

En ik denk dat het nieuwsbericht ook voornamelijk is om vraagtekens te zetten bij de tientallen andere nieuwsberichten op andere sites die het overnemen zonder enig korreltje zout.
Met nog wat verder zoeken, zie je het nieuwsartikel in zijn eigen land waarin hij onder eigen naam aangeeft dat het puur een publiciteitsstunt is en trollen.
http://www.repubblica.it/...lvr.it&utm_medium=twitter
op mijn startup waar wij uitbesteed server management services adverteren', dit is de versie van de auteur dat onthult: '' Ik ben ook het schrijven van een boek over Unix for Dummies Horror Verhalen en toch dat feit er werkelijk gebeurd met iemand die ik ken
Weliswaar grof via google translate, maar de kern lijkt me duidelijk genoeg...
Eigen bedrijfje dat services verzorgt evenals eigen boek promoten via 1 stunt.

[Reactie gewijzigd door Xanaroth op 15 april 2016 15:14]

Fake of niet, Łberhaupt ben je een idioot van een beheerder als je met 1500 klanten geen offside backup hebt. Backup partitie's moet je nooit automatisch laten aankoppelen, dan loop je dit soort risico's

Men neemt thuis een dikke internetpijp en een NAS met 20+ TB en stuurt 's nachts gecomprimeerd en over een geŽncrypte verbinding de backup van DC naar thuis.

Daar heb je heus wel geld voor als je een hosting bedrijf hebt met 1500+ klanten.

Mocht het fake zijn, dan heb je nu wel mooi met naam en toenaam slechte reclame op je dak!
Men neemt thuis een dikke internetpijp en een NAS met 20+ TB en stuurt 's nachts gecomprimeerd en over een geŽncrypte verbinding de backup van DC naar thuis.
Een ISP die naar thuis backupped? God bespaar me voor dat soort cowboys.
naar huis hoeft tegenwordig niet meer voor een paar tientjes heb je een transip stack met genoeg data om je servertjes naartoe te backuppen...

maar in principe heb ik liever een goede hostingprovider die klein begint en houtje-touwtje oplossingen nodig heeft ... dan zo'n grote toko die een smak geld neersmijt standaard backup oplossingen aankoopt en geen flauw benul heeft fan hoe zijn hard en software nu echt werken, dat je belt met de vraag wanneer men php 4.2 eindelijk gaat upgraden, en met zegt, wij gebruiken standaard wat plesk 8 gebruikt en we zien geen noodzaak om te upgraden. (juni 2015)
Die kleine Cowboys hebben het over het algemeen beter voor mekaar als de grote prutsers...
Ha, dat is juist een van onze locaties, al is het naar kantoor. Eerst backup in zelfde DC, dan offsite naar ander DC en daarna offsite naar kantoor. Al is het simpelweg om altijd snel fysiek bij je data te kunnen. Een cloud oplossing zoals bv stack/Amazon eff alle gegevens downloaden gaat vaak niet snel en als je het snel nodig hebt is elke minuut 1 te veel. Dus liever een offsite naar andere locatie waaronder thuis dan cowboys die alles groot doen, maar daarna een dag zitten te wachten op de data. En ja dat heb ik gezien. (Al zal het wel zo zijn, elke waarde voor zijn geld)
het is een kleine hostingprovider zoals in het bericht staat en hij heeft geld nodig voor het restoren van de disk.

Dus dan zie ik dat als enige oplossing.

grotere hosting providers maken dit soort fouten niet zo snel.
het is een kleine hostingprovider zoals in het bericht staat en hij heeft geld nodig voor het restoren van de disk.

Dus dan zie ik dat als enige oplossing.

grotere hosting providers maken dit soort fouten niet zo snel.
Dat ben ik niet met je eens... wij waren destijds een heel kleine speler (windows- en webontwikkeling + webhosting waarbij de 3 vennoten de zaak als bijberoep hadden), maar we zaten wel bij Combell, die we toch als een van de betere (en uiteraard niet zo goedkope) hosting providers mogen zien.
Dat is dus best te betalen, zeker met 1500+ klanten (ok, wij hadden ook onze dev-projecten, maar hadden slechts 20-tal klanten).
Fake of niet, Łberhaupt ben je een idioot van een beheerder als je met 1500 klanten geen offside backup hebt. Backup partitie's moet je nooit automatisch laten aankoppelen, dan loop je dit soort risico's
Ik ben zo nochtans een jaar geleden de databases verloren voor het website(je) dat ik had gemaakt voor mijn huwelijk. De Nederlandse hostingprovider leek mij te vertrouwen (zeker niet de goedkoopste), maar blijkbaar is hij erin geslaagd om de database en de backups ervan tegelijkertijd te corrumperen...
Deze regel:
Er is verder op internet nergens iets terug te vinden over klagende gebruikers van het hostingbedrijf, wat anno 2016 wel te verwachten zou zijn.
Brainfart: dan denk ik aan louche (darkweb) servers die hij om zeep heeft geholpen en dat hij daarom zo vaag blijft. Die partijen / users gaan niet over het internet schreeuwen dat ze niet bij hun 'favoriete' website kunnen... Hoewel de hoster dan nog wel een uitdaging heeft.
Een van de dingen die het voor mij heel erg duidelijk maakt is dat rm -rf / niet meer werkt sinds 2006 zonder de --no-preserve-root parameter kortom het hele commando werkt niet eens op een moderne installatie (lees rm versie van na 2006).

Zie ook de man van rm: http://man7.org/linux/man-pages/man1/rm.1.html
Link werkt niet: 404
Topic is verdwenen.
Ik neem dit verhaal met een stevige schep aan zout maar dat neemt niet weg dat rm -rf / wel een bijzonder gevaarlijke instructie is.
Die kruiwagen zout had ik er ook al overheen gegooit. Maar dat doe ik ook bij het artikel dat jij aanhaalt.

Dat een file schrijfbaar is wil niet zeggen dat je de variable weggooit als je die file verwijderd. Sys is een psuedosystem, dus grote kans dat hij de delete gewoon negeert en alleen de link naar die variable weghaald zonder de variable uit de EFI settings te verwijderen. Dat artikel had gewoon de proef op de som moeten nemen en aantonen dat je op die manier een systeem (potentieel) kan bricken.

En verder is rm -rf / geen gevaarlijke instructie:
Status: Downloaded newer image for centos:centos7
[root@dfb63c806ad4 /]# rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
(neemt niet weg dat elke keer als ik het type ik 4 keer kijk of ik niet toevallig focus op een terminal heb ;))

[Reactie gewijzigd door Kees op 15 april 2016 12:36]

rm -rf /*

werkt wel... Veel sneller dan --no-preserve-root, en veel makkelijker per ongeluk te doen. Dus rm -rf blijft een gevaarlijk commando.
Inderdaad, of rm -rf * terwijl je in de root aanwezig bent. Op die manier heb ik laatst een (gelukkig tijdelijke) directory leeggegooit. Ik had verwacht dat er meerdere bestanden in zouden staan die met 'trace' begonnen, maar dat bleek er maar een te zijn. Een 'rm tra[tab]*' verder was de hele directory leeg.. oops.
Nou vraag ik mij af hť, je hebt een aantal Moederborden waar fysiek een UEFI-BIOS reset knop op aanwezig is. Kun je deze op op de manier die hierboven genoemd wordt ook definitief bricken, of zijn deze met het fysieke knopje op het mobo dan wel weer terug te halen.
Ik ben hier benieuwd na, aangezien een goede vriend van me volgens hemzelf zijn mobo gebrickt heeft.
En mocht dat op deze manier terug te draaien zijn, dan kan ik hem dat melden, aangezien hij over zo een mobo beschikt.
Een ASUS Crosshair V Formula-Z mobo om precies te zijn.

Bij voorbaat dank :D
Dat klinkt als een mobo met een backup uefi, die zou je dan zo weer kunnen herstellen ja.
Okť top, en thx voor je snelle reactie.
Nou had ik ook al wel zo'n idee dat het op die manier mogelijk was.
Maar ik heb daar nog geen ervaring mee gehad, dus ook mede daarom de vraag.
En aangezien ik vanavond na het avondeten zijn kant opga, kan ik het hem gelijk melden, en het waarschijnlijk ook gelijk voor hem voor elkaar maken.

Dus nogmaals, mijn dank _/-\o_

Edit: Typo

[Reactie gewijzigd door SSDtje op 16 april 2016 14:38]

Uitkomst :
Bij deze kan ik je melden dat het resetten van de UEFI-BIOS inderdaad gelukt is door op de resetknop op het betreffende mobo te drukken, topie dus :)
Haha, dat probleem ken ik.

Eigenlijk zou -i voor elke rm-operatie als root afgedwongen moeten worden. Kun je zelf instellen natuurlijk maar het zou altijd overal een goede maatregel zijn. Dan moet je die ook expliciet overiden als je alle bevestigingen niet wilt, maakt het alweer iets lastiger.
Vooral omdat / en * naast elkaar zitten (iig bij je numpad).
Wat ik altijd doe is rm [bestandsnaam] en dan pas -rf erachter typen.

[Reactie gewijzigd door twicejr op 15 april 2016 13:55]

Dat is sinds een tijdje toegevoegd, maar vroeger was dat niet zo!
Dat is inderdaad 10 jaar geleden toegevoegt(waarbij debian nog een tijd lang --no-preserve-root als default had vanwege 'backwards compatibiliteit' en je dus het commando als rm -rf --preserve-root / moest draaien om je / niet weg te gooien, handig voor in een alias maar gelukkig is het ook in debian de default geworden.
En zoals je in het artikel kunt lezen claimt de beste man een OS te draaien waarin die optie gewoon bestaat.
Dat artikel had gewoon de proef op de som moeten nemen en aantonen dat je op die manier een systeem (potentieel) kan bricken.
Ik zou zeggen -- Ga je gang! Ik ga het niet proberen, heb ik echt het geld niet voor om dat soort experimenten uit te voeren.
heb ik echt het geld niet voor om dat soort experimenten uit te voeren.
Daar heb je echt geen geld voor nodig, alleen een klein beetje tijd. Download een gratis hypervisor, een kant en klare linux image, en je kunt testen..
Het probleem is dat een hypervisor in het algemeen geen UEFI ondersteuning bied, en al helemaal niet de variablen vanaf de host waarmee je potentieel de boel zou kunnen bricken.
Daar heb je echt geen geld voor nodig, alleen een klein beetje tijd. Download een gratis hypervisor, een kant en klare linux image, en je kunt testen..
Het ging om het vernietigen van je UEFI; om het potentieel volledig onbruikbaar maken van het moederbord door middel van rm -rf. Een hypervisor gaat daar niet noodzakelijkerwijs bescherming tegen bieden en is ook geen garantie dat het resultaat zonder tussenkomst van de hypervisor hetzelfde zou zijn.
In principe moet er toch wel weer een manier zijn om een nieuwe uefi er op te zetten als je die stuk hebt gemaakt? Hij is er toch ook voor het eerst een keer op gezet? Of zorgt die gebrickte uefi er voor dat je er ook niet meer in kan?

[Reactie gewijzigd door lololig op 15 april 2016 14:41]

Hangt van het moederbord af. Sommige kan je herstellen, sommige niet.
Wilde net hetzelfde zeggen.. volgensmij is # rm -rf / nog altijd 'schadelijk' voor je gegevens.
Als je bijvoorbeeld op /mnt/share1 iets hebt gemount, worden die bestanden toch ook allemaal verwijderd*.

Ik begrijp het hele verhaal dus niet zo, die 'speciale' toevoegingen maken toch geen verschil?
Hoe ik dit weet? Zelf al een keer gedaan (wel van geleerd :+), en Bumblebee (voor Optimus) heeft dit probleem ook gehad, en daar waren ook gebruikers data kwijt.
Zonder de toevoeging --no-preserve-root wordt tegenwoordig het commando rm -rf / geweigerd ;)
Juist als beveiliging. Let op : dit geld alleen als je / aan geeft, op elke andere map werkt het wel.

[Reactie gewijzigd door hackerhater op 15 april 2016 12:42]

Wil het niet nog een keer proberen.. maar misschien voor de grap nog eens in een VM. ;)
Bedenk mij trouwens dat Bumblebee volgensmij alleen /usr/bin verwijderde, wat dus inderdaad mag. :/

Wat ik altijd 'raar' heb gevonden, is dat het er nooit echt standaard uit het # rm commando validatie is opgenomen voor belangrijke paden als /usr, /bin, /var, .. alleen een externe tool checkt dit. Er is wel safe-rm, maar om weer een extra tool te installeren.. zou gewoon er standaard in moeten zitten.
"with great power comes great responsibility"
Gewoon uitkijken wat je doet als root en niet onnodig als root werken.
Als user krijg je netjes een permission denied op die mappen.

[Reactie gewijzigd door hackerhater op 15 april 2016 15:02]

Mja, heel veilig is dat nog niet. Maak je er, niet geheel ondenkbaar

rm -rf /*

van dan werkt het weer wel zonder --no-preserve-root toe te voegen. Door shell-expansie van * voor het uitvoeren van het commando, dus daar kan rm zelf niet zo veel aan doen maar het is net zo desastreus.
I know, het beschermd puur tegen gevalletjes als :
rm -rf / pad_wat_je_eigenlijk_wilde_wissen
Damn wat is dit slecht.. voor een hostingbedrijf notabene. Die zou toch wel beter moeten weten dat een script eerst op een testomgeving wordt getest of het goed werkt i.p.v productie..
Hij heeft gewoon een zielig verhaal verzonnen om geld bij ekaar te krijgen. Denk maar niet dat ook maar 1 cent naar een dataherstelbedrijf gaat.
Waarschijnlijk.

Ik vrees het ergste voor de klanten, die hopelijk wel een offsite backup hebben in plaats van blindelings op de hoster te vertrouwen.

[Reactie gewijzigd door Baris op 15 april 2016 13:02]

Op iedere hoek van de straat vind je tegenwoordig wel een ondernemertje die zichzelf hostingprovider noemt. Dus dit verbaast me absoluut niet. Hoe meer mensen met een bepaalde professie bezig zijn, hoe meer fouten er gemaakt worden, en dat is dan nog even los van de skills van de bewuste mens.
Verder vind ik het niet echt nieuwswaardig. Denk dat het iedere dag wel ergens gebeurt op de wereld. rm -rf maakt je lui en voor je het weet gebruik je het overal voor. Je moet gewoon bewust blijven van de risicos.
"Het ondernemertje DAT" want ondernemertje is een verkleinwoord dus onzijdig en het woordje "het" was daar ook al een hint voor: het gaat nooit met die. Alstublieft dankuwel.

Er is in dit geval sprake van >1500 sites, dus niet echt heel klein. Inderdaad vreemd dat er nog geen boze klanten zijn opgedoken.

Algemeen: ik zie er ook niet direct een advertorial in (wie zou daar beter van worden? Een verkoper van cloudbackups?). Het kan opzich natuurlijk wel een hoax zijn; de betere hoaxes bevatten wel altijd iets dat op een levensles lijkt.

[Reactie gewijzigd door mae-t.net op 15 april 2016 20:49]

Pffff dankjewel. Nooit meer doe hŤ
Marsala, alias 'bleemboy'
Bleem! was ook pure oplichting, dus misschien is de nickname wel erg goed gekozen.
Waarom was Bleem! pure oplichting? Bij mijn weten hebben ze oprecht geprobeert om een goede PS-emulator neer te zetten, maar zijn ze kapotgeprocedeerd door Sony.

OT: Dit verhaal doet mij denken aan een collega die ooit een bestandje had gemaakt met de naam "~" die hij ook verwijderde met rm -rf ~.
Ik geloof er niks van. Het klinkt als de gemiddelde aandachtstrekker, waar het Internet zo'n gemakkelijk podium voor beidt. Dan wrijft het natuurlijk ook als tech-website of je zo'n bericht juist moet melden of niet.

Ik vind het jammer dat het nodig is om hier een nieuwsartikel aan te wijden, maar ben blij dat het artikel voornamelijk gewijd is aan ontkrachten van de beweringen. Dat verdient namelijk natuurlijk wel gedeeld te worden.
Het is geen nieuwsartikel :) Maar een .geek

[Reactie gewijzigd door henk1994 op 15 april 2016 12:46]

Het is een nieuw artikel met een nieuwtje op een tech-nieuws website. Komt toch redelijk in de buurt van een nieuwsartikel als je het mij vraagt ;)
Is het komkommer-seizoen nu al begonnen? Waarom plaatst Tweakers dit vage verhaal?

Het belang van backups kan ook wel op een betere manier onder de aandacht worden gebracht...

Edit: het is inmiddels duidelijk dat het of fake is, of gewoon een of andere noob waarvan er duizenden zijn. Tijdens de herstelwerkzaamheden heeft de persoon in kwestie ook nog zogenaamd 'of' en 'if' omgewisseld tijdens een 'dd' commando... Yeah, right...

In elk geval niet nieuws- of .geek-waardig.

[Reactie gewijzigd door Herko_ter_Horst op 15 april 2016 12:46]

Het staat ook niet voor niets onder .Geek...
Omdat het nog steeds opmerkelijk technisch nieuws is. Veel andere nieuwssites hebben dit nieuws ook gedeeld.
Ik zou als professionele hostingpartij vooral alle backups enkel lokaal opslaan. Alles + dit verjaal = Jezus, wat een amateur(s).
Hij sloeg het niet lokaal op. Hier staat het duidelijker vermeld;
https://developers.slashd...with-one-line-of-bad-code

Hij had een mount naar een externe (offsite) locatie. Dus kan b.v een CIFs mount zijn naar de backups op een andere PC. Nog steeds niet goed daar niet van, maar anders dan "Lokaal" opslaan ;)
Vreemd tweakers nieuwsbericht. "Dit is waarschijnlijk onzin, maar we posten het toch."

Als dit het nieuwe beleid is wil gerust nog een hoop nieuwe reddit links in de nieuws-suggesties werpen :+

[Reactie gewijzigd door boe2 op 15 april 2016 12:24]

Lekker nieuwswaardig artikel. Heeft iemand van de Redactie al getoetst of dit Łberhaupt echt gebeurd is?

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True