Inside 10.7 - Mac OS X Lion

[heilei]

Annan nyt edes yksi kunnon esimerkki missä relaatiotietokantapohjainen ei tule kysymykseen?

Se, että minulla on 3 ulkoista kovalevyä, koska tiedostot eivät mahdu yhdellekään ja että niissä on samoja tiedostoja (backupeja) taitaa jo kumota koko ajatusmallin + se, että käytän niitä tiedostoja 3 eri paikassa. Mitäs jos yksi kovalevy hajoaa? Menee koko tietokanta uusiksi, jos se kerran pitää olla piilossa käyttäjältä. Mistä tiedän mitä tietoa katosi, kun kerran kaikki on piilossa? Mukavaa, kun häviää puolet koodausprojektista sen kovalevyn mukana, koska en itse saanut määritellä loppupeleissä sen sijaintia. Miksi ollaan vielä 1980-luvulla? Siksi, että tämän hetkinen on ylivoimaisesti toimivin malli. Kukaan täysjärkinen ei luota monimutkaisiin tietokantoihin, koska ne hajoaa ennemmin tai myöhemmin omaan monimutkaisuuteensa + ne on raskaita verrattuna tämänhetkiseen tiedostojärjestelmään + HANKALA YLLÄPITÄÄ "Works on paper" on pikkasen eri asia, kuin reaalimaailma.
...

20 vuotta ja risat aineistonhallinnasta leipänsä saaneena allekirjoitan tuon ylläolevan täysin (mun kohdalla puhutaan siis järjestelmistä, joissa tiedostojen/dokumenttien lukumäärät lasketaan miljoonissa).

Siinä, että ikävät tekniset asiat piilotetaan siltä loppukäyttäjältä parin kerroksen taakse, ei ole mitään pahaa; se on päinvastoin suositeltavaa. Heti kun ne kerrokset puretaan auki, ollaan juuri noiden ym. ongelmien ja haasteiden edessä (vikatilanteet, backupit, hajautus jne.). Teollisuuden isot DAM/CMS-järjestelmät ja niiden haasteet eivät loppujen lopuksi ole enää niin kovin kaukana nykykäyttäjän tilanteesta, nyt kun meillä kaikilla on levyt täynnä digitauhkaa, ja lisää tunkee joka tuutista.

[honpsu]

Annan nyt edes yksi kunnon esimerkki missä relaatiotietokantapohjainen ei tule kysymykseen?

Se, että minulla on 3 ulkoista kovalevyä, koska tiedostot eivät mahdu yhdellekään ja että niissä on samoja tiedostoja (backupeja) taitaa jo kumota koko ajatusmallin + se, että käytän niitä tiedostoja 3 eri paikassa. Mitäs jos yksi kovalevy hajoaa? Menee koko tietokanta uusiksi, jos se kerran pitää olla piilossa käyttäjältä. Mistä tiedän mitä tietoa katosi, kun kerran kaikki on piilossa?

Ei ole erilaisia formaatteja, on vain tietue "kuva", ja metadatana sen sisältämä raakadata, ilmoitus siitä mikä on pakkausalgoritmi, ja jokainen ohjelma voi sitten kirjoittaa omat metadatansa kuvan yhteyteen

Ja performance on mikä sitten, kun dataa alkaa olemaan miljoona key-value -pairia eri ohjelmien lisääminä? Works on paper...not in real life. Nyt on vain jono bittejä, joiden lukemisesta vastaa itse ohjelma, ei tiedostojärjestelmä -> tiedostojärjestelmä ei kuormitu käytännössä juuri ollenkaan.
Kuulostaa taas siltä, että on koodattu web-sivuja, eikä mitään low leveliä ikinä

Käsittääkseni nykyiselläänkin pyydät kyllä käyttöjärjestelmältä luvan avata ja käyttää tiedostoa, ja käyttöjärjestelmä sitten toimii yhdessä tiedostojärjestelmän tietokannan kanssa missä se data levyllä sijaitseekaan. Ei se lowlevel tule muuttumaan mihinkään - samalla tavalla sitä dataa sektoreina/soluina tallennetaan tulevaisuudessakin, mutta datan identifioijana ei tule olemaan /Users/Documents/untitled1.doc vaan esim ID_23039240234, ja sitten relaatiotietokannasta löytyy metatiedot.

Jos yksi kovalevy hajoaa, ilmoittaa tietokanta ettei kuvien X,Y,Z dataa löydy joiden pitäisi sijaita LevylläX. Metatiedot ja riippuvuudet löytyy tietokannasta toki vieläkin. Mitä tapahtuu jos tietokantalevy hajoaa? No aivan samalla tavalla kuin käy nykyään järjestelmälevynkin kanssa, eli tiedot katooa ellei ne ole varmennettu toisaalle. Jos on useampi kovalevy, kyseinen kovalevy sisältää tietokannan toki tiedostoista jotka sijaitsevat ko. levyillä.

Miten hallita datan fyysista sijaintia tietokannassa? Toki jokaisella dokumentilla, kuvalla, etc. on määre millä levyllä data sijaitsee ja mahdollisesti halutaan sijaitsevan, ja esim varmuuskopiointiperiaatteista, tai ylipäänsä periaatteista miten tiedostoja säilötään (esim. kaikki kuvatiedostot säilötään/siirretään ulkoiselle kovalevylle X). Yksinkertaista! Kopiointi muistitikulle toimii aivan siirtämällä kopio koneen tietokannasta muistitikun tietokantaan, metatiedoissa säilyy kopioinnin päivämäärä ja mahdolliset muutokset.

TimeMachinen käynnistämällä näet vanhat versiot dokumenteista jotka ovat varmuuskopioituna varmuuskopioinnille annettujen periaatteiden mukaisesti.

Normikäyttäjän valokuvat, dokumentit, sähköpostit yms. eivät sen kummemmin kuormita. Ammattivalokuuvajan/videokuvaajan teratavujen datamäärät vaativat korkeaa IO:ta (joka ei tule mihinkään muuttumaan, samat algoritmit siellä lowlevel-tasolla raakadataa siirtävät, vain ylemmäntason käsittely muuttuu), mutta eivät hakemistorakennetta tule tarvitsemaan. Jos puhutaan nyt jostain serveri-tason ratkaisuista, joissa jokainen mikrosekunti merkitsee ollaan aivan väärällä keskustelufoorumilla.

Jo pelkästään spotlightin indeksointi kertoo kuinka auttamattomasti itse tiedostojärjestelmä kykenee nykypäivän vaatimuksista suoriutumaan.

[spiidi78]

Käsittääkseni nykyiselläänkin pyydät kyllä käyttöjärjestelmältä luvan avata ja käyttää tiedostoa, ja käyttöjärjestelmä sitten toimii yhdessä tiedostojärjestelmän tietokannan kanssa missä se data levyllä sijaitseekaan. Ei se lowlevel tule muuttumaan mihinkään - samalla tavalla sitä dataa sektoreina/soluina tallennetaan tulevaisuudessakin, mutta datan identifioijana ei tule olemaan /Users/Documents/untitled1.doc vaan esim ID_23039240234, ja sitten relaatiotietokannasta löytyy metatiedot

Heh. Itseasiassa tiedoston määre ei ole /polku/tiedosto.doc vaan indeksi tiedostojärjestelmän tietokannassa. Spotlight on sitten se linkitys tiedoston metadataan. Käytännössä lisäapua uudesta tiedostojärjestelemästä ei siis ole.

Jos yksi kovalevy hajoaa, ilmoittaa tietokanta ettei kuvien X,Y,Z dataa löydy joiden pitäisi sijaita LevylläX. Metatiedot ja riippuvuudet löytyy tietokannasta toki vieläkin. Mitä tapahtuu jos tietokantalevy hajoaa? No aivan samalla tavalla kuin käy nykyään järjestelmälevynkin kanssa, eli tiedot katooa ellei ne ole varmennettu toisaalle. Jos on useampi kovalevy, kyseinen kovalevy sisältää tietokannan toki tiedostoista jotka sijaitsevat ko. levyillä. Miten hallita datan fyysista sijaintia tietokannassa? Toki jokaisella dokumentilla, kuvalla, etc. on määre millä levyllä data sijaitsee ja mahdollisesti halutaan sijaitsevan, ja esim varmuuskopiointiperiaatteista, tai ylipäänsä periaatteista miten tiedostoja säilötään (esim. kaikki kuvatiedostot säilötään/siirretään ulkoiselle kovalevylle X). Yksinkertaista!

Tämä on ristiriidassa oman ideologiasi kanssa. Tietojahan ei voinut määrittää missä ne fyysisesti sijaitsevat, vai mitä Sitäpaitsi jos kuvia on 10TB, ne eivät mahdu yhdelle levylle. Ei niin yksinkertaista. Jos yksi kovalevy hajoaa, tiedot säilyy muilla levyillä koskemattomina.

Käytännössä ehdotuksesti ei siis eroa millään siitä, mitä tehdään jo tälläkin hetkellä, paitsi että Finderissa tiedosto ja kansiorakennetta ei ole piilotettu käyttäjältä. Ja ettei ohjelmat hyödynnä tuota metadataa vaikka se olisi mahdollista.

Jo pelkästään spotlightin indeksointi kertoo kuinka auttamattomasti itse tiedostojärjestelmä kykenee nykypäivän vaatimuksista suoriutumaan.

You said it! Miksi siis pitää vaihtaa tiedostojärjestelmä, kun se toimii Spotlightin kaltaisen metadatasysteemin kanssa hyvin jo nyt? Sitä ei ole vaan hyödynnetty vielä kunnolla. Tällöin tiedot löytyvät nopeasti, ja silti käyttäjällä on vapaus valita oma tiedostojärejstelmärakenne (tai vaihtoehtoisesti sen voisi Lionissa piilottaa käyttäjältä Finderissä jos haluaa).

[honpsu]

Tämä on ristiriidassa oman ideologiasi kanssa. Tietojahan ei voinut määrittää missä ne fyysisesti sijaitsevat, vai mitä Sitäpaitsi jos kuvia on 10TB, ne eivät mahdu yhdelle levylle. Ei niin yksinkertaista. Jos yksi kovalevy hajoaa, tiedot säilyy muilla levyillä koskemattomina.

Käytännössä ehdotuksesti ei siis eroa millään siitä, mitä tehdään jo tälläkin hetkellä, paitsi että Finderissa tiedosto ja kansiorakennetta ei ole piilotettu käyttäjältä. Ja ettei ohjelmat hyödynnä tuota metadataa vaikka se olisi mahdollista.

Jo pelkästään spotlightin indeksointi kertoo kuinka auttamattomasti itse tiedostojärjestelmä kykenee nykypäivän vaatimuksista suoriutumaan.

You said it! Miksi siis pitää vaihtaa tiedostojärjestelmä, kun se toimii Spotlightin kaltaisen metadatasysteemin kanssa hyvin jo nyt? Sitä ei ole vaan hyödynnetty vielä kunnolla. Tällöin tiedot löytyvät nopeasti, ja silti käyttäjällä on vapaus valita oma tiedostojärejstelmärakenne (tai vaihtoehtoisesti sen voisi Lionissa piilottaa käyttäjältä Finderissä jos haluaa).

Se että fyysinen tallennus tehdään läpinäkyväksi käyttäjälle, ei tarkoita sitä etteikö dataa pystyisi jatkossa hallinnoimaan esim. massalaitteittain niinkuin väitätte. Kyse on vain toteutustavasta, eikä se syö mitään periaatetta.

iPhoto, Spotlight ja Osoitekirja yms. ovat sovelluskohtaisia laajennuksia tiedostojärjestelmän puutteisiin - ja jatkossa ko. ominaisuudet tulevat olemaan tarjolla käyttöjärjestelmätasoisena rajapintana. Toteutetaan pikkuhiljaa uusina ominaisuuksina symbioosissa vahan hakemistopohjaisen tiedostojärjestelmän kanssa. Ja hups, jossainvaiheessa huomataan ettei tietoa enää kukaan tallenna hakemistorakenteeseen vaan tietokantapohjaisesti käyttöjärjstelmän tarjoamalla API:lla. Mistään tämän kummemmasta ei ole kyse, eikä mahdoton toteuttaa koska "Entä jos tila loppuu!?", tai koska "Massamuistilaite rikki / varmuuskopiointi!", tai koska "Liian raskas! Tehoton! Mahdoton toteuttaa! Epävakaa!".

Hyvä esimerkki on esimerkiksi Plex - ennen elokuvat tallennettiin hakemistorakenteeseen, nykyään Plex skannaa massamuistilaitteen lävitse ja lisää elokuvat sekä tv-sarjat kirjastoonsa jonka jälkeen käyttäjän ei tarvitse enää miettiä missä elokuvat sijaitsevat levyllä - epäolennaista. Vaan tämän jälkeen ne löytyvät automaattisesti lajiteltuna sellaisin perustein jotka oikeasti vaikuttavat päätöksentekoomme (esim. Uudet elokuvat - Katsomattomat elokuvat - Katsotut elokuvat, Draamaa, Äksöniä, Piirrettyjä jne...). Elokuvan metadatan perusteella ohjelma hakee internetin tietopalvelusta elokuvan arvostelut, tiedot näyttelijöistä ja ohjaajista, kansi ja muut ehostegrafiikat ja käyttäjien arvostelut. Tulevaisuudessa nämä toiminnot tulevat olemaan käyttöjärjestelmätasoisia.

Tapasi hoitaa edellämainittu Finderilla hakemistorakenteessa on se että sinulla on kansio Elokuvat ja tiedosto "MakedonianViholliset.avi" ja ellet ole sattunut ko. elokuvan arvostelua lukemaan edellisenä päivänä lehdestä ei sinulla ole mitään muuta päätöksentekomahdollisuutta kuin avata tiedosto ohjelmassa X tarkastaakseni onko kyseessä edes elokuva, lasten piirretty vai eroottispainotteinen kotivideo. Joten mitä ihmettä me sillä Finderilla edes teemme? Selaamme .eml päätteisiä sähköposteja, tai yritämme etsiä hakemistorakenteesta Kauko Röyhkän osoitekorttia soittaaksemme oikeaan puhelinnumeroon etsimällä FaceTime.app sovelluksen /Users/Applications hakemistosta? Eikun onko se sittenkin /Applications hakemistossa? Mutta minne minä sen osoitekortin tallenninkaan... Ja millä nimellä?

[spiidi78]

iPhoto, Spotlight ja Osoitekirja yms. ovat sovelluskohtaisia laajennuksia tiedostojärjestelmän puutteisiin - ja jatkossa ko. ominaisuudet tulevat olemaan tarjolla käyttöjärjestelmätasoisena rajapintana. Toteutetaan pikkuhiljaa uusina ominaisuuksina symbioosissa vahan hakemistopohjaisen tiedostojärjestelmän kanssa. Ja hups, jossainvaiheessa huomataan ettei tietoa enää kukaan tallenna hakemistorakenteeseen vaan tietokantapohjaisesti käyttöjärjstelmän tarjoamalla API:lla

Sitten kun se API on vielä buginen, niin alkaa taas ongelmat ja käytännössä tiedot on yleensä menetetty kokonaan, tai päädytään virheeseen, jota ei voi enää korjata -> riskit kasvaa aina suuremmiksi mitä monimutkaisemmaksi mennään. Tällä hetkellä se 80-luvun tiedostojärjestelmä ainakin toimii. Sitten KUN iPhoto tai Spotlight räjähtää, niin tiedot on silti tallessa. Ajattelet edelleen ikäänkuin kaikki toimisi aina täydellisesti ja olet valmis uhraamaan kaiken työsi sen takia, että joku uusi juttu on hieno paperilla. Toinen mitä ajattelet on perinteinen tietokoneen-resurssit-on-loppumaton-luonnonvara, eli kaikki on mahdollista, koska koneteho ei lopu kesken, väärin. Kannattaisi tutustua vaikka iPhone tai OS X -koodaamiseen, niin löydät aika paljon asioita, joita mielestäsi edes Apple ei pysty tekemään täydellisesti, ja luottamuksesi kaikkeen täydellisesti toimivaan alkaa pikkuhiljaa romahtamaan. Sitten voidaan jatkaa keskustelua, miksi tuollaista järjestelmää ei edelleenkään ole otettu käyttöön ja toivottavasti ei oteta ihan hetkeen.

Tuli vielä mieleen, mitä sivuvaikutuksia tuo saisi heti aikaan:
- Mitäs tehdään esim tämän hetken kopiosuojauksille, joilla piilotetaan levylle dataa? Tälläisiä ohjelmia ovat esimerkiksi usein sellaiset, joissa on kokeiluaika. API:n kauttahan sitä ei voida piilottaa käytännössä mitenkään, jos käyttäjälle annetaan vapaus vaikuttaa kovalevyn sisältöön millään tavalla. -> ohjelman uudelleenasennus nollaa kokeiluajan.
- Kaikki OS X -ohjelmat tarvitsevat välittömän päivityksen. Moni ohjelma, jota täälläkin olevista ihmisistä käyttää, ei enää välttämättä kehitetä. Ensimmäinen yhteensopivuusongelma onkin jo siinä.
- Edelleen se metadata-ongelma. Et voi väittää, että esim eri kuvankäsittelyohjelmat puhuvat samoilla termeillä asioista ja tulkitsevat ne oikein. Vrt. Aperture Definition, Photoshop Unsharp Mask, Lightroom Clarity, kaikki tekevät suunnilleen samaa muttei kuitenkaan näytä samalta. Algoritmeja on melkein joka ikiselle asialle tehty oma, eikä ole montaa algoritmia, joiden lopputulos on aina sama. Eli metadataa ei voida käytännössä yhdistellä mitenkään ohjelmien välillä, eli joka ohjelma tekee omat datat -> kone menee loppupeleissä jumiin kun etsitään jotain.

Bonus:
- Pelottavaa tämä ajattelumaailma API-sitä-API-tätä. API:t on käytännössä vain apuna toteuttamaan jokin asia nopeasti. Jos se ei miellytä, niin voi aina tehdä oman. Mutta jos kaikki perustuu rajapintoihin, niin silloin käyttäjältä viedään mahdollisuus tehdä se oma. Kantsii muistaa, ettei APIt ratkaise kaikkia asioita. Ne ratkaisee itseasiassa vain todella pienen murto-osan ongelmista. Hyötyä tulee ainoastaan silloin, kun se sopii täydellisesti jonkin ongelman ratkaisuun.

Tossa nyt muutama esimerkki

Ps. Koko tietokanta-ajatus on käytännössä "vähän" isompi versio Windowsin rekisteristä. Kannattaa verrata sitä vaikka ensisijaisesti siihen.

[Macfly]

...ennen elokuvat tallennettiin hakemistorakenteeseen, nykyään Plex skannaa massamuistilaitteen lävitse ja lisää elokuvat sekä tv-sarjat kirjastoonsa jonka jälkeen käyttäjän ei tarvitse enää miettiä missä elokuvat sijaitsevat levyllä - epäolennaista. Vaan tämän jälkeen ne löytyvät automaattisesti lajiteltuna sellaisin perustein jotka oikeasti vaikuttavat päätöksentekoomme

Ko. kädenvääntöön annan myös maallikon näkemyksen. En koe mitään haittaa Finderin kaltaisesta järjestelystä. Vaikka siinä on omat huonot puolensa, niin minä ainakin haluan että jokainen file löytyy oikeasta lokerosta. Vaikka löytäisin saman esim. Aperturen kirjastosta. Jos haluan siirtää useita kokonaisuuksia (useita kansioita sisältöineen) vaikka eri käyttikselle, niin se onnistuu helposti ja tiedän ainakin mitä & mikä versio menee. Voinko olla varma että viiden vuoden päästä käyttämäni ohjelma tai käyttis osaa lukea vanhat tiedostot itselleen oikein; en voi. Vaikka saisinkin kirjastoni siirtymään oikein niin tuskin kaikki tagit, exifit, tähdet, värit ja muut ihanat merkinnät siirtyisivät samalla kertaa.

[F1.4]

Toivottavasti nyt ei törmää samaan ongelmaan mitä oli SL:n kanssa käyttämiini kuvankäsittely ohjelmiin tuli päivitykset vasta puolen vuoden viiveellä siinä vaiheessa tosin oli ehditty jo korjata ohjelma paremmin toimivaksi muutenkin . Apple varmaan otti siitä opiksi kun informoi noin puoli vuotta aikaisemmin milloin ohjelma julkaistaisiin.

[carrbon]

Toivottavasti nyt ei törmää samaan ongelmaan mitä oli SL:n kanssa käyttämiini kuvankäsittely ohjelmiin tuli päivitykset vasta puolen vuoden viiveellä siinä vaiheessa tosin oli ehditty jo korjata ohjelma paremmin toimivaksi muutenkin . Apple varmaan otti siitä opiksi kun informoi noin puoli vuotta aikaisemmin milloin ohjelma julkaistaisiin.

Muistaakseni SL:n tulo kyllä informoitiin myös aika hyvissä ajoin..? Korjatkoon joku jos olen väärässä!

[Pis]

Toivottavasti nyt ei törmää samaan ongelmaan mitä oli SL:n kanssa käyttämiini kuvankäsittely ohjelmiin tuli päivitykset vasta puolen vuoden viiveellä siinä vaiheessa tosin oli ehditty jo korjata ohjelma paremmin toimivaksi muutenkin . Apple varmaan otti siitä opiksi kun informoi noin puoli vuotta aikaisemmin milloin ohjelma julkaistaisiin.

Muistaakseni SL:n tulo kyllä informoitiin myös aika hyvissä ajoin..? Korjatkoon joku jos olen väärässä!

About vuoden verran etukäteen saivat kehittäjät ensimaistiaiset ellen ole käsittänyt aivan väärin. Ja näin kai on ollut tapana muidenkin kissojen kohdalla.

[F1.4]

Toivottavasti nyt ei törmää samaan ongelmaan mitä oli SL:n kanssa käyttämiini kuvankäsittely ohjelmiin tuli päivitykset vasta puolen vuoden viiveellä siinä vaiheessa tosin oli ehditty jo korjata ohjelma paremmin toimivaksi muutenkin . Apple varmaan otti siitä opiksi kun informoi noin puoli vuotta aikaisemmin milloin ohjelma julkaistaisiin.

Muistaakseni SL:n tulo kyllä informoitiin myös aika hyvissä ajoin..? Korjatkoon joku jos olen väärässä!

About vuoden verran etukäteen saivat kehittäjät ensimaistiaiset ellen ole käsittänyt aivan väärin. Ja näin kai on ollut tapana muidenkin kissojen kohdalla.

Siinä tapauksessa yhteensopivuus päivitykset pitäisi tulla samaan aikaan uuden käyttiksen ilmestymisen aikaan eikä pitkällä viiveellä.

[carrbon]

Toivottavasti nyt ei törmää samaan ongelmaan mitä oli SL:n kanssa käyttämiini kuvankäsittely ohjelmiin tuli päivitykset vasta puolen vuoden viiveellä siinä vaiheessa tosin oli ehditty jo korjata ohjelma paremmin toimivaksi muutenkin . Apple varmaan otti siitä opiksi kun informoi noin puoli vuotta aikaisemmin milloin ohjelma julkaistaisiin.

Muistaakseni SL:n tulo kyllä informoitiin myös aika hyvissä ajoin..? Korjatkoon joku jos olen väärässä!

About vuoden verran etukäteen saivat kehittäjät ensimaistiaiset ellen ole käsittänyt aivan väärin. Ja näin kai on ollut tapana muidenkin kissojen kohdalla.

Siinä tapauksessa yhteensopivuus päivitykset pitäisi tulla samaan aikaan uuden käyttiksen ilmestymisen aikaan eikä pitkällä viiveellä.

Jep, mutta sehän ei ole enää Applen vika..

[spiidi78]

Jep, mutta sehän ei ole enää Applen vika..

Tavallaan on. Osa noista viiveistä johtunee siitä, että Apple on pakottanut jengiä koodaamaan Cocoalla ohjelmistot, koska vanhojen frameworkien tuki (Carbon) on lopetettu. Tuoreimpana esimerkkinä siirtymä 64-bit aikakauteen. Käytännössä siis kehittäjien on pitänyt tehdä softat tietyiltä osin täysin uusiksi.

[kronos]

Näinhän tuo on mutta jos Apple ei pakottaisi kehittäjiä tekemään jatkuvasti uutta niin mitään kehitystä ei tapahtuisi. Kehittäjät ovat tyypillisesti erittäin laiskoja ja menevät yleensä yli siitä mistä aita on matalin. Harvoin näkee ohjelmointisuorituksia, joissa loistaa uudet innovaatiot ja ilmiömäinen luovuus. Viimeksi törmäsin moiseen OmniGrafflen yhteydessä.

Kaikesta päätellen iOS ja Mac OS X ovat lähestymässä toisiaan ja Lion on sitten tästä työstä ensimmäinen versio.

Olen myös kuullut huhuja, että Apple voisi luoda itselleen oman prosessorin käytettäväksi myös kannettavissa ja pöytäkoneissa — ei ollenkaan mikään mahdoton ajatus kun ottaa huomioon Applen käytössä olevat rahavarannot sekä sen, että Applella on jo olemassa varsin pätevä prosessoritiimi ARMille.

[tsjlehti]

Jep, mutta sehän ei ole enää Applen vika..

Tavallaan on. Osa noista viiveistä johtunee siitä, että Apple on pakottanut jengiä koodaamaan Cocoalla ohjelmistot, koska vanhojen frameworkien tuki (Carbon) on lopetettu. Tuoreimpana esimerkkinä siirtymä 64-bit aikakauteen. Käytännössä siis kehittäjien on pitänyt tehdä softat tietyiltä osin täysin uusiksi.

Eikä tuossa vielä kaikki. Apple taisi taannoin aika yllättäen hyllyttää 64-bittisen version Carbonista, jos oikein muistan. Tuo varmasti sotki monen muun aikatauluja ja suunnitelmia.

[Jamac]

Jep, mutta sehän ei ole enää Applen vika..

Tavallaan on. Osa noista viiveistä johtunee siitä, että Apple on pakottanut jengiä koodaamaan Cocoalla ohjelmistot, koska vanhojen frameworkien tuki (Carbon) on lopetettu. Tuoreimpana esimerkkinä siirtymä 64-bit aikakauteen. Käytännössä siis kehittäjien on pitänyt tehdä softat tietyiltä osin täysin uusiksi.

Eikä tuossa vielä kaikki. Apple taisi taannoin aika yllättäen hyllyttää 64-bittisen version Carbonista, jos oikein muistan. Tuo varmasti sotki monen muun aikatauluja ja suunnitelmia.

Ja hyvä päätös olikin. Mitä nopeammin Carbonista, eli vanhasta OS 9 koodistä päästään OS X:n sisällä eroon, sen parempi. Cocoa tarkoittaa puhdasta OS X-koodia jossa pelaa kaikki OS X:n herkut, moniajot ja muut sen sellaiset.

[spiidi78]

Harvoin näkee ohjelmointisuorituksia, joissa loistaa uudet innovaatiot ja ilmiömäinen luovuus. Viimeksi törmäsin moiseen OmniGrafflen yhteydessä.

No, kaikki on jo kerran tehty. Käytännössä voidaan vain soveltaa jo tehtyjä asioita uudelleen. En itse kyllä näe OmniGrafflessa mitään innovatiivista tai luovuutta Jos saisin valita, niin StarUML:ää käyttäisin, jos se olisi tehty Macille. Harmi, ettei kukaan ole portannut sitä vielä. Varmaan johtuu siitä, että se on tehty Delphillä, eikä kukaan C/C++ -koodari halua lukea Pascal-koodia

[tsjlehti]

Ja hyvä päätös olikin. Mitä nopeammin Carbonista, eli vanhasta OS 9 koodistä päästään OS X:n sisällä eroon, sen parempi.

Kyllähän se teknisesti perusteltu päätös oli. Mutta teknisiä perusteita sille mielen muutokselle, että ensin sanotaan ja vakuutellaan pitkään carbonista tulevan 64-bittistä versiota ja sitten perutaan, ei taida olla ollut olemassa.

[DrDoom]

Ko. kädenvääntöön annan myös maallikon näkemyksen. En koe mitään haittaa Finderin kaltaisesta järjestelystä.

Toinen maallikon näkemys tulee tässä. Joskus ohjelmien avautuminen kestää raivostuttavan pitkään. On paljon kätevämpää käydä siellä Dokumentti-kansiossa hakemassa ne pari Word-asiakirjaa ja kopioida ne muistitikulle, kuin odottaa pitkään, kun Word käynnistyy ja sitten tallennella halutut asiakirjat muistitikulle.

Sinänsä pidän vaikka iTunesin tavasta hallinoida dataa tietokantana, mutta se ei saa olla ainoa tapa. Googlen Picassa on mielestäni löytänyt hyvän tasapainon tietokannan ja tiedostojärjestelmän käytön kanssa.

[Mailia]

Sinänsä pidän vaikka iTunesin tavasta hallinoida dataa tietokantana, mutta se ei saa olla ainoa tapa. Googlen Picassa on mielestäni löytänyt hyvän tasapainon tietokannan ja tiedostojärjestelmän käytön kanssa.

iTunesin tapa järjestää tiedostoja on kyllä hyvä. Se tekee automaattisesti kansiot minulle ja lajitteleet mediat sinne ja itse ohjelmassa kaikki näkyy oikein siististi, mutta jos tarvitsen niitä tiedostoja itse tiedostojärjestelmässä, tiedän mistä ne löytää hyvin ja järjestellysti.

[DrDoom]

Sinänsä pidän vaikka iTunesin tavasta hallinoida dataa tietokantana, mutta se ei saa olla ainoa tapa. Googlen Picassa on mielestäni löytänyt hyvän tasapainon tietokannan ja tiedostojärjestelmän käytön kanssa.

iTunesin tapa järjestää tiedostoja on kyllä hyvä. Se tekee automaattisesti kansiot minulle ja lajitteleet mediat sinne ja itse ohjelmassa kaikki näkyy oikein siististi, mutta jos tarvitsen niitä tiedostoja itse tiedostojärjestelmässä, tiedän mistä ne löytää hyvin ja järjestellysti.

Joo, periaatteessa iTunesin tapa on hyvä. Käytännössä varsin suuri osa levyistä menee aivan vääriin kansioihin (Collection, Other tms tai sitten väärän artistin alle). Eipä tuo musiikkijutuissa häiritse, kun ei kerran ole tarvetta käpistellä manuaalisesti niitä tiedostoja, mutta missä tahansa muissa tiedostoissa (dokumentit, taulukot, valokuvat) tuo ei tulisi kyseeseenkään.

[nin]

Joo, periaatteessa iTunesin tapa on hyvä. Käytännössä varsin suuri osa levyistä menee aivan vääriin kansioihin (Collection, Other tms tai sitten väärän artistin alle). Eipä tuo musiikkijutuissa häiritse, kun ei kerran ole tarvetta käpistellä manuaalisesti niitä tiedostoja, mutta missä tahansa muissa tiedostoissa (dokumentit, taulukot, valokuvat) tuo ei tulisi kyseeseenkään.

Eikö ne tagit kannattaisi korjata? Turhaa kai siitä iTunesia syyttää, että levyt menee vääriin kansioihin jos on väärät tiedot.

[DrDoom]

Joo, periaatteessa iTunesin tapa on hyvä. Käytännössä varsin suuri osa levyistä menee aivan vääriin kansioihin (Collection, Other tms tai sitten väärän artistin alle). Eipä tuo musiikkijutuissa häiritse, kun ei kerran ole tarvetta käpistellä manuaalisesti niitä tiedostoja, mutta missä tahansa muissa tiedostoissa (dokumentit, taulukot, valokuvat) tuo ei tulisi kyseeseenkään.

Eikö ne tagit kannattaisi korjata? Turhaa kai siitä iTunesia syyttää, että levyt menee vääriin kansioihin jos on väärät tiedot.

Tagit on ihan oikein. Turha on syyttää käyttäjää, jos ohjelmassa on vikaa.

[Mailia]

Joo, periaatteessa iTunesin tapa on hyvä. Käytännössä varsin suuri osa levyistä menee aivan vääriin kansioihin (Collection, Other tms tai sitten väärän artistin alle). Eipä tuo musiikkijutuissa häiritse, kun ei kerran ole tarvetta käpistellä manuaalisesti niitä tiedostoja, mutta missä tahansa muissa tiedostoissa (dokumentit, taulukot, valokuvat) tuo ei tulisi kyseeseenkään.

Eikö ne tagit kannattaisi korjata? Turhaa kai siitä iTunesia syyttää, että levyt menee vääriin kansioihin jos on väärät tiedot.

Tagit on ihan oikein. Turha on syyttää käyttäjää, jos ohjelmassa on vikaa.

Kyllä tuo kuulostaa vääriltä tageiltä ennemmin kuin iTunesin ongelmalta. Itse ainakin olen tarkkaan vahtinut tageja ja ne näyttäisi olevan ihan järjestyksessä.

[DrDoom]

Joo, periaatteessa iTunesin tapa on hyvä. Käytännössä varsin suuri osa levyistä menee aivan vääriin kansioihin (Collection, Other tms tai sitten väärän artistin alle). Eipä tuo musiikkijutuissa häiritse, kun ei kerran ole tarvetta käpistellä manuaalisesti niitä tiedostoja, mutta missä tahansa muissa tiedostoissa (dokumentit, taulukot, valokuvat) tuo ei tulisi kyseeseenkään.

Eikö ne tagit kannattaisi korjata? Turhaa kai siitä iTunesia syyttää, että levyt menee vääriin kansioihin jos on väärät tiedot.

Tagit on ihan oikein. Turha on syyttää käyttäjää, jos ohjelmassa on vikaa.

Kyllä tuo kuulostaa vääriltä tageiltä ennemmin kuin iTunesin ongelmalta. Itse ainakin olen tarkkaan vahtinut tageja ja ne näyttäisi olevan ihan järjestyksessä.

Liitteenä kaksi kuvaa, joista toisessa Mark Knopflerin albumin tagit ja toisessa kansio, jossa kyseinen albumi sijaitsee. Itunes huolehtii itse kansioiden järjestelystä ja on päättänyt, että kyseinen albumi (ja muutama muukin) kuuluu kansioon Compilations. Ja löytyy näitä enemmänkin, välillä on artistit iloisesti sekaisin samassa kansiossa. Samaa höttöä on Applen softat kuin muillakin, eli kaukana virheettömyydestä ihan perusasioissakin.

[honpsu]

Tagit on ihan oikein. Turha on syyttää käyttäjää, jos ohjelmassa on vikaa.

Samaa höttöä on Applen softat kuin muillakin, eli kaukana virheettömyydestä ihan perusasioissakin.

Olet ruksannut kohdan "osa kokoelmaa", ja ihmettelet miksi albumi on kokoelma kansiossa?