Se Windowsin rekisteri...

[Repe Ruutikallo]

Paljon puhutaan siitä, että Windowsin rekisteri on monien ikävyyksien alku ja juuri. Voisiko joku tietäjä ystävällisesti selvittää, mitä tästä johtuvia käytännön eroja OS X:ssä ja Xp:ssä on ja mitä jokapäiväiseen tietokone-elämäämme vaikuttavia juttuja näistä eroista seuraa?

[MjP2]

Windowsilla oikuttelevista ohjelmista muodostuu helposti tuskaisa riesa, ja niitä saa olla poistamassa un-installerilla (ja siitähän riemu repeää, kun poisto-ohjelma toteaa, ettei poistamista voida tehdä, koska blaa). Lisäksi jaetut resurssit eivät paljoa sano tavalliselle käyttäjälle, mutta Windows olettaa, että käyttäjän tulisi tietää, mitkä noista ovat tarpeellisia.

Vastaavasti, jos käyttis kenkkuaa, myös ohjelmat joutuu asentamaan uusiksi. Itselläni on ainakin yleensä Macilla tapana kopioida toimivat ohjelmat talteen ja asentaa pelkkä käyttis uudestaan, jos ongelmia ilmenee. Windowsilla moinen ei (noin vain?) onnistu.

Voiko Windowsilla muuten ajaa ohjelmaa kaverin koneella vaikka iPodilta ilman, että ohjelmaa asentaa käytettävälle koneelle?

Usein täälläkin mainittu xvsxp.com-sivusto esittelee muistaakseni osuvia rekisteriongelmia.

MjP2

[spiidi78]

Pahin ongelma rekisterissä on se, että se paisuu ja paisuu. Uninstallerit ei poista rekisteristä läheskään kaikkea ohjelmaan liittyvään ja itse ohjelmakaan ei aina suostu lähtemään. Tulee melkoinen urakka poistaa ne manuaalisesti, eikä ilman installer logia ole mitään mahdollisuuksia edes löytää kaikkia rekisteriavaimia.

En ole ihan täysin perillä OSX:n tiedostojärjestelmästä, mut ilmeisesti yksi .APP -tiedosto onkin naamioitu kansio, joka sisältää ohjelman ja yleensä myös sen kaikki tarvitsemat komponentit, joten se näyttää yhdeltä tiedostolta ja sen voi helposti drag'n'dropata yhellä kertaa mihin paikkaan vaan?

[MjP2]

Noin kai se menee, joo. Pakkauksen sisällön saa näkyviin kohdeklikkaamalla ohjelmaa ja valitsemalla aukeavasta valikosta "näytä pakkauksen sisältö".

Tuossa kohtaa Apple muuten rikkoo omia sääntöjään. Kohdevalikkoon ei saisi laittaa mitään, mihin ei ole pääsyä muistakin valikoista, mutta tuo toiminto löytyy ainoastaan kohdevalikosta...

MjP2

[NOx]

Tiedostojärjestelmä on HFS+ (Pantherista alkaen HFS+ Journaled). Ohjelmapakkaukset - Bundlet - eivät liity tiedostojärjestelmään. Mac OS X Application bundle voi sijaita melkein missä tiedostojärjestelmässä tahansa.

http://developer.apple.com/documentatio ... /10000123i

HFS ja sen johdannaiset ovat tiedostojärjestelmänä aivan takapuolesta. Paljon monimutkaisemmin asiaa ei voisi tehdä, siis yksinkertaista levykirjanpitoa. Tässä Windows, NTFS ja FAT32 vievät voiton 6-0. Jopa alkuperäinen FAT ainakin 2-0. Unix File Systemeistä puhumattakaan.

[spiidi78]

Mitäs eroa on Unix File Systemillä ja HFS+ Journaledilla? Olisiko viisaampaa siirtyä UFS:ään kun OSX kerran tukeekin sitä suoraan?

[Repe Ruutikallo]

>HFS ja sen johdannaiset ovat tiedostojärjestelmänä aivan takapuolesta. Paljon monimutkaisemmin asiaa ei voisi tehdä, siis yksinkertaista levykirjanpitoa. Tässä Windows, NTFS ja FAT32 vievät voiton 6-0. Jopa alkuperäinen FAT ainakin 2-0. Unix File Systemeistä puhumattakaan.

Tästä varmaan tulee kommenttia. Mnää en osaa sanoa muuta kuin sen että HFS+ journaled on paras tiedostojärjestelmä johon olen törmännyt, kun sitä on näköjään (lähes?) mahdotonta saada sekoamaan. (Ilman journalointiahan homma onnistuu kohtuullisella vaivalla, mitä Jaguaria muistelen.) FAT32 kuuluu olevan tältä osin vähän toista maata...

[spiidi78]

Juu ainakin FAT ja FAT32 menee sekasin päivänkakkaran helposti. Nimim. kerran kaikki tiedostot paskaks ilman mitään syytä. Sen lisäks FATit fragmentoituu nopeasti 70-80% tienoille, täysin paska järjestelmä sanon ma.

NTFS on fiksuin noista Wintoosan filesystemeistä

[Jamac]

Jostapas luin ettei FAT systeemeissä olisi mitään käyttäjäoikeussysteemiä?

[Elroy]

Tiedostojärjestelmä ei vaikuta käyttäjähallintaan. Tiedostojärjestelmässä VOI olla käyttäjienhallintaa avustavia tai parantavia ominaisuuksia.

Windowsmaailman ongelma on kirjavat kehitysympäristöt ja käyttöjärjestelmän pakottama DLL ja rekisteriympäristö. Eli DLL luokat menevät helposti sekaisin ja niitä on hirveästi eri versioita. Rekisteriin taas työnnetään kaikki viittaukset ja asetukset etc. joita käyttöjärjestelmä ja softat voi käyttää. Rekisterin roskaantuminen ei ole windowsin vika, vaikka se onkin windowsin osa. Ohjelmiston tekijän vastuulla on tehdä ohjelmiston poistosta sellainen, että se todellakin poistaa omat tiedostonsa rikkomatta muuta ympäristöä ja siivoa ne tekemänsä rekisterimerkinnät pois.

Tässä on nyt suotta sekoitettu kahta eri asiaa.

[MjP2]

Oli kenen vika tahansa, nuo ongelmat ovat osa käyttäjän Windows-kokemusta. Sikäli on oikeutettua sanoa, että ne ovat "ongelmia käytettäessä Windowsia", vaikkeivät suoranaisesti "Windowsin ongelmia" olisikaan.

MjP2

[Elroy]

Tottakai on oikeutettua, jokainenhan valitsee mitä käyttää. Rahalla saa ja hevosella pääsee.

[NOx]

Mitäs eroa on Unix File Systemillä ja HFS+ Journaledilla? Olisiko viisaampaa siirtyä UFS:ään kun OSX kerran tukeekin sitä suoraan?

Vastaus erosta toisessa viestissä.

UFS:ää voi käyttää käytännössä vain palvelimissa. Työasemissa hankaluutena ovat mm. etteivät kaikki ohjelmat, etenkään Carbon-pohjaiset, toimi UFS-levyltä. HFS käyttää hakemistoerottimena :-merkkiä, UFS /-merkkiä. Mac OS X hoitaa konversion, mutta suoraan levyä käyttävät ohjelmat voivat olla hämillään. UFS ei tue multifork-tiedostoja, joten Carbonin on simuloitava resource forkit. Jälleen yksi syy miksi olen kovasti sitä mieltä, että koko resource forkeista olisi päästävä eroon kokonaan ja lopullisesti. Koska forkeja ei tueta, voivat etenkin vanhemmat ohjelmat kuolla.

Vaikka OS itse tukeekin UFS:ää, saattaa se UFS-levylle asennettuna olla toivottoman hidas toiminnoissaan vaikka Panther onkin jo parempi. Tietysti jos levyjä on useampia voi niistä työasemassakin jonkin alustaa UFS:ään ja tallentaa dokumentteja tuonne. Mieluiten sellaisia joissa ei ole resource forkeja, melko varmoja esimerkkejä ovat erilaiset kuvatiedostot, html, tekstitiedostot, pdf jne.

[masa]

Jos se resurssihaarukka on huono niin miksipä Apple ei siitä hankkiudu eroon? Ei kai se nyt niin huono asia ole kuin täällä annatte ymmärtää. En ole asiaa hirveesti tutkinut mutta jossain olen asiaan törmännyt.

[NOx]

Tästä varmaan tulee kommenttia. Mnää en osaa sanoa muuta kuin sen että HFS+ journaled on paras tiedostojärjestelmä johon olen törmännyt, kun sitä on näköjään (lähes?) mahdotonta saada sekoamaan

Varmaan tulee kommenttia. En silti aio muuttaa mielipidettäni.

Journaling siis tarkoittaa vikatilanteesta toipumista nojautuen (jälleen kerran uuteen) logiin levytapahtumista. Entäs jos logia ei ole? Kokeile nyppäämällä FireWire-levy lennosta irti. Journaling on erityisen hyödyllinen HFS+ levyillä, mutta kaikki levyjärjestelmät kyllä tukevat sitä. HFS+ levyillä Journalingin merkitys korostuu, koska itse HFS+ on niin onneton:

HFS järjestelmässä kaikki kirjoitetaan kahteen kertaan levylle. Jonkun mielestä tämä on varmaan turvallista. Tosiasiassa näin on pakko tehdä koska tiedostojärjestelmä on muuten niin haavoittuvainen. Yksinkertainen tiedostojärjestelmä olisi yksinkertainen myös korjata. HFS, HFS+ molemmat ovat puumaisia rakenteeltaan. UFS ja DOS:in levyjärjestelmät ovat lineaarisia, siis yksinkertaisia.

Kirjanpito tapahtuu aivan käsittämättömän monimutkaiseksi. Kansanomaisesti selitettynä kun lisätään uusi osoitetieto, kirjoitetaan myös kaikki muut uudelleen. Siis vaikka tämä olisi alkutilanne: 1, 2, 3, 4, 5, 6. Mikä noista on juuri? Se on kolmosen ja nelosen välissä. Lisätään yksi tiedosto: 1, 2, 3, 4, 5, 6, 7. Juuri osuu nyt nelosen kohdalle kirjanpidossa. Mikä tästä on seuraus? Kaikki kirjoitetaan uudelleen, koko kirjanpito eli Binary Tree. Ja tämä tehdään joka ainoa kerta kun tiedosto tallennetaan, poistetaan tai nimetään uudelleen. Juuren pitää olla keskellä, kaikki haut alkavat aina keskeltä HFS-järjestelmässä. Kun tiedosto siirretään kansiosta toiseen, kirjoitetaan sekä lähdekansion ja kohdekansion kirjanpito kokonaan uudelleen. Hidasta kuin mikä ja lisäksi riskialtista. HFS+ mahdollisti isomman tiedostomäärän levyllä ja pienemmän tilanvaraustaulukon, isommat levyt ja isommat tiedostot. Lisäyksenä kirjanpitoon tarvittiin vielä yksi komponentti lisää HFS B-Treen lisäksi, jokainen levyjä Nortonilla tai Applen työkaluilla korjannut on varmasti törmännyt Catalog Fileen (aika usein se on "invalid"). Catalog File sisältää myös levykirjanpidon, taltiotiedot, vapaiden blokien määrän, tiedostojen ja kansioiden määrän jne. Tämä siis Binary Treen lisäksi.

HFS (+) monimutkaisuus ja Journalingin korostunut hyödyllisyys tässä yhteydessä selviää lukemalla sitä käsittelevän Tech Noten http://developer.apple.com/technotes/tn/tn1150.html, samalla aukeaa miksi Nortonista tuli epäluotettava ja miksi levytyökalujen päivitykset ylipäätään ovat kestäneet kauan. HFS+ on nykyiselle levyjärjestelmälle väärä nimi, 10.3 käyttää levyjärjestelmänä HFSX v.5:ttä. Sen päälle on vielä tungettu metadata area ja hotfile b-tree, siis sen toisen b-treen lisäksi. Koko HFS nykyisellään on silkkaa p*skaa ja se on erittäin herkkä vioittumaan.

UFS puolestaan sisältää hakemistoista tietona vain tiedostonimet ja inode-numerot. inodet sisältävät tiedot kaikista levyjärjestelmään tallennetuista tiedostoista. Kun UFS:ään kirjoitetaan, kirjoitetaan tiedostonimi ja inodeen tieto tiedoston sijainnista fyysisesti levyllä. Yhdellä kirjoituskerralla. Ihan tolkuttoman yksinkertaista, toimivaa ja nopeaa. Tarvittaessa voidaan myös käyttää journalingia.

[thebanzai]

No johan tuli tietoutta. Mitenkäs linuxin ext3, reiserFS ja muut? Macciin ei nyt kauheasti liity, mutta...

[spiidi78]

NOx:
Journaling siis tarkoittaa vikatilanteesta toipumista nojautuen (jälleen kerran uuteen) logiin levytapahtumista. Entäs jos logia ei ole? Kokeile nyppäämällä FireWire-levy lennosta irti

Kato perkkele. Tota ihmeteltiinkin USB-muistikamman kanssa kun tuli revittyä irti ilman "ejectiä" -> melkein kaikki data korruptoitunutta.

Kiitos todella hyvästä ja selventävästä tietopaketista!

[NOx]

Jos se resurssihaarukka on huono niin miksipä Apple ei siitä hankkiudu eroon?

Siksi kun Macceja on myyty, ostettu ja käytetty vuodesta 1984. Monet vanhat tiedostot lakkaisivat toimimasta, mukaanlukien tuhannet postarifontit. Classic-ohjelmat eivät toimisi ollenkaan ja niin edelleen. Siirtyminen Mac OS X:ään olisi siis melkoisen tuskallista ellei peräti mahdotonta monelle käyttäjälle.

Resource Fork -tuki voisi silti olla optio. Uusilla ohjelmilla ei ole mitään tarvetta käyttää tai etenkään tallentaa tiedostoihin Resource Forkia, ei ainakaan jos ohjelma noudattaa Applen ohjelmointisuosituksia. Kyse on ainoastaan yhteensopivuudesta alaspäin.

Developer dokumenteista selviää, että Apple tosiaan yrittää päästä irti Resource Forkeista. Vienee aikaa, osin siksi kun käyttäjät ovat niihin tottuneet ja vastustavat ajatusta tiedostopäätteistä. Henk. koht. Windows-ja Unix-verkkoja käyttävänä ja paljon Windows-koneiden käyttäjien kanssa asioivana henkilönä olen päinvastaista mieltä. Resource Fork on yksinomaan piina ja "ylimääräisiä" tiedostoja saa aina selitellä ja poistella.

[NOx]

No johan tuli tietoutta. Mitenkäs linuxin ext3, reiserFS ja muut? Macciin ei nyt kauheasti liity, mutta...

Nämähän ovat kaikki luonteeltaan lineaarisia, siis yksinkertaisia ja enemmän tai vähemmän sukua UFS:lle. ReiserFS sisältää enemmän älykkyyttä ja journalingin, mutta kaukana se on HFS:n monimutkaisuudesta. Reiseria voidaan myös laajentaa plugineilla. Ext3 on kuin ext2, mutta sisältää journalingin. Tehossa noiden välillä ei kai isoja eroja ole kokonaisuutena.

Ihan aluksihan Maciin piti tulla hieman samantapainen levyjärjestelmä kuin (kenties) tuleva WinFS on. Idea oli sotkea kaikki läjään, ei hakemistoja vaan piilotiedostoja joiden perusteella olisi jaoteltu sisältöä. Sittemmin ajatuksesta luovuttiin sekavana. Jos WinFS tulee, on jännittävää nähdä miten se selviää mahdollisista ongelmatilanteista. Tarkemmin ajateltuna, miten käyttäjät selviävät mahdollisista ongelmatilanteista.

[Lakiopaalu]

HFS+ vs. UFS: Taidat olla Tevanianin opetuslapsi, käsittääkseni juuri muut eivät ole tuollaista ehdotelleet.

Lukemista Avie Tevanianista:
http://daringfireball.net/2003/07/the_g ... d_the_avie
ja
http://daringfireball.net/2003/07/finding_avie.

[NOx]

HFS+ vs. UFS: Taidat olla Tevanianin opetuslapsi, käsittääkseni juuri muut eivät ole tuollaista ehdotelleet.

Heittäisit mieluummin jotakin HFS:ää puoltavia argumentteja. Ainoa minkä keksin on yhteensopivuus vanhoihin järjestelmiin.

Jos asiaa tarkastellaan oliko Nextin tiedostojärjestelmä parempi kuin Mac OS X, niin siinä tapauksessa kyllä olen Tevanianin oppilapsi vaikken sitä ole koskaan tiedostanutkaan.

Aika moni on ehdotellut UFS:ää HFS:n sijaan, Tevanianin lisäksi. Alunperin Rhapsody ei edes ymmärtänyt yhtään mitään HFS:stä. WWDC:ssä 1998 oli demo, jossa näytettiin HFS:n mounttaamista käsin. Eipä kyllä ollut tukea Applesharellekaan.

Tilanne on vieläkin sama eikä muuksi muutu. Mac OS X perustuu yli 100:lle Open Source projektille, koko Darwin perustuu enemmän tai vähemmän BSD:lle. Darwin myös asentuu x86-ympäristössä UFS:lle.

Kuinka monen BSD-komennon tiedät suoraan tukevan HFS-nimiä ja hakemistoerottimia? Open Source projektit ovat pääosin peräisin Unix/Linux-ympäristöistä, mitään tukea HFS:lle ei löydy. Niinpä Mac OS X VFS joutuu koko ajan kääntämään viittauksia HFS/UFS-tyylisten viitausten välillä. Perustele miksi tämä on parempi vaihtoehto teknisesti kuin suoraan käyttää UFS:ää tai muuta vastaavaa?

Selvyyden vuoksi: käyttöjärjestelmäni lepää HFS+ Journaled levyllä kun muuta vaihtoehtoa ei oikein ole käyttämieni ohjelmien puitteissa. Varmuuskopiot menevät UFS-levyllä sijaitseville imageille.

[Lakiopaalu]

Jeh, myönnetään, toi oli huono heitto kun en esittänyt parempia argumentteja kuin pari linkkiä.

Koetin etsiä J.Gruberin saitilta niitä artikkeleita, jossa ko. heebo perustelee asiaa, mutten löytänyt. Itse olen enemmänkin rauta-pää (gear-head) kuin koodinvääntäjä; lueskelen koodipuolen artikkeleita satunnaisesti.

Pari hataraa muistikuvaa kuitenkin recource- ja creator-forkeista (korjaa, jos kirjoittelen läpiä päähäni):
Pelkkä tiedostopääte dokumentissa olisi loppukäytäjän kannalta heikompi vaihtoehto. Esim. tuplaklikatessa dokumenttia.
Miten finderin (aik. Sherlock, aik. finder) kyky löytää tiedostoja luontiohjelman mukaan ("Etsi kaikki FreeHand9:llä tehdyt..." etc.)?

Sinänsä mielenkiintoista OSX:n kypsymisen aikana on ollut seurata tietynlaista leiriytymistä: pitkäaikaiset Mac-käyttäjät ("if it aint' broke, don't fix it" ja vastarinta OSX:n myötä tulleisiin muutoksiin) vastaan Unix-ympäristöstä tulleet. Itse kuulun aika pitkälti ensinmainituihin.
Toisaalta, Jonathan Ives ei ole minulle mikään jumala: Modaustyökaluihini kuuluu mm. kulmahiomakone ("otetaan yksi kpl. G4-torneja, perataan se, ja tehdään katolle 80x80mm tuulettimelle rälläkällä aukko, kun isompaa ei ilmankierrollisesti järkevään paikkaan saa sisukalujen sijoittelun takia..." ) eli kuin pahinkin PuuCeen virittelijä...

Lisää luettavaa: http://daringfireball.net/2002/08/unix_switchers

http://www.igeek.com/articles/Interface ... eNames.txt

[NOx]

Pelkkä tiedostopääte dokumentissa olisi loppukäytäjän kannalta heikompi vaihtoehto. Esim. tuplaklikatessa dokumenttia.
Miten finderin (aik. Sherlock, aik. finder) kyky löytää tiedostoja luontiohjelman mukaan ("Etsi kaikki FreeHand9:llä tehdyt..." etc.)?

Tämä on asia jolla voidaan spekuloida varmaan ikuisesti, mikä on loppukäyttäjän kannalta parempi. Poistamalla Resource Forkit menetään Finderin kyky etsiä dokumentteja luontiohjelman mukaan (tosin ei aivan kokonaan, tiedoston päätehän liittää dokumentin johonkin ohjelmaan). Toisaalta samalla poistuvat virheellisesti rekisteröityneiden dokumenttisidosten ongelma. Samalla poistuu myös yhteensopivuus- ja siirrettävyys- ja varmuuskopiointiongelmat ja Mac on helpompi liittää sekaverkkoon.

Itse olen ollut valmis heittämään Resource Forkit mäkeen jota kuinkin vuodesta 1992, jolloin aloin aktiivisesti käyttämään sähköpostia ja BBS-järjestelmiä. Aika monesta on lähtenytkin, kiitos mm. Graphic Converterin.

Resource Forkien heikko kohta käyttömukavuudessakin on ollut tilanne jossa monta ohjelmaa kykenee avaamaan saman dokumentin ja tietysti se sitten aukeaa väärässä ohjelmassa. Tukisivustot ovat aina olleet pullollaan näitä kysymyksiä. Nykytilanteessa vaihtoehtoisia yhdistelmiä dokumentin avaamiseen ovat a) tiedostopääte b) tiedostopääte + resource fork c) resource fork d) resource fork + tiedostopääte e) ei mitään. Siis levyllä viisi .jpg -kuvaa, jotka kaikki aukeavat eri ohjelmalla.

Teoriatasolla Resource Forkit helpottavat käyttöä, mutta jonkin mennessä vikaan onkin käyttäjä usein pulassa. Ongelmaa pahentaa kun "mistään ei ole tarvinnut välittää", kone vaan toimii. Pienestä ongelmasta kasvaa helposti ylittämätön este. No totuuden nimessä on sanottava, että myös nyky-Windows aiheuttaa harmaita hiuksia käyttäjille oletusarvoisesti piilottamalla tiedostopäätteet, joten eipä sielläkään juuri tietoisempia olla.

Modaustyökaluihini kuuluu mm. kulmahiomakone ("otetaan yksi kpl. G4-torneja, perataan se, ja tehdään katolle 80x80mm tuulettimelle rälläkällä aukko, kun isompaa ei ilmankierrollisesti järkevään paikkaan saa sisukalujen sijoittelun takia..." ) eli kuin pahinkin PuuCeen virittelijä...

Heh. Osaatko muuten kertoa miten noi ledivalot ja valokaapelit tarvitsevat virtaa sisään. 12V? Toiveikkaasti ajattelen samojen modaustarvikkeiden kelpaavaan moton kuin tietokoneenkin modaamiseen...

[Lakiopaalu]

Heh. Osaatko muuten kertoa miten noi ledivalot ja valokaapelit tarvitsevat virtaa sisään. 12V? Toiveikkaasti ajattelen samojen modaustarvikkeiden kelpaavaan moton kuin tietokoneenkin modaamiseen...

Duota, duota... en suoralta kädeltä. Voin kyllä heittää läjän PC-modaus-saittien linkkejä, jos tosissasi olet. Sieltä kyllä löytyy. Tiedonkeruuni ja kokemukseni rautapuolelta on keskittynyt enemmänkin maksimaalisen tehon saamiseen mahdollisimman luotettavasta ja hiljaisesta koneesta.
:$ Häpeillen tunnustan pistäneeni aikoinaan yhden ledivaloilla varustetun tuulettimen kiinni, mutta se oli sillä hetkellä siirtämäänsä ilmamäärään nähden hiljaisin vaihtoehto, ja vieläpä muoviosiensa sävyltä lähes yksi yhteen G4 DigiAudion siniharmaaseen väriin.:$

"aint' buildin' no pimpwheels, mon..." enemmänkin olen P.Starkin linjoilla, mitä teolliseen muotoiluun tulee. Arkkitehtuurissa minimalismi on sitten eri juttu... eli syvältä.

[T-LintU]

Nykytilanteessa vaihtoehtoisia yhdistelmiä dokumentin avaamiseen ovat a) tiedostopääte b) tiedostopääte + resource fork c) resource fork d) resource fork + tiedostopääte e) ei mitään.

Entäs *nix tyylinen file-komennon käyttö?