natgillin/translations-raw huggingface dataset:
Open Source file systems are less prone to data loss than proprietary systems: Wrong, NTFS is rather a tiny notch better than ext3, ReiserFs, JFS, XFS, to name just the most popular file systems that often come as default FS with distributions. A brilliant article about it is here: link
Avatud lähtekoodiga failisüsteemid on andmekao osas veakindlamad kui kommertssüsteemid: väär. Pigem on NTFS isegi vedi parem kui ext3, ReiserFS, JFS või XFS, kui nimetada kõigest levimumaid failisüsteeme, mida pakuvad vaikimisi enamik distributsioone. Selle kohta on väga hea artikkel siin.
Journaling files systems prevent data corruption/ loss: Wrong, they only speed up the scan process in case of a sudden interrupt during operation and prevent ambiguous states. But if a file was not entirely saved before the mishap, it'll be lost.
Kirjendavad failisüsteemid väldivad andmete riknemist ja kadu: väär. Need ainult kiirendavad skaneerimist operatsioonide äkilise katkestuse korral ja väldivad mitmetitõlgendavate olekute tekkimist. Aga kui fail ei ole enne probleemi tekkimist täielikult salvestatud, läheb ta ikkagi kaotsi.
RAID systems prevent data corruption/ loss: Mostly wrong, RAID0 and 1 prevent you from nothing, RAID5 can prevent data loss due to disk-failures (but not from disk or file system errors). Many low-end RAID controllers (most mother board controllers are) don ’ t report problems, figuring you’ ll never notice. If you do notice, months later, what is the chance that you ’ ll know it was the controller’ s fault? One insidious problem is corruption of RAID 5 parity data. It is pretty simple to check a file by reading it and matching the metadata. Checking parity data is much more difficult, so you typically won ’ t see parity errors until a rebuild. Then, of course, it is too late.
RAID- süsteem väldib andmete riknemist ja kadu: enamasti väär. RAID0 ja RAID1 ei väldi midagi, RAID5 võib vältida andmekadu, mida põhjustavad kettavead, aga see ei väldi kuidagi ketta enda riknemist ega failisüsteemi vigu. Enamik lihtsamaid RAID- i kontrollereid (sellised on enamik emaplaadi kontrollereid) ei anna probleemidest teada, nii et sa ei märkagi neid. Ja kui lõpuks mitu kuud hiljem märkadki, siis ei saa sa kuidagi kindel olla, et tegemist on kontrolleri veaga. Tõsine probleem on RAID5 paarsusandmete riknemine. Faili on suhteliselt lihtne kontrollida seda lugedes ja metaandmeid sobitades, aga paarsusandmete kontroll on palju keerukam, mistõttu neid vigu ei näe tavaliselt enne ümberehitamist. Ja siis on mõistagi juba hilja.
Viruses are the biggest thread to digital data: Wrong. Theft, and human errors are the primary cause of data loss.
Viirused on digiandmete suurim oht: väär. Peamised andmekao põhjused on vargus ja inimlikud vead.
Make your budget: Data size, required storage volume estimation
Arvepidamine: andmete suurus, vajaliku andmemahu hindamine
Digital camera sensors are 1-2 aperture stops away from fundamental physical limitations. What I mean is this: as technology evolves, there is a natural limit to its progress. Sensitivity and noise characteristics for any kind of light sensor are not far from that limit.
Digikaamera sensorid on jõudnud peaaegu füüsika poolt ettemääratud piirideni. Ma mõtlen sellega, et kuigi tehnoloogia areneb, on arengul oma loomulikud piirid. Mis tahes valgussensori tundlikkuse ja müra parameetrid on juba väga piiri lähedal.
Today's cameras tend towards 10 mega pixels sensors, although this resolution is already too high for compact cameras and deteriorates the end result. Given the sensor size and quality of optics, 6 mega pixels are optimum for compact cameras. Even DSLR cameras run into their limits at 10-12 mega pixels, for higher resolutions one has to go for full frame sensors (24x36mm) or even bigger formats.
Tänapäeva kaamerad kipuvad ulatuma 10 megapiksliste sensoriteni, ehkki see erandusvõime on kompaktkaameratele juba liiga suur ja tegelikult halvendab lõpptulemust. Arvestades sensori suurust ja optika kvaliteeti, on kompaktkaameratele optimaalne 6 megapikslit. Isegi digipeegelkaaremad jõuavad piirini 10- 12 megapiksli kandis, sest suurema eraldusvõime korral peab kasutama täiskaadersensoreid (24x36 mm) või veelgi suuremaid.
So, taking into account the manufacturer mega pixel propaganda it seems save to say that the bulk of future cameras will see less than 20 mega pixels. This gives us an estimation for the necessary storage space per photograph in the long run: & lt; 15 MB per image. Even if file versioning will be introduced (grouping of variations of a photograph under one file reference), the trend is to implement scripting of changes so that a small overhead will be recorded only and not a whole different image per version. With faster hardware this concept will see it's maturity quite soon.
Kui pidada silmas tootjate megapikslipropagandat, on päris usutav, et tulevased kaamerad on juba vähemalt 20 megapikslised. See võimaldab hinnata fotole vajalikku salvestusmahtu: & lt; 15 MB pildi kohta. Isegi kui kasutusele võetakse failiversioonid (fotovariantide koondamine ühe faili alla), valitseb suundumus teostada muudatusi nii, et salvestatakse ainult variantide muudatused, mitte aga iga variant eraldi pildina. Kiirema riistvara ilmudes saab see peagi teoks.
In order to estimate the amount of storage space you have to plan for, simply determine the number of photographs you take per year (easy with & digikam; 's timeline sidebar) and multiply it by 15 MB. Most users will keep less than 2000 pictures per year which requires less than 30 GB/ year. Assuming that you will change your hard disk (or whatever media in the future) every 4-5 years, the natural increase in storage capacity will suffice to keep you afloat.
Vajaliku salvestusruumi hindamiseks tuleb näiteks lihtsalt võtta aluseks fotode arv, mida aastas teed (seda võimaldab väga hõlpsasti & digikam; i ajatelg) ja korrutada see 15 MB- ga. Enamik kasutajaid teeb aastas alla 2000 pildi, mis tähendab mahtu alla 30 GB aasta kohta. Eeldades, et vahetad kõvaketast (või millist tahes tulevast andmekandjat) iga 4- 5 aasta järel, piisab ka loomulikust mahu suurenemisest sinu vajaduste rahuldamiseks.
The more ambitious ones out there will need more space, much more maybe. Think of buying a file server, Giga-Ethernet comes integrated into motherboards today and it's a flick to fetch the files over the local network. Speaking about modern mobos: they now have external SATA connectors. This makes it really a trifle to buy an external SATA drive and hook it up to your machine. 1000 GB drives will hit the market this year (2008). These are terrific compact storage containers for backup swapping: keep one drive at home and one somewhere else.
Pretensioonikamad vajavad muidugi ruumi rohkem võib- olla isegi palju rohkem. Siis tasuks mõelda juba failiserverile. Giga- Ethernet on tänapäeval juba emaplaadil ning failide liigutamine üle kohtvõrgu võtab vaid hetke. Veel tänastest emaplaatidest: enamasti on neil välised SATA konnektorid. See lubab ka osta välise SATA- ketta ja ühendada selle masinaga. Juba käesoleval (2008.) aastal jõuavad turule 1000 GB kettad. Need on varundamise mõttes väga käepärased: hoia näiteks üht kodus ja teist kuskil mujal, et andmed ikka kindlapeale alles jääksid.
Back it up, backup, backup, recover!
Varundamine, varundamine, varundamine ja taastamine!
A 750GB HD costs & euro; 100 today. Do not blame anybody else for data loss! 6% of all PCs will suffer an episode of data loss in any given year. Backup your data often according to a plan, and back it up and test the backup before you do anything dramatic like re-installing your OS, changing disks, resizing partitions and so on.
750 GB kõvaketas maksab täna & euro; 100. Nii et pole kedagi teist süüdistada andmekaos. 6% kõigist arvutitest elab aastas üle andmekao. Varunda oma andmeid sageli, kindla aja järel ning võta varundamine ette ja kontrolli varukoopiat alati, enne kui teed midagi suuremat, näiteks paigaldad uue operatsioonisüsteemi või uuendad vana uuele versioonile, vahetad kettaid, muudad partitsioonide suurust jne.
Disaster prevention
Katastroofi vältimine
Say, you religiously do your backups every day on a external SATA drive. Then comes the day where lightning strikes. Happy you if the external drive was not connected at that moment!
Oletame siis, et varundad kirglikult iga päev välisele SATA- kettale. Aga siis saabub päev, kui sind tabab äike. Sul veab, kui väline ketas ei ole sel hetkel ühendatud!
Disasters strike locally and destroy a lot. Forget about airplane crashes: fire, water, electricity, kids and theft are dangerous enough to our data. They usually cover a whole room or house.
Katastroofid juhtuvad lokaalselt ja nad teevad suurt hävitustööd. Ära mõtle lennuõnnetustele: tulekahju, vesi, lapsed ja vargused on sinu andmetele palju ohtlikumad. Kõik need mõjutavad enamasti kogu tuba või isegi maja.
Therefore disaster control means de-localized storage. Move your backups upstairs, next house, to your bureau (and vise versa), whatever.
Seepärast tähendab katastroofi vältimine salvestamise hajutamist. Vii oma varukoopiad pööningule, naabermajja, töökohta või kuhu tahes mujale.
There is another good aspect to the physical separation: as said above, panic is often the cause of destroying data, even the backup data. Having a backup not at hand right away may safe your ass one day.
Füüsilisel hajutamisel on veel üks hea külg: nagu eespool öeldud, on andmete, isegi varundatud andmete kao sage põhjus paanika. Kui sul pole varukoopiat kohe käepärast, võib paanikahoog vaibuda ja sa suudad mõistlikult talitada.
Some backup technicalities explained for laymen.
Mõningad varundamise üksikasjad võhikutele.
Full Backup: A complete backup of all the files being backed up. It is a snapshot without history, it represents a full copy at one point in time.
Täielik varundamine: kõigist failidest täieliku varukoopia tegemine. See on hetkvõte ilma ajaloota, kajastades just antud hetke seisu.
Differential Backup: A backup of only the files that have changed since the last full backup. Constitutes a full snapshot of two points in time: the full backup and the last differential one.
Diferentsvarundamine: ainult neist failidest varukoopia tegemine, mida on muudetud pärast viimast täielikku varundamist. See on hetkvõte kahest ajapunktist: täieliku varundamise ja viimase muutvarundamise hetkest.
Incremental Backup: A backup of only the files that have changed since last whatever backup. Constitutes multiple snapshots. You can recreate the original state at any point in time such a backup was made. This comes closest to a versioning system except that it is only sampled and not continuous.
Muutvarundamine: ainult neist failidest varukoopia tegemine, mis on muutunud pärast mis tahes varasemat varundamist. See esindab mitut hetkvõtet. Sul on võimalik taastada algne olek mis tahes varasema varundamise hetkel. See on päris lähedal versioonisüsteemile, ainult et siin on tegemist siiski teatud valimiga, mitte järjepideva arenguga.
Best practice: The IT-layman's backup cookbook
Parim käitumine: IT- võhiku varundamise tark- mees- taskus
do a full backup in a external storage device.
tee varukoopia välisele salvestusseadmele.
verify its data integrity and put it away (disaster control)
kontrolli andmete terviklikkus ja paiguta varukoopia kuhugi eemale (katastroofi vältimine).
have another storage device for frequent backups
hangi teine salvestusseade sagedaste varukoopiate tegemiseks.
swap the devices every other month after having verified data integrity
vaheta seadmeid iga paari kuu järel, olles eelnevalt kontrollinud andmete terviklikkust.
A useful rsync recipe to backups
Kasulik rsynci varundamise retsept
Rsync is a wonderful little utility that's amazingly easy to set up on your machines. Rather than have a scripted FTP session, or some other form of file transfer script - rsync copies only the differences of files that have actually changed, compressed and through ssh if you want to for security. That's a mouthful.
Rsync on imeline pisike programm, mida on äärmiselt lihtne oma kasuks tööle panna. Selle asemel et luua skriptiga FTP- seanss või mõni muulaadne failide edastamise skript, kopeerib rsync ainult tegelikult muudetud failide erinevused tihendatult ja kui soovid turvalisust, siis ka üle SSH. See on väga võimas!
A reasonable backup approach for images could be this one:
Mõistlik piltide varundamisstrateegia võiks olla selline:
backup important images right away (after dumping them to a computer) to DVD/ optical media
varunda tähtsad pildid otsekohe, pärast arvutisse laadimist. DVD- le või optilisele andmekandjale.
do daily incremental backup of the work space
tee tööruumist iga päev muutvarukoopia.
do a weekly differential backup and delete integral backups of week-2 (two weeks ago)
tee kord nädalas diferentsvarukoopia ja hävita üle- eelmise nädala varukoopia.
do a monthly differential backup and delete backup of month-2
tee iga kuu diferentsvarukoopia ja kustuta üle- eelmise kuu varukoopia.
if not physically separated already, separate it now (swapping-in another backup drive)
kui varukoopiad ei asu juba eraldi kohas, tee seda kohe nüüd (paiguta nad teisele varukoopiakettale).
This protocol tries to leave you enough time to spot losses and to recover fully at the same time keeping the backup volume at & lt; 130% of the working space. You end up with a daily version of the last 7-14 days, a weekly snapshot for at least one month, and a snapshot of every month. Any more thinning should be done by hand after a full verification.
See retsept jätab piisavalt aega kadusid tähele panna ja neid täielikult taastada, milleks om vaja hoida varundamismahu & lt; 130% tööruumi mahust. Tulemusena on sul igapäevased varukoopiad viimasest 7- 14 päevast, iganädalane varukoopia vähemalt ühe kuu kohta ja iga kuu varukoopia. Pärast varukoopiate täielikku kontrollimist saad muidugi salvestatavate andmete mahtu veelgi vähendada.
script to follow.... TBD
järgneb skript... (veel tegemata)
For German speaking *nix users: link
Saksakeelsetele UNIX- i kasutajatele: link.
Themes: metadata, IPTC stored in image files, XMP files associated, keep the originals, storage, scalability, media, retrieval of images and metadata, copying image data over to the next generation of media, applications, operating systems, virtualization, viewing device... use of the www.
Teemad: metaandmed, pildifailidesse salvestatud IPTC, failiga seonduv XMP, originaali alleshoidmine, salvestamine, skaleerimine, andmekandjad, piltide ja metaandmete hankimine, pildiandmete kopeerimine uue põlvkonna andmekandjale, rakendused, operatsioonisüsteemid, virtualiseerimine, vaateseadmed... veebi kasutamine.
In order for your valuable images to survive the next 40 years or so (because that's about the time that you will become really interested to revisit those nice old photographs of you as a child, adolescent & etc;) there are two strategies to be observed:
Et sinu väärtuslikud pildid säiliksid järgnevad 40 aastat (see on just see aeg, mil sa hakkad tundma suurt huvi vanade fotode vastu, kus oled lapse või teismelisena), tuleb silmas pidada kahte asja:
Keep up with technology, do n't lag behind more than a couple of years.
Hoia tehnikaga sammu, ära ole maas enam kui aasta- paar.
Save your photos in an open, non-proprietary standard.
Salvesta fotod avatud standardeid kasutades.
How to keep up with technology?
Kuidas hoida sammu tehnikaga?
As the future is unforeseeable by nature, everything said today is to be taken with caution, and to be reviewed as we advance. Unfortunately there is no shortcut possible to some basic vigilance. Every 5-8 years at least one should ask oneself the question of backwards compatibility of current systems. The less variants we used in the past the less questions are to be answered in the future.
Kuna tulevik on juba olemuselt ennustamatu, siis tuleb kõike, mida öeldakse täna, võtta teatud ettevaatusega ning kohaneda, kui tulevik peaks olema teistsugune. Vähemalt iga 5- 8 aasta järel tuleks tõsiselt mõelda parajasti kasutatava süsteemi tagasiühilduvuse peale. Mida vähem variante oleme kasutanud minevikus, seda vähematele küsimustele peame vastama tulevikus.
Of course every time you change your computer system (machine, operating system, applications, DRM) you have to ask yourself the same questions. Today, if you want to switch to Windows Vista, you have to ask yourself three times if you still can import your pictures, and, more important so, if you are ever able to move them onto some other system or machine. Chances are good that you cannot. I see many people struggling around me, because Vista enforces a strict DRM regime. How can you proof to Vista that you are actually the owner of your pictures copyright?
Loomulikult tuleb samu küsimusi esitada endale ka siis, kui vahetad välja arvutisüsteemi (masina, operatsioonisüsteemi, rakendused, DRM- i). Kui soovid näiteks täna lülituda Windows Vistale, tuleks enda käest kolm korda küsida, kas saad ikka importida oma pilte ja mis veel olulisem, kas saad hiljem neid liigutada mõnda muusse süsteemi või masinasse. Päris usutav, et ei saa. Ma näen enda ümber paljusid inimesi, kes on selle pärast mures, sest Vista kehtestab väga range DRM- süsteemi. Kuidas tõestada Vistale, et piltide autoriõigus kuulub tõepoolest sinule?
Basically the questions should be answered along the line explained in this document: use and change to open standards supported by a manifold of applications.
Põhimõtteliselt saab sellele ja teistele küsimustele vastata samaga, mida me oleme juba eelnevalt toonitanud: kasuta või võta kasutusele avatud standardid, mida toetavad väga paljud rakendused.
Virtualization becomes available now for everybody. So if you have an old system that is important for reading your images, keep it, install it as a virtual machine for later.
Virutaliseerimine on praegu juba kõigile kättesaadav. Kui sul on mõni vana süsteem, mis on piltide lugemiseks hädavajalik, siis hoia see alles ja paigalda virtuaalmasinana.
Otherwise the advice is quite simple: every time you change your computer architecture, your storage and backup technology, your file format, check it out, go through your library and convert to a newer standard if necessary. And keep to open standards.
Muidu on soovitus väga lihtne; alati, kui muudad arvutiarhitektuuri, salvestamise ja varundamise tehnoloogiat või failivorminguid, uuri neid lähemalt, kontrolli neid ja kui vaja, teisenda uuemale standardile. Ja veel kord: püsi avatud standardite juures.
Scalability
Skaleeritavus
Scalability is the tech-geek expression of the (easy) capability of a system to be resized, which always means up-sized.
Skaleeritavus on tehniline mõiste, mis tähendab süsteemi suuruse (lihtsa) muutmise võimalust - tegelikkuses alati selle suurendamist.
EMVS / LVM Todo
EMVS / LVM (veel tegemata)
Lets assume you planned for scalability and dedicated the container you want to increase to a separate disk or partition. On *nix systems like & Linux; you then can copy and resize the container to the new disk:
Oletame, et mõtled skaleeritavuse peale ja oled välja valinud millegi, mille soovid muuta omaette kettaks või partitsiooniks. UNIX- i süsteemides, näiteks & Linux; is, võid siis väljavalitu kopeerida uuele kettale:
Check with dmesg if your new disk is recognized by the system, but do n't mount it.
Kontrolli käsuga dmesg, kas süsteem tunneb uue ketta ära, aga ära seda ühenda.
& dollar; dd if=/ dev/ sdb[#] of=/ dev/ sdc # source is / dev/ sdb, new disk is / dev/ sdc & dollar; parted resize / dev/ sdc1 0 & lt; disk size in MBgt; # works on ext2,3, fat16, 32 and reiserfs & dollar; resize2fs / dev/ sadc1 #resize_reiserfs in case
& dollar; dd if=/ dev/ sdb [#] of=/ dev/ sdc # allikas on / dev/ sdb, uus ketas on / dev/ sdc & dollar; parted resize / dev/ sdc1 0 & lt; ketta suurus MB- desgt; # toimib ext2, 3, fat16, 32 ja reiserfs' i korral & dollar; resize2fs / dev/ sadc1 # resize_ reiserfs antud juhul
Todo
(Veel tegemata)
Use open, non-proprietary standards as file formats
Avatud standardeid järgivate failivormingute kasutamine
The short history of the digital era in the past 20 years has proven over and over again that proprietary formats are not the way to go when you want your data to be intelligible 10 years into the future. Microsoft is certainly the well known culprit of that sort because of its domineering market share. But other companies are actually (if inadvertently) worse since they may not stay long enough in the market at all or have a small user/ contributor base only. In the case of Microsoft one has at least the advantage of many people sharing the same problems. Finding a solution has therefore much more success. Still, in some cases Microsoft is using Open Source documentation to understand their own systems, so badly maintained have been their own documentation. Usually with any given MSoffice suite one cannot properly read a document created with the same application two major versions earlier.
Viimase paarikümne digiajalugu on korduvalt näidanud, et kommertsvormingud ei ole lahendus, kui soovid, et sinu andmed oleks mõistetavad ka kümne aasta pärast. Microsoft on selles vallas üks tuntumaid süüdlasi, sest tema turuosa on nii võimas. Kuid mõnedki teised firmad on vahest hullemadki (ehkki pole nii palju meedikajastust saanud), sest nad ei pruugi üldse kuigi kaua turul püsida või on neil üpris väike kasutajate- abiliste baas. Microsofti puhul on hea vähemalt see, et sama probleem tabab paljusid inimesi. Seepärast on ka lahenduse leidmine tavaliselt edukam. Siiski kasutab ka Microsoft mõnel juhul omaendagi süsteemi mõistmiseks avatud lähekoodiga dokumentatsiooni, sest ta enda dokumentatsioon on sedavõrd kehv. Tavaliselt ei ole näiteks suvalise MS Office' i versiooniga võimalik lugeda juba kaks versiooni varasema variandiga loodud dokumente.
Image formats have had a longer live time than office documents and are a bit less affected by obsolescence.
Pildivormingud on pikema elueaga kui kontoridokumendid ja iganemine puudutab neid veidi vähem.
Open Source standards have the huge advantage of having an open specification. Even if one day in the future there'll be no software to read it anymore, one can recreate such software, a task becoming simpler every year.
Avatud lähtekoodiga standardite suureks eeliseks on avatud spetsifikatsioon. Isegi kui tulevikus ei ole tarkvara, mis suudaks seda lugeda, on võimalik see päris lihtsalt luua.
JPEG has been around for a while now, and whilst it's a lossy format losing a bit every time you make a modification and save it, it is ubiquitous, supports JFIF, EXIF, IPTC and XMP metadata, has good compression ratios and can be read by all imaging software. Because of its metadata limitation, lossy nature, absence of transparency and 8 bit color channel depth, we do not recommend it. JPEG2000 is better, can be employed lossless, but lacks in user base.
JPEG on levinud juba pikemat aega ja ehkki see on kadudega vorming, mis tähendab, et iga muutuse ja salvestamisega kaotab ta veidi, on see kõikjal levinud, toetab JFIF- i, EXIF- i, IPTC ja XMP metaandmeid, on korraliku tihendusmääraga ja seda suudab lugeda peaaegu iga pilditarkvara. Metaandmete piirangu, kadude, läbipaistvuse puudumise ja 8- bitiste värvikanalite sügavuse tõttu ei ole see siiski soovitatav. JPEG2000 on parem ja võib olla ka kadudeta, aga selle kasutajabaas on väga pisike.
GIF is a proprietary. patented format and slowly disappearing from the market. Do n't use it.
GIF on kommertslik ja patenteeritud vorming, mis tasapisi kaob turult. Seda ei ole mõtet kasutada.