Onko EFI -osio nykyään pakollinen Ubuntussa?

Anonyymi

Jos on, niin miksi? Vanhasssa koneessani en tarvitse efiä.

69

948

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • Uusissa PC-koneissa on oletuksena UEFI asetettuna päälle, joten tällaiseen koneeseen asennettavan käyttöjärjestelmän on joko tuettava EFI:ä tai sitten on koneesta otettava UEFI pois.

      • Anonyymi

        Ubuntu 18.04 asentui vielä ilman efi-osiota. Nyt 20.04 ei.


      • Anonyymi

        Mutta Ubuntussa ei ole mitään erillistä Uefi osiota, joka mm w10 on.


      • Anonyymi kirjoitti:

        Mutta Ubuntussa ei ole mitään erillistä Uefi osiota, joka mm w10 on.

        Kyllä vain on, mikäli Linux on asennettu koneeseen, jossa UEFI on päällä.


      • Anonyymi
        Kollimaattori kirjoitti:

        Kyllä vain on, mikäli Linux on asennettu koneeseen, jossa UEFI on päällä.

        Vastasinkin avauksen kysymyksen pohjalta!


      • Anonyymi
        Anonyymi kirjoitti:

        Vastasinkin avauksen kysymyksen pohjalta!

        Uefia ei ole mitään järkee pitää päällä!


      • Anonyymi

        EI OLE PAKOLLINEN!


      • Anonyymi
        Anonyymi kirjoitti:

        EI OLE PAKOLLINEN!

        Joku levittää taas valheitaan! Ei se ole pakollinen!


      • Anonyymi
        Kollimaattori kirjoitti:

        Kyllä vain on, mikäli Linux on asennettu koneeseen, jossa UEFI on päällä.

        Niin, siis, tarkempia yksityiskohtia tietämättä, mutta jos Ubuntu on asennettu windows 10 rinnalle, siis rinnalle, niin tällöin Ubuntun EFI -tiedot menevät sille samalla EFI-osiolle jolla windows 10 tiedot ovat.

        Yhdellä kiintolevyllä voi olla vain yksi EFI -osio, jota sitten kaikki käyttävät, kun asennetaan rinnalle jotain.


      • Anonyymi kirjoitti:

        Niin, siis, tarkempia yksityiskohtia tietämättä, mutta jos Ubuntu on asennettu windows 10 rinnalle, siis rinnalle, niin tällöin Ubuntun EFI -tiedot menevät sille samalla EFI-osiolle jolla windows 10 tiedot ovat.

        Yhdellä kiintolevyllä voi olla vain yksi EFI -osio, jota sitten kaikki käyttävät, kun asennetaan rinnalle jotain.

        Itse ainakin ymmärsin "erillisellä" tarkoitettavan erillistä osiota, jossa Ubuntu ei sijaitse. Tähän erilliseen ja yhteen ainoaan kunkin kiintolevyn EFI -osioon juuri perustuu nykyaikaisten käyttöjärjestelmien saumaton multiboottaus, kun enää ei yhden käyttöjärjestelmän asennus omalle osiolleen riko koneella jo olevan käyttöjärjestelmän käynnistystä.


      • Anonyymi
        Kollimaattori kirjoitti:

        Itse ainakin ymmärsin "erillisellä" tarkoitettavan erillistä osiota, jossa Ubuntu ei sijaitse. Tähän erilliseen ja yhteen ainoaan kunkin kiintolevyn EFI -osioon juuri perustuu nykyaikaisten käyttöjärjestelmien saumaton multiboottaus, kun enää ei yhden käyttöjärjestelmän asennus omalle osiolleen riko koneella jo olevan käyttöjärjestelmän käynnistystä.

        Vaikea ymmärtää että mitä tässä tarkoitettiin, mutta tosiasia on se, että yhdellä kiintolevyllä voi olla vain yksi EFI -osio, ja tietokoneessa voi olla useampi kiintolevy yhtä aikaa kiinni, joissa jokaisessa voi olla yksi oma EFI -osio, ja näin myös 'hoitaa' multiboot -asiota.

        Itselläni mm, oli W81 ja W10 asennettuna yhteen koneessen, kumpikin omille kiintolevyille, ja sitten kun asensi Linuxin, niin piti valita että kumpaan EFI -osioon Linux laittaa käynnistystiedostonsa...


    • Ubuntu 20.04 LTS ei tarvitse UEFI-yhteensopivuutta, vaan asentuu koneeseen, jossa ei ole UEFI:a. Tämän olen testannut sekä vanhalla koneella että virtualisoituna.

      Toimii.

    • Anonyymi

      Kannattaa olla varuillaan jos muita käyttiksiä on asennettuna, Ubu 20.04 jälkeen muut käyttikset jäi "iki-looppiin" käynnistysvaiheessa

      • Anonyymi

        Mitä hittoa sä taas valehtelet...


      • Anonyymi
        Anonyymi kirjoitti:

        Mitä hittoa sä taas valehtelet...

        En valehtele, oli Mint 19.3 ja Fedora 31, molemmat jäi ikuiseen käynnistystilaan Ubuntun 20.04 asennuksen jälkeen.


      • Anonyymi

        Tuo on w10 ongelma.. Ubuntu toimii!


      • Anonyymi
        Anonyymi kirjoitti:

        En valehtele, oli Mint 19.3 ja Fedora 31, molemmat jäi ikuiseen käynnistystilaan Ubuntun 20.04 asennuksen jälkeen.

        Toivottavast uskosi on tarpeeksi vahva toistelemaan puppua päivästä toiseen.


      • Anonyymi
        Anonyymi kirjoitti:

        Toivottavast uskosi on tarpeeksi vahva toistelemaan puppua päivästä toiseen.

        Sinä sitä valetta levität!


      • Anonyymi
        Anonyymi kirjoitti:

        Toivottavast uskosi on tarpeeksi vahva toistelemaan puppua päivästä toiseen.

        En tiedä mitä puppua tässä muka on, kerroin vain kokemuksistani. En ole mikään Windows trolli sillä koneessani ei ole Windowsia lainkaan. Asensin sitten uusiksi Ubtuntu 20.04 ensin ja sen jälkeen Mintin, Fedoralle ei ollut käyttöä. Toki onneksi kaukaa viisaana on omat osiot käyttiksille ja datalle, joten en tuossa mitään menettänyt kuin asentaa softat vain uusiksi.


      • Anonyymi
        Anonyymi kirjoitti:

        En valehtele, oli Mint 19.3 ja Fedora 31, molemmat jäi ikuiseen käynnistystilaan Ubuntun 20.04 asennuksen jälkeen.

        Valehtelethan! Ubuntun 20.04 toimii mainiosti ilman ongelmia!


      • Anonyymi
        Anonyymi kirjoitti:

        En tiedä mitä puppua tässä muka on, kerroin vain kokemuksistani. En ole mikään Windows trolli sillä koneessani ei ole Windowsia lainkaan. Asensin sitten uusiksi Ubtuntu 20.04 ensin ja sen jälkeen Mintin, Fedoralle ei ollut käyttöä. Toki onneksi kaukaa viisaana on omat osiot käyttiksille ja datalle, joten en tuossa mitään menettänyt kuin asentaa softat vain uusiksi.

        Levittää jatkuvasti valheita Linuxixta, Firefoxista ja Ubuntusta mm.


      • Anonyymi
        Anonyymi kirjoitti:

        En tiedä mitä puppua tässä muka on, kerroin vain kokemuksistani. En ole mikään Windows trolli sillä koneessani ei ole Windowsia lainkaan. Asensin sitten uusiksi Ubtuntu 20.04 ensin ja sen jälkeen Mintin, Fedoralle ei ollut käyttöä. Toki onneksi kaukaa viisaana on omat osiot käyttiksille ja datalle, joten en tuossa mitään menettänyt kuin asentaa softat vain uusiksi.

        Tässä voi olla kyse grub2-configurointien eroista, ts. ubuntu käyttää oletuksena UUID-tunnuksia levyosioille ja jos ne ei ole mukana kernelissä, ongelmiahan siitä seuraa. Voit joutua editoimaan käsin levytunnukset bootissa. Mitään ei kuitenkaan ole kadonnut ja jos haluat bootin toimivan, niin voit mountata muiden käyttistesi osiot esim. /media/disk1, jne. alle jos ne eivät löydy automaattisesti - yleensä löytyy. Tämän jälkeen ajettuna update-grub. Ainakin jossakin vaiheessa redhat odotti /dev/hda1 tjsp. osioita /dev/sda1 osion tilaan, mitä taas ubuntussa käytetään - tuon korjaaminen auttoi bootissa.
        Edelleen, oletus-kernelisi ei välttämättä osaa lukea osiota jos siltä puuttuu ajurit sen tiedostojärjestelmää varten. Näitä on tullut korjailtua mm. ajamalla esim. ubuntun kernelillä ristiin toista käyttistä, jotta sen saa edes käyntiin. Tämän jälkeen asenneltua tarvittavat ajurit ja generoimalla uusi initrd (mkinitramfs, update-initramfs) saa ajurin mukaan ja käynnistyy. Jos käytät /boot-osiota on tämä helppoa, koska voit sijoittaa kaikki kernelisi em. hakemistoon.


      • Anonyymi
        Anonyymi kirjoitti:

        En valehtele, oli Mint 19.3 ja Fedora 31, molemmat jäi ikuiseen käynnistystilaan Ubuntun 20.04 asennuksen jälkeen.

        Jos näin tapahtuu, niin BIOSin kautta voi viime kädessä valita että minkä käyttöjärjestelmän haluaa bootata....


      • Anonyymi
        Anonyymi kirjoitti:

        Jos näin tapahtuu, niin BIOSin kautta voi viime kädessä valita että minkä käyttöjärjestelmän haluaa bootata....

        Biossista voi määritellä, miltä levyosiolta tai ulkoiselta laitteelta järjestelmän voisi käynnistää, jos osiolla on sopiva käynnistin kuten grub asennettuna.
        Jos jollekulle levyosioista on asennettu esim. Grub, voi käynnistettäessä editoida grub:in käynnistymistä - mutta tuo on siis jo hieman eri asia.
        Käynnistyksen lataajan voi korjata Live-jakeluilla tai erityisillä Rescue-medioilla.


    • Anonyymi

      Lähinnä tuossa harmittaa, ettei 20.04 tue enää i386 arkkitehtuuria. Näitä koneita kun on käytössä - toisaalta jos niitä pystyy käyttämään vanhalla käyttöjärjestelmällä tuonne 2030 asti, niin ehkäpä se riittää..

      • Anonyymi

        i386-prossori ongelman ratkaisin asentamalla Debianin ko. vanhoihin koneisiin.
        En näet jaksa uskoa, että Canonical Ubuntun 18.04 i386 -versiota jaksaa ylläpitää 2030 asti :(


      • Anonyymi
        Anonyymi kirjoitti:

        i386-prossori ongelman ratkaisin asentamalla Debianin ko. vanhoihin koneisiin.
        En näet jaksa uskoa, että Canonical Ubuntun 18.04 i386 -versiota jaksaa ylläpitää 2030 asti :(

        Samat bugikorjaukset siihen varmaan käännetään mukaan kuin mitä tehdään vastaavaan x86_64 -versioon...


    • EFi osio ei ole pakollinen. EFI osio kuitenkin nykyaikaa ja antaa tuen isommille levyille. MBR on kovin pieni ja se sisältää vain koodin mistä varsinainen lataaja löytyy. Vanha bios ei tue kovin isoa levyä ja lataajaa ei vättämättä pystytä lukemaan. gpt osioitu levy taas sisältää EFI osion ja ongelmia ei ole isojen levyjen kanssa. Pienen SSD levyn voi toki osioida MBR levyksi jos datat muilla levyillä. Oikeissa tietokoneissa joissa paljon levyjä on käytetty jo pitkään fiksumpia tapoja säilyttää dataa. Nyky PC:ssä joku teran levy ihan normi nykyään. Harrastajilla taas on monen teran levyjä joissa EFI jo pakollinen. Levyjen osioinnissa Windows on ollut pitkään huono. Vasta 64 bittinen Windows osasi isompia levyjä. Dos 3 osasi vain 32 megasen levyn. Linux on osannut käyttää levyjä fiksummin. Samoin moni muu systeemi. Windows ei välttämättä riitä kotikäyttäjälle vieläkään. kun se vaan ei osaa. Tämä ei ole valetta vaan ihan faktaa.

      • Anonyymi

        EFI ei anna tukea isommille levyille, vaan vain GPT.


      • Anonyymi

        GPT osioitu levy EI sisällä EFI -osiota ellei sitä sinne erikseen LAITETA käyttöjärjestelmän asennuksen yhteydessä.


      • Anonyymi

        Itse asiassa, MBR mahdollistaa enintään 2TB partition käytön, ja jos suurempaa haluaa, niin sitten pitää käyttää GPT. Linuxilla on mahdollista tehdä myös ns. 'Hybrid Mode', jossa MBR:n sisään piilotetaan GPT, ja näin saadaan käyttöön yli 2TB osio käyttöön. Menetelmää käytetään joissain korkatuissa NAS -pavelimissa, joissa NASin oma ohjelmisto (firmware) on asetettu boottaamaan kokonaan toinen Linux suoraan kiintolevyltä, jossa rajoituksena pääsääntöisesti on, että GPT -partitiolta tämä 'ohitus' ei osaa bootata, vaan vain MBR.

        Tällä ei puolestaan ole mitään tekemistä tiedostojärjestelmän kanssa, jossa vanha MS-DOS aikainen FAT tosiaan oli rajoitettu 32M, jonka jälkeen tuli sitten enemmän tilaa antavat FAT32, VFAT, ja NTFS, joiden lisäksi myös eri UNIXit ja Linuxit toivat myös muita tiedostojärjestelmiä, joista tunnetuimmat ext2 ja ext3, jotka myöhemmin päivittyivät ext4, kuitenkaan unohtamatta jo 90-luvun taitteessa kehitettyä XFS -tiedostojärjestelmää, joka vain jäi jostain syystä varjoon, ja on alkanut vasta nyt nostamaan päätään pinnalle, ollen oletustiedostojärjestelmänä useissa palvelinkäyttöjärjestelmään tarkoitetuissa Linuxeissa.


      • Anonyymi
        Anonyymi kirjoitti:

        Itse asiassa, MBR mahdollistaa enintään 2TB partition käytön, ja jos suurempaa haluaa, niin sitten pitää käyttää GPT. Linuxilla on mahdollista tehdä myös ns. 'Hybrid Mode', jossa MBR:n sisään piilotetaan GPT, ja näin saadaan käyttöön yli 2TB osio käyttöön. Menetelmää käytetään joissain korkatuissa NAS -pavelimissa, joissa NASin oma ohjelmisto (firmware) on asetettu boottaamaan kokonaan toinen Linux suoraan kiintolevyltä, jossa rajoituksena pääsääntöisesti on, että GPT -partitiolta tämä 'ohitus' ei osaa bootata, vaan vain MBR.

        Tällä ei puolestaan ole mitään tekemistä tiedostojärjestelmän kanssa, jossa vanha MS-DOS aikainen FAT tosiaan oli rajoitettu 32M, jonka jälkeen tuli sitten enemmän tilaa antavat FAT32, VFAT, ja NTFS, joiden lisäksi myös eri UNIXit ja Linuxit toivat myös muita tiedostojärjestelmiä, joista tunnetuimmat ext2 ja ext3, jotka myöhemmin päivittyivät ext4, kuitenkaan unohtamatta jo 90-luvun taitteessa kehitettyä XFS -tiedostojärjestelmää, joka vain jäi jostain syystä varjoon, ja on alkanut vasta nyt nostamaan päätään pinnalle, ollen oletustiedostojärjestelmänä useissa palvelinkäyttöjärjestelmään tarkoitetuissa Linuxeissa.

        Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus.


      • Anonyymi
        Anonyymi kirjoitti:

        Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus.

        Olet muuten oikeassa! Nyt muistin, että joskus 90-luvun taitteessa alkoi tulla 1Gt kiintolevyjä...


      • Anonyymi
        Anonyymi kirjoitti:

        Olet muuten oikeassa! Nyt muistin, että joskus 90-luvun taitteessa alkoi tulla 1Gt kiintolevyjä...

        Onkos tuo "kiintolevy" mukamas niin vanha, mulla on ollut vain kovalevyjä.


      • Anonyymi
        Anonyymi kirjoitti:

        Onkos tuo "kiintolevy" mukamas niin vanha, mulla on ollut vain kovalevyjä.

        Tekniikka kehittyy koko ajan...


      • Anonyymi kirjoitti:

        Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus.

        "Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus."

        Sanoinkin, että DOS 3 kokoraja oli 32MB. Mikrosoftin osiointiohjelma oli muinon rikki. Vaikka tiedostojärjestelmä olisi sallinut siinä usein joku rajoitus. Windows XT muistaakseni 137GB kunnes service pack korjasi vian. Jos osioi isomman levyn, vaikka 200GB se sekosi. Sata levyn tuki piti pistää korpulta.

        UEFI on korjannut monta rajoitusta. EFI osio helpottaa useamman käyttöjärjestelmän asentamisen. Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan. Gpt mahdollistaa myös useampia levyjä. mbr levyjen ongelma oli osioden loppuminen. 4 kpl primäärejä joista yksi käynnistyvä. Lisäksi laajennettu osio. Kun tuuppasi uuden levyn koneeseen kaikki nimet sekosi. Linuxin nimeämistapa fiksumpi.

        Historiallisista syistä käytän vielä paljon XFS-tiedostojärjestelmää. Vakaa ja muutamissa asioissa fiksumpi kuin ext4. Otin käyttöön kun ext4 oli vielä epävakaa. Miinuksena, että osion koon pienentäminen hankalaa.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus."

        Sanoinkin, että DOS 3 kokoraja oli 32MB. Mikrosoftin osiointiohjelma oli muinon rikki. Vaikka tiedostojärjestelmä olisi sallinut siinä usein joku rajoitus. Windows XT muistaakseni 137GB kunnes service pack korjasi vian. Jos osioi isomman levyn, vaikka 200GB se sekosi. Sata levyn tuki piti pistää korpulta.

        UEFI on korjannut monta rajoitusta. EFI osio helpottaa useamman käyttöjärjestelmän asentamisen. Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan. Gpt mahdollistaa myös useampia levyjä. mbr levyjen ongelma oli osioden loppuminen. 4 kpl primäärejä joista yksi käynnistyvä. Lisäksi laajennettu osio. Kun tuuppasi uuden levyn koneeseen kaikki nimet sekosi. Linuxin nimeämistapa fiksumpi.

        Historiallisista syistä käytän vielä paljon XFS-tiedostojärjestelmää. Vakaa ja muutamissa asioissa fiksumpi kuin ext4. Otin käyttöön kun ext4 oli vielä epävakaa. Miinuksena, että osion koon pienentäminen hankalaa.

        ...'Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan.'... ei nyt ihan pidä paikkaansa, koska windows piti aina asentaa ensin, ja vasta sen jälkeen pystyi asentamaan Linuxin, koska windows oli aina pakko olla ensimmäisellä partitiolla, ja sen jälkeen kun asensi Linuxin, niin 'lilo' otti hoitaakseen että kumpi käyttöjärjestelmä ladataan.

        ...'Gpt mahdollistaa myös useampia levyjä.'.. ei pidä paikkaansa, vaan vain useampia osioita. MBR osioiden enimmäismäärä oli 7, jos laajennettu osiointi oli käytössä, kun GPT sallii 128, Mutta Linuxilla pystyi käyttämään LVM, joka kykeni osoimaan yhden ismomman osion pienemmiksi, ja niiden kokoja pystyi myös lennosta muuttamaan.

        XFS ei oletusarvoisesti salli osion koon pienentämistä, ja itse en ainakaan ole löytänyt mitään työkalua tähän, vaan vain ohjeen että kaikki pitää ensin kopioida talteen muualle, ja sitten tehdä kokonaan osio uudelleen.

        Itse en ole onnistunut pitämään XFS ehjänä ja kunnossa lainkaan, joten käytän edelleen vain EXT4, joka siis myös sallii osion pienentämisen, erityisesti tapauksessa kun käytetään LVM.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "Korjaan sinua sen verran että MS-Dos 6.xx FAT16 rajoitti kiintolevyn kokoa 2 GB, ei siis 32MB. Tuo 32 MB rajoitus on paaaaaaljon vanhempien dossien rajoitus."

        Sanoinkin, että DOS 3 kokoraja oli 32MB. Mikrosoftin osiointiohjelma oli muinon rikki. Vaikka tiedostojärjestelmä olisi sallinut siinä usein joku rajoitus. Windows XT muistaakseni 137GB kunnes service pack korjasi vian. Jos osioi isomman levyn, vaikka 200GB se sekosi. Sata levyn tuki piti pistää korpulta.

        UEFI on korjannut monta rajoitusta. EFI osio helpottaa useamman käyttöjärjestelmän asentamisen. Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan. Gpt mahdollistaa myös useampia levyjä. mbr levyjen ongelma oli osioden loppuminen. 4 kpl primäärejä joista yksi käynnistyvä. Lisäksi laajennettu osio. Kun tuuppasi uuden levyn koneeseen kaikki nimet sekosi. Linuxin nimeämistapa fiksumpi.

        Historiallisista syistä käytän vielä paljon XFS-tiedostojärjestelmää. Vakaa ja muutamissa asioissa fiksumpi kuin ext4. Otin käyttöön kun ext4 oli vielä epävakaa. Miinuksena, että osion koon pienentäminen hankalaa.

        "Sanoinkin, että DOS 3 kokoraja oli 32MB. "

        Juu, niin sanoit mutta joku toinen sanoi että se olisi yleinen Dossin kokoraja johon sitä sitten korjasin että se koski todella vanhoja dosseja, ei esim. Dos 6.xx.


      • Anonyymi
        Anonyymi kirjoitti:

        ...'Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan.'... ei nyt ihan pidä paikkaansa, koska windows piti aina asentaa ensin, ja vasta sen jälkeen pystyi asentamaan Linuxin, koska windows oli aina pakko olla ensimmäisellä partitiolla, ja sen jälkeen kun asensi Linuxin, niin 'lilo' otti hoitaakseen että kumpi käyttöjärjestelmä ladataan.

        ...'Gpt mahdollistaa myös useampia levyjä.'.. ei pidä paikkaansa, vaan vain useampia osioita. MBR osioiden enimmäismäärä oli 7, jos laajennettu osiointi oli käytössä, kun GPT sallii 128, Mutta Linuxilla pystyi käyttämään LVM, joka kykeni osoimaan yhden ismomman osion pienemmiksi, ja niiden kokoja pystyi myös lennosta muuttamaan.

        XFS ei oletusarvoisesti salli osion koon pienentämistä, ja itse en ainakaan ole löytänyt mitään työkalua tähän, vaan vain ohjeen että kaikki pitää ensin kopioida talteen muualle, ja sitten tehdä kokonaan osio uudelleen.

        Itse en ole onnistunut pitämään XFS ehjänä ja kunnossa lainkaan, joten käytän edelleen vain EXT4, joka siis myös sallii osion pienentämisen, erityisesti tapauksessa kun käytetään LVM.

        Kyllä Windows 10 ylikirjoitti alussa aina ison päivityksen jälkeen käynnistyslataajan.


      • Anonyymi
        Anonyymi kirjoitti:

        Kyllä Windows 10 ylikirjoitti alussa aina ison päivityksen jälkeen käynnistyslataajan.

        Kerroppa mikä se sellainen 'iso päivitys' on joka ylikirjoittaa käynnisyslataajan, että linkki tällaiseen uutiseen, koska ei tällaisesta oli koskaan millään kansainvälisellä foorumilla ole ollut mitään juttua, ja ei minulla ainakaan ole ylikijoittanut käynnistyslataajaa koskaan siten että Linux olisi lopettanut toimimasta...


      • Anonyymi
        Anonyymi kirjoitti:

        Kerroppa mikä se sellainen 'iso päivitys' on joka ylikirjoittaa käynnisyslataajan, että linkki tällaiseen uutiseen, koska ei tällaisesta oli koskaan millään kansainvälisellä foorumilla ole ollut mitään juttua, ja ei minulla ainakaan ole ylikijoittanut käynnistyslataajaa koskaan siten että Linux olisi lopettanut toimimasta...

        Enpä noita numeroita enää muista vuosilta 2014/ 2015/2016.


      • Anonyymi
        Anonyymi kirjoitti:

        Enpä noita numeroita enää muista vuosilta 2014/ 2015/2016.

        Noh, eipä todellakaan ole minun kohdalleni sattunut kertaakaan... Ettet nyt vain satuilisi omiasi....?


      • Anonyymi kirjoitti:

        Kyllä Windows 10 ylikirjoitti alussa aina ison päivityksen jälkeen käynnistyslataajan.

        'Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan.'... Tarkoitin, että Windows asennus kirjoitti aina yli mbr:n sisällön ja mahdollisesti muut asennetut käyttöjärjestelmät vaikka Linux ei sitten enää käynnistynyt. Linuxin käynnistylataaja kuten Windowssinkin on melko helppo asentaa uudestaan asennusmedialla. Linux voi olla vaikka missä, myös useammalla levyllä. Levyillä voi olla myös erilaiset tiedostojärjestelmät. lataaja tukee aika montaa tiedostojärjestelmää.


      • Anonyymi kirjoitti:

        ...'Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan.'... ei nyt ihan pidä paikkaansa, koska windows piti aina asentaa ensin, ja vasta sen jälkeen pystyi asentamaan Linuxin, koska windows oli aina pakko olla ensimmäisellä partitiolla, ja sen jälkeen kun asensi Linuxin, niin 'lilo' otti hoitaakseen että kumpi käyttöjärjestelmä ladataan.

        ...'Gpt mahdollistaa myös useampia levyjä.'.. ei pidä paikkaansa, vaan vain useampia osioita. MBR osioiden enimmäismäärä oli 7, jos laajennettu osiointi oli käytössä, kun GPT sallii 128, Mutta Linuxilla pystyi käyttämään LVM, joka kykeni osoimaan yhden ismomman osion pienemmiksi, ja niiden kokoja pystyi myös lennosta muuttamaan.

        XFS ei oletusarvoisesti salli osion koon pienentämistä, ja itse en ainakaan ole löytänyt mitään työkalua tähän, vaan vain ohjeen että kaikki pitää ensin kopioida talteen muualle, ja sitten tehdä kokonaan osio uudelleen.

        Itse en ole onnistunut pitämään XFS ehjänä ja kunnossa lainkaan, joten käytän edelleen vain EXT4, joka siis myös sallii osion pienentämisen, erityisesti tapauksessa kun käytetään LVM.

        "Itse en ole onnistunut pitämään XFS ehjänä ja kunnossa lainkaan, joten käytän edelleen vain EXT4, joka siis myös sallii osion pienentämisen, erityisesti tapauksessa kun käytetään LVM."

        Itsellä on ollut pitkään XFS TV-tallenteiden, musiikin ja valokuvien säilöntäpaikkana. Ikinä ei ongelmia. Levyn eheytyskin helppoa - toki yleensä tarpeetonta. XFS ollut pitkään vakaa ja varsinkin isojen tiedostojen käytössä nopeampi kuin EXT4 mistä etua TV-tallenteiden kanssa kun poistaa vaikka mainokset. Jokaiseen käyttötarkoitukseen löytyy sopiva tiedostojärjestelmä. Jos kääntelee paljon vaikka kerneletä ei xfs ehkä ole sopivin kun lähdekoodi pakkautuu kivasti ja tiedostojen koko pieni.


      • Mikko_Tku kirjoitti:

        "Itse en ole onnistunut pitämään XFS ehjänä ja kunnossa lainkaan, joten käytän edelleen vain EXT4, joka siis myös sallii osion pienentämisen, erityisesti tapauksessa kun käytetään LVM."

        Itsellä on ollut pitkään XFS TV-tallenteiden, musiikin ja valokuvien säilöntäpaikkana. Ikinä ei ongelmia. Levyn eheytyskin helppoa - toki yleensä tarpeetonta. XFS ollut pitkään vakaa ja varsinkin isojen tiedostojen käytössä nopeampi kuin EXT4 mistä etua TV-tallenteiden kanssa kun poistaa vaikka mainokset. Jokaiseen käyttötarkoitukseen löytyy sopiva tiedostojärjestelmä. Jos kääntelee paljon vaikka kerneletä ei xfs ehkä ole sopivin kun lähdekoodi pakkautuu kivasti ja tiedostojen koko pieni.

        Itsekin olen antanut kertoa itselleni XFS:n olevan erityisen hyvän suurten tiedostojen tallentamiseen ja lukemiseen, joten olen XFS:ää käyttänyt elokuvatiedostojen tallennuskiintolevylle.

        Nykyään myös pääkoneeni SSD:n /home -osio on formatoitu XFS:ksi, mutta sitä en tiedä, onko mitään nopeusetua saatavilla systeemissä, joka muutoinkin on todella nopea. Järjestelmäosion alustin EXT4:ään, koska en oikein ole löytänyt perusteluja sille, miksi pitäisi käyttää oletuksena olevaa BTRFS:ää.


      • Anonyymi
        Mikko_Tku kirjoitti:

        'Ennen Windows kirjoitti aina yli Linuxin käynnistyslataajan.'... Tarkoitin, että Windows asennus kirjoitti aina yli mbr:n sisällön ja mahdollisesti muut asennetut käyttöjärjestelmät vaikka Linux ei sitten enää käynnistynyt. Linuxin käynnistylataaja kuten Windowssinkin on melko helppo asentaa uudestaan asennusmedialla. Linux voi olla vaikka missä, myös useammalla levyllä. Levyillä voi olla myös erilaiset tiedostojärjestelmät. lataaja tukee aika montaa tiedostojärjestelmää.

        Niin... siis windows piti aina asentaa ensin ennen kuin pystyi asentamaan mitään muuta, koska windows pitää aina asentaa ensimmäiselle partitiolle, ja vasta tämän jälkeen Linux etc, niin ei se mitään silloin voi ylikirjoittaa. Mutta jos tästä nyt jotenkin kumman syystä oli jonkinlainen huoli, niin sen mbr pystyi varmuuskopiomaan Linuxilla talteen..


      • Kollimaattori kirjoitti:

        Itsekin olen antanut kertoa itselleni XFS:n olevan erityisen hyvän suurten tiedostojen tallentamiseen ja lukemiseen, joten olen XFS:ää käyttänyt elokuvatiedostojen tallennuskiintolevylle.

        Nykyään myös pääkoneeni SSD:n /home -osio on formatoitu XFS:ksi, mutta sitä en tiedä, onko mitään nopeusetua saatavilla systeemissä, joka muutoinkin on todella nopea. Järjestelmäosion alustin EXT4:ään, koska en oikein ole löytänyt perusteluja sille, miksi pitäisi käyttää oletuksena olevaa BTRFS:ää.

        "Järjestelmäosion alustin EXT4:ään, koska en oikein ole löytänyt perusteluja sille, miksi pitäisi käyttää oletuksena olevaa BTRFS:ää."

        EXT4 pahin rajoitus on kai tiedostojen lukumäärä mitä ei voi kasvattaa jälkiteen. Raja voi tulla vastaan jos pienellä levyllä paljon tiedostoja. Normikäyttäjällä harvemmin paljon tiedostoja. BTRFS osaa paremmin käsitellä pieniä tiedostoja. Sisältö voidaan tallentaa hakemistorakenteenesen. tiedostoja voidaan pakata. Kopiosta tallennetaan vain yksi versio.

        Huvikseen voi testata tikulla. 100 000 pientä tiedostoa. Kaunanko kestää fat, ext4, XFS tai BTRFS. fat tallentaa nimet listaan ja listan luku aloitetaan aina alusta. Fat siitä rajoittunut, että sen juuren voi tallentaa vain vähän tiedostoja. Fat häviää melkoisesti ja ihme kun vielä käytössä.

        Esim Arch linux sisältää 69888 aur pakettia. BSD ports ja Gentoon portage sisältävät myös paljon pieniä tiedostoja jos joku väittää ettei tuollaiselle tiedostämäärälle ole käyttöä.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "Järjestelmäosion alustin EXT4:ään, koska en oikein ole löytänyt perusteluja sille, miksi pitäisi käyttää oletuksena olevaa BTRFS:ää."

        EXT4 pahin rajoitus on kai tiedostojen lukumäärä mitä ei voi kasvattaa jälkiteen. Raja voi tulla vastaan jos pienellä levyllä paljon tiedostoja. Normikäyttäjällä harvemmin paljon tiedostoja. BTRFS osaa paremmin käsitellä pieniä tiedostoja. Sisältö voidaan tallentaa hakemistorakenteenesen. tiedostoja voidaan pakata. Kopiosta tallennetaan vain yksi versio.

        Huvikseen voi testata tikulla. 100 000 pientä tiedostoa. Kaunanko kestää fat, ext4, XFS tai BTRFS. fat tallentaa nimet listaan ja listan luku aloitetaan aina alusta. Fat siitä rajoittunut, että sen juuren voi tallentaa vain vähän tiedostoja. Fat häviää melkoisesti ja ihme kun vielä käytössä.

        Esim Arch linux sisältää 69888 aur pakettia. BSD ports ja Gentoon portage sisältävät myös paljon pieniä tiedostoja jos joku väittää ettei tuollaiselle tiedostämäärälle ole käyttöä.

        Tiedostojen määrä EXT4 -tiedostojärjestelmässä riippuu sekä tiedostojärjestelmän koosta, että käytettävästä blokkikoosta, (block size) koska 'inode'jen määrä on rajallinen, ja suhteutettu lineaarisesti sekä tiedostojärjestelmän itsensä kokoon, että blokkikokoon (block size).

        Itse en ole koskaan onnistunut saamaan EXT4 -tiedostojärjestelmää täyteen tiedostojen määrällä, vaikka järjestelmässä on todella, todella paljon erilaista lähdekoodia myös, koska teen ristikäännöksiä eri alustoille.

        Asiaan vaikuttaa myös se, että käyttääkö 32 vai 64-bittistä ympäristöä, koska se tuo rajoitukset käytettävälle muistiavaruudelle ja muulle laskennalle, joka koskee myös osioita että tiedostojärjestelmiä.

        Aiemmin myös 64-bittisessä käyttöjärjestelmässä oli rajoituksia, kun oltiin siirtymässä 64-bittiseen osoitteistoon, ja itselläni on myös edelleen yksi aika iso "vanhaan aikaan" luotu levyjärjestelmä, joka piti jakaa useampaan osaan, koska koko tilan käyttöön ottaminen kerralla ei tuolloin vielä ollut mahdollista.


      • Anonyymi kirjoitti:

        Tiedostojen määrä EXT4 -tiedostojärjestelmässä riippuu sekä tiedostojärjestelmän koosta, että käytettävästä blokkikoosta, (block size) koska 'inode'jen määrä on rajallinen, ja suhteutettu lineaarisesti sekä tiedostojärjestelmän itsensä kokoon, että blokkikokoon (block size).

        Itse en ole koskaan onnistunut saamaan EXT4 -tiedostojärjestelmää täyteen tiedostojen määrällä, vaikka järjestelmässä on todella, todella paljon erilaista lähdekoodia myös, koska teen ristikäännöksiä eri alustoille.

        Asiaan vaikuttaa myös se, että käyttääkö 32 vai 64-bittistä ympäristöä, koska se tuo rajoitukset käytettävälle muistiavaruudelle ja muulle laskennalle, joka koskee myös osioita että tiedostojärjestelmiä.

        Aiemmin myös 64-bittisessä käyttöjärjestelmässä oli rajoituksia, kun oltiin siirtymässä 64-bittiseen osoitteistoon, ja itselläni on myös edelleen yksi aika iso "vanhaan aikaan" luotu levyjärjestelmä, joka piti jakaa useampaan osaan, koska koko tilan käyttöön ottaminen kerralla ei tuolloin vielä ollut mahdollista.

        Esim Gentoon asennusoppaassa varoitetaan tuosta jos tehdään pieni alle 8G levy. mkfs.ext4 -T small /dev/<device> auttaa. Kokeile 4G tikulla ja pistä sinne paljon tiedostoja. df -i näyttää itsellä, että parilla levyllä 22% käytössä. Paljon tiedostoja on 100 000 - 200 000. BTRFS kokeilematta, mutta luulisin sen olevan nopeampi


      • Anonyymi
        Mikko_Tku kirjoitti:

        Esim Gentoon asennusoppaassa varoitetaan tuosta jos tehdään pieni alle 8G levy. mkfs.ext4 -T small /dev/<device> auttaa. Kokeile 4G tikulla ja pistä sinne paljon tiedostoja. df -i näyttää itsellä, että parilla levyllä 22% käytössä. Paljon tiedostoja on 100 000 - 200 000. BTRFS kokeilematta, mutta luulisin sen olevan nopeampi

        Itse ainakin olen ollut jo pitkään tietoinen eri EXT<n> tiedostojärjestelmän (osion) koko vs. blokkikoko vs. tiedostojen määrä, eli kokeilut minulle ainakin riittää.

        En myöskään tässä vaiheessa enää lähde kokeilemaan XFS, kun en vaan ole sitä jostain syystä saanut pysymään ehjänä ja kunnossa, enkä myöskään ainakaan vielä lähde kokeilemaan BTRFS, sillä jo lukemani perusteella BTRFS on vähän kuin LVM, ja että siinä on jokin oma hallintatyökalu volumien jne. tekemiseen ja käsittelyyn, niin minulla saa toistaiseksi tämäkin jäädä, ainakin siihen asti kunnes asiasta kirjoitellaan enemmän eri foorumeilla, joita kautta sitten voi opiskella ja kerätä käyttäjien kokemuksia.

        Olen jo oppinut LVM niin hyvin että osaan komennot käytännössä jo ulkoa, ja en myöskään ole vielä löytänyt mitään syytä että miksi pitäisi vaihtaa tästä pois johonkin muuhun.

        Komento 'df -i' näyttää 'inode'jen statuksen, esim.:

        # df -i
        Filesystem Inodes IUsed IFree IUse% Mounted on
        devtmpfs 8215102 1142 8213960 1% /dev
        tmpfs 8220153 1 8220152 1% /dev/shm
        tmpfs 819200 3152 816048 1% /run
        /dev/dm-4 3276800 711760 2565040 22% /
        tmpfs 409600 59 409541 1% /tmp
        /dev/md126 65408 113 65295 1% /boot
        /dev/sda1 0 0 0 - /boot/efi
        /dev/dm-6 3276800 267478 3009322 9% /home
        tmpfs 1644030 229 1643801 1% /run/user/1000
        /dev/mapper/md0_2 61038592 29 61038563 1% /mnt/md0

        Myönnän kyllä että en ehkä sitten osannut parametroida XFS oikein kun se oli jatkuvasti minulla solmussa, ja en lähde vielä ainakaan vähään aikaan opettelmaan BTRFS .


      • Anonyymi
        Mikko_Tku kirjoitti:

        "Järjestelmäosion alustin EXT4:ään, koska en oikein ole löytänyt perusteluja sille, miksi pitäisi käyttää oletuksena olevaa BTRFS:ää."

        EXT4 pahin rajoitus on kai tiedostojen lukumäärä mitä ei voi kasvattaa jälkiteen. Raja voi tulla vastaan jos pienellä levyllä paljon tiedostoja. Normikäyttäjällä harvemmin paljon tiedostoja. BTRFS osaa paremmin käsitellä pieniä tiedostoja. Sisältö voidaan tallentaa hakemistorakenteenesen. tiedostoja voidaan pakata. Kopiosta tallennetaan vain yksi versio.

        Huvikseen voi testata tikulla. 100 000 pientä tiedostoa. Kaunanko kestää fat, ext4, XFS tai BTRFS. fat tallentaa nimet listaan ja listan luku aloitetaan aina alusta. Fat siitä rajoittunut, että sen juuren voi tallentaa vain vähän tiedostoja. Fat häviää melkoisesti ja ihme kun vielä käytössä.

        Esim Arch linux sisältää 69888 aur pakettia. BSD ports ja Gentoon portage sisältävät myös paljon pieniä tiedostoja jos joku väittää ettei tuollaiselle tiedostämäärälle ole käyttöä.

        ..."Fat häviää melkoisesti ja ihme kun vielä käytössä."...

        FAT on edelleen käytössä koska siitä on tullut ns. 'de facto', ja mm. digikamerat ja muut vastaavat käyttävät tätä muistikorteissa edelleen, koska se (FAT) on suoraan tuettu eri käyttöjärjestelmissä.

        On ollut puhetta ja kirjoittelua kameravalmistajien keskuudessa tätä korvaavasta tiedostojärjestelmästä, mutta jonkun pitäisi ottaa siitä vastuu, ja huolehtia samalla siitä että se sitten myös toimii aina ja kaikkialla, mikä tuskin tulee tapahtumaan.

        Microsoft lisäksi lisensoi FAT -tiedostojärjestelmää laitevalmistajien käyttöön, kuten mm. juuri digikameroihin, että muistikortit saa formatoitua ja tallennettua niihin kuvia, ja kuvat näkyviin tietokoneissa...

        FAT -tiedostojärjestelmästä on myös helppo palauttaa tietoja, jos jotain sattuu hukkumaan...


      • Anonyymi kirjoitti:

        ..."Fat häviää melkoisesti ja ihme kun vielä käytössä."...

        FAT on edelleen käytössä koska siitä on tullut ns. 'de facto', ja mm. digikamerat ja muut vastaavat käyttävät tätä muistikorteissa edelleen, koska se (FAT) on suoraan tuettu eri käyttöjärjestelmissä.

        On ollut puhetta ja kirjoittelua kameravalmistajien keskuudessa tätä korvaavasta tiedostojärjestelmästä, mutta jonkun pitäisi ottaa siitä vastuu, ja huolehtia samalla siitä että se sitten myös toimii aina ja kaikkialla, mikä tuskin tulee tapahtumaan.

        Microsoft lisäksi lisensoi FAT -tiedostojärjestelmää laitevalmistajien käyttöön, kuten mm. juuri digikameroihin, että muistikortit saa formatoitua ja tallennettua niihin kuvia, ja kuvat näkyviin tietokoneissa...

        FAT -tiedostojärjestelmästä on myös helppo palauttaa tietoja, jos jotain sattuu hukkumaan...

        "FAT on edelleen käytössä koska siitä on tullut ns. 'de facto', ja mm. digikamerat ja muut vastaavat käyttävät tätä muistikorteissa edelleen, koska se (FAT) on suoraan tuettu eri käyttöjärjestelmissä."
        FAT versioita useita erilaisia ja kaikkia niitä ei tueta. Esim exFAT on tuettu harvemmissa laittseissa, mutta tärkeä jos isoja tiedostoja.

        Kameralla voidaan räpsiä paljonkin ruutuja ja yli 1000 kuvaa samassa kansiossa hidastaa kovasti. Kun tiedostot talletetaan linkitettyyn listaan. Onneksi moni kamera osaa itse tehdä uusia kansioita automaattisesti. Isoilla RAW-kuvilla kuvaus hidastuu rajusti ja kun puskuri täynnä pitää odotella, että kuvat on kirjoitettu kortille.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "FAT on edelleen käytössä koska siitä on tullut ns. 'de facto', ja mm. digikamerat ja muut vastaavat käyttävät tätä muistikorteissa edelleen, koska se (FAT) on suoraan tuettu eri käyttöjärjestelmissä."
        FAT versioita useita erilaisia ja kaikkia niitä ei tueta. Esim exFAT on tuettu harvemmissa laittseissa, mutta tärkeä jos isoja tiedostoja.

        Kameralla voidaan räpsiä paljonkin ruutuja ja yli 1000 kuvaa samassa kansiossa hidastaa kovasti. Kun tiedostot talletetaan linkitettyyn listaan. Onneksi moni kamera osaa itse tehdä uusia kansioita automaattisesti. Isoilla RAW-kuvilla kuvaus hidastuu rajusti ja kun puskuri täynnä pitää odotella, että kuvat on kirjoitettu kortille.

        Itse olen havainnut että muistikortilla itsellään on mitä suurin merkitys tässä nopeudessa, jo kuluneen vajaan 20 vuoden kokemuksella. Yksi ensimmäisistä CF -muistikorteista jonka ostin, oli mainoksen mukaan 133x -nopeuksinen, Transcendin kortti, ja se hävisi nopeudeltaan parille muulle kortille, kuten SanDisk PRO -kortit...

        Ja samaa linjaa on ollut myös pokkarikameroiden SD -korttien kanssa.

        En ymmärrä mitä tekemistä linkitetyllä listalla ja FAT -tiedostojärjestelmällä on keskenään...?

        En myöskään ole koskaan onnistunut saamaan 10.000 kuvaa yhdelle ja samalle kortille, sillä itse otan kaikki kuvat juuri nimenomaisesti RAW -formaatissa, jälkikäsittelyä varten...

        On se toki selvää että jos ottaa vain kooltaan pieniä JPG -pakattuja kuvia ensin sarjatulella, ja sitten käy niitä kamerassa läpi, ja poistelee sieltä muutamia sieltä täältä, niin MIKÄ TAHANSA tiedostojärjestelmä FRAGMENTOITUU ja HIDASTUU.

        Itse vedän aina muistikortteja täyteen, vaihdan uuden kameraan kun on täynnä, ja sitten illalla kaikki koneeseen ja formatoidaan kortit seuraavaa päivää varten.

        Media(t) ei tänä päivänä maksa, ja ole maksaneet, paljon mitään, niin turha säästää ja kikkailla.

        Olen monta kertaa törmännyt mummoihin ja pappoihin jotka haluavat "säästää rahaa", ja sitten lastenlasten synttäri-, kevät- yms. juhlissa käyvät kameraa kiivasti läpi että "mitä kuivia täältä nyt voisi poistaa että voidaan ottaa kuvia kun <xxxxxxx> ..."

        Mutta kukin tyylillään...


      • Anonyymi kirjoitti:

        Itse olen havainnut että muistikortilla itsellään on mitä suurin merkitys tässä nopeudessa, jo kuluneen vajaan 20 vuoden kokemuksella. Yksi ensimmäisistä CF -muistikorteista jonka ostin, oli mainoksen mukaan 133x -nopeuksinen, Transcendin kortti, ja se hävisi nopeudeltaan parille muulle kortille, kuten SanDisk PRO -kortit...

        Ja samaa linjaa on ollut myös pokkarikameroiden SD -korttien kanssa.

        En ymmärrä mitä tekemistä linkitetyllä listalla ja FAT -tiedostojärjestelmällä on keskenään...?

        En myöskään ole koskaan onnistunut saamaan 10.000 kuvaa yhdelle ja samalle kortille, sillä itse otan kaikki kuvat juuri nimenomaisesti RAW -formaatissa, jälkikäsittelyä varten...

        On se toki selvää että jos ottaa vain kooltaan pieniä JPG -pakattuja kuvia ensin sarjatulella, ja sitten käy niitä kamerassa läpi, ja poistelee sieltä muutamia sieltä täältä, niin MIKÄ TAHANSA tiedostojärjestelmä FRAGMENTOITUU ja HIDASTUU.

        Itse vedän aina muistikortteja täyteen, vaihdan uuden kameraan kun on täynnä, ja sitten illalla kaikki koneeseen ja formatoidaan kortit seuraavaa päivää varten.

        Media(t) ei tänä päivänä maksa, ja ole maksaneet, paljon mitään, niin turha säästää ja kikkailla.

        Olen monta kertaa törmännyt mummoihin ja pappoihin jotka haluavat "säästää rahaa", ja sitten lastenlasten synttäri-, kevät- yms. juhlissa käyvät kameraa kiivasti läpi että "mitä kuivia täältä nyt voisi poistaa että voidaan ottaa kuvia kun <xxxxxxx> ..."

        Mutta kukin tyylillään...

        "En ymmärrä mitä tekemistä linkitetyllä listalla ja FAT -tiedostojärjestelmällä on keskenään...?"

        Fat tallentaa tiedostojen nimet listaan. Siitä haku on hidasta. Aloitetaan listan ensimmäisestä nimestä, sitten seuraava, ... jos lista on pitkä tiedoston löytyminen kestää. Nykyisissä tiedostojärjestelmissä on on kehittynyt haku esim. binaaripuusta. hakuaika on oleellisesti lyhyempi. Pienillä tiedostoilla - jos niitä on paljon menee enemmän aikaa listan käsittelyyn kuin itse tiedoston tallentamiseen tai lukemiseen. Voi kestää niin kauan, että voi käydä vaikka baarissa ottamassa muutaman oluen.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "En ymmärrä mitä tekemistä linkitetyllä listalla ja FAT -tiedostojärjestelmällä on keskenään...?"

        Fat tallentaa tiedostojen nimet listaan. Siitä haku on hidasta. Aloitetaan listan ensimmäisestä nimestä, sitten seuraava, ... jos lista on pitkä tiedoston löytyminen kestää. Nykyisissä tiedostojärjestelmissä on on kehittynyt haku esim. binaaripuusta. hakuaika on oleellisesti lyhyempi. Pienillä tiedostoilla - jos niitä on paljon menee enemmän aikaa listan käsittelyyn kuin itse tiedoston tallentamiseen tai lukemiseen. Voi kestää niin kauan, että voi käydä vaikka baarissa ottamassa muutaman oluen.

        Tuossa toteat että,

        ..."jos lista on pitkä tiedoston löytyminen kestää."...

        Mitä ei tapahdu silloin kun käytetään linkitettyjä listoja, sillä näiden kanssa käytetään aina puolittaishakua, jolloin haettava tieto löytyy aina samassa ajassa, aivan riippumatta siitä että kuinka monta tietuetta listassa on.


      • Anonyymi kirjoitti:

        Tuossa toteat että,

        ..."jos lista on pitkä tiedoston löytyminen kestää."...

        Mitä ei tapahdu silloin kun käytetään linkitettyjä listoja, sillä näiden kanssa käytetään aina puolittaishakua, jolloin haettava tieto löytyy aina samassa ajassa, aivan riippumatta siitä että kuinka monta tietuetta listassa on.

        "Mitä ei tapahdu silloin kun käytetään linkitettyjä listoja, sillä näiden kanssa käytetään aina puolittaishakua, jolloin haettava tieto löytyy aina samassa ajassa, aivan riippumatta siitä että kuinka monta tietuetta listassa on."

        Puolittaishaku ei onnistu. Hakuaika on O(n). Eli lista luetaan aina alusta. Puolitushaussa hakuaika on O(log n). Tyhjää tilaa ei myöskään tallenteta vaan sen takia on koko fat-taulukko luettava läpi. Paremmissa systeemeissä käytetää B-puita ym ja hakuaika on parempi kuin O(log n). Kovalevyllä kun voi olla paljon tiedostoja. Itsellä liki 400 000 juuressa. Toki useampi levy. Jo kernelin sorsien lähdepuu lähentelee 100 000 tiedostoa. Noita kun purkaa muutaman tikulle huomaa kyllä fat-järjestelmän hitauden.


      • Anonyymi
        Mikko_Tku kirjoitti:

        "Mitä ei tapahdu silloin kun käytetään linkitettyjä listoja, sillä näiden kanssa käytetään aina puolittaishakua, jolloin haettava tieto löytyy aina samassa ajassa, aivan riippumatta siitä että kuinka monta tietuetta listassa on."

        Puolittaishaku ei onnistu. Hakuaika on O(n). Eli lista luetaan aina alusta. Puolitushaussa hakuaika on O(log n). Tyhjää tilaa ei myöskään tallenteta vaan sen takia on koko fat-taulukko luettava läpi. Paremmissa systeemeissä käytetää B-puita ym ja hakuaika on parempi kuin O(log n). Kovalevyllä kun voi olla paljon tiedostoja. Itsellä liki 400 000 juuressa. Toki useampi levy. Jo kernelin sorsien lähdepuu lähentelee 100 000 tiedostoa. Noita kun purkaa muutaman tikulle huomaa kyllä fat-järjestelmän hitauden.

        Jos puolittaishaku linkitetyssä listassa "ei onnistu", niin sitten kyseessä on vain tasan kaksi selittävää syytä, joista ei voi poiketa, muuten kuin ohjelmointivirheen johdosta:

        1) tietoa ei ole (enää/alunperin ollutkaan) olemassa
        2) lista (tietokanta) on korruptoitunut

        Jos linkitetyssä listassa on vaikka 500 tietuetta (lukua), ja valitsee luvun 1 ja sitä kun lähdetään puolittaishaulla iteroimaan niin:

        1) 500<
        2) 250<
        3) 125<
        4) 62<
        5) 31<
        6) 15<
        7) 7<
        8) 3<
        9) 2< tai suoraan 1
        10) == 1 viimeistään

        ...aina iteraation tulos on viimeistään 10, ja samaa tulee jos valitsee luvun 500, niin iterointi on sama mutta nousevaan suuntaan...

        Ja jos tässä vielä muuttaa:

        5) 31<
        6) 16<
        7) 8<
        8) 4<
        9) 2<
        10) == 1

        Niin edelleen iteraatioita on 10.

        Ja otetaan malliksi vielä vaikka luku 365:

        1) 500<
        2) >250
        3) 375<
        4) >313
        5) >345
        6) >361
        7) 369<
        8) == 365

        Edelleen väitän että FAT ei ole mikään linkitetty lista, vaan vain pino tai jono, jota iteroidaan tietue kerrallaan kunnes oikea tieto löytyy.

        DOSiin yms. oli saatavana erilaisia välimuistiohjelmia nopeuttamaan tiedostojärjestelmän suorituskykyä.

        Ja jos on todella niin per*ssi että lähtee purkamaan jotain Linuxin kerneliä FAT -tiedostojärjestelmään USB -tikulle, niin luulen että ensimmäinen pullonkaula on se USB-tikku itse, eikä suinkaan FAT...

        Ja vielä kun FAT tukee vain 8 3 merkin tiedostojen ja hakemistojen nimiä, niin onnea sitten vaan sen FAT -osiolle puretun kernelin kanssa...


    • Anonyymi

      Ennenkaikkea, Ubuntu ei ole pakollinen missään olosuhteissa!

      • Anonyymi

        Minulta se ainakin on säästänyt hermoja, kun "isot" päivitykset jotka rikkoo koneen jää historiaan - aina voi valita vanhemman kernelin esim. käynnistyksessä, jos joskus sattuisi tulemaan viallinen päivitys vastaan. Ubuntun päivitykset on aika hyvin testattu nykyjään ja harvemmin tulee laitteisto-komboja vastaan, missä ei geneerinen kerneli toimisi.


      • Anonyymi

        Windows ei ole pakollinen missään olosuhteissa! Ja turhaan poistat tätä viestiä koska siinä EI ole mitään asiatonta!


      • Anonyymi
        Anonyymi kirjoitti:

        Minulta se ainakin on säästänyt hermoja, kun "isot" päivitykset jotka rikkoo koneen jää historiaan - aina voi valita vanhemman kernelin esim. käynnistyksessä, jos joskus sattuisi tulemaan viallinen päivitys vastaan. Ubuntun päivitykset on aika hyvin testattu nykyjään ja harvemmin tulee laitteisto-komboja vastaan, missä ei geneerinen kerneli toimisi.

        Kuinka windowsin käynnistyksessä voi valita windowsin vanhemman kernelin....? Mistä ylipäätään tietää tai voi saada selville että windowsin kernel päivittyy päivityksen yhteydessä....?


      • Anonyymi

        "Ennenkaikkea, Ubuntu ei ole pakollinen missään olosuhteissa!"

        VÄÄRIN SANOTTU, täytyy sanoa todenmukaisesti:
        Ennen kaikkea, Ubuntua ei voi suositella missään olosuhteissa!


      • Anonyymi
        Anonyymi kirjoitti:

        "Ennenkaikkea, Ubuntu ei ole pakollinen missään olosuhteissa!"

        VÄÄRIN SANOTTU, täytyy sanoa todenmukaisesti:
        Ennen kaikkea, Ubuntua ei voi suositella missään olosuhteissa!

        Väärin meni jälleen, Windowsia ei voi suositella missään olosuhteissa, Ubuntua taas voi!


    • Anonyymi

      Ubuntun asentaminen koneelle on sama kuin ottaisi autostaan kumit pois vanteilta.

      • Anonyymi

        Valitettavasti isäsi ei käyttänyt kumia.


      • Anonyymi

        Kaikki nyt vaan ei osaa, edes kumien kanssa...


      • Anonyymi

        Olipa se osuva vertaus, olen täysin samaa mieltä.


    • Anonyymi

      Ei ole, eikä ole ollutkaan, missään vaiheessa. Ubuttajat eivät näistä asioista muuta ymmärrä kuin sen minkä laitamme painikkeisiin näkymään.

    Ketjusta on poistettu 6 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. Milloin olet viimeksi nähnyt

      Kaivattusi ja missä? Onko ikävä vastaa rehellisesti.
      Ikävä
      132
      2081
    2. Onpas punavihreät taas ärhäkkäinä

      😺 Ihan tuntuu kuin syyttäisitte meikäläisiä/meikäläistä Oulun puukotuksesta. Tapaus on hyvin ikävä ja tuomittava. En
      Luterilaisuus
      375
      1558
    3. Hauskaakin jopa...

      Että moni nainen olettaa, että kyse on vaan siitä kaanustinloukusta, kun mies jotain ehdottaa. 😄 Ja miettiikö monikaan
      Sinkut
      227
      1166
    4. Nainen, minkä kappaleen laittaisit nyt miehelle

      kuunneltavaksi tietäen, että hän ikävöi sinua ja kipuilee päästäkseen yhteyteen kanssasi. Jotain, joka kertoo...
      Ikävä
      108
      972
    5. Koen, että minua tavallaan vainotaan

      Kyllä minä vain satun tietämään, että täälläkin on joitain serkun kaiman kummeja jotka kiusaavat minua. Lisäksi sairas n
      Ikävä
      126
      959
    6. Toivottavasti vielä kohdataan mies

      Ja aloitetaan juttelu. Nyt olisin valmis.
      Ikävä
      92
      933
    7. Vanhemmalle naiselle

      Aikataulu muutos. Ensi viikolla pistetään asia vireille. Ei juhannukseen asti aikaa. Kannatti valehdella!
      Ikävä
      55
      918
    8. Herätänkö minä sinut itkullani nainen

      Kysyn tässä kun kaipuun aallot lyövät ylitseni ja ihmettelen missä olet toivoessani, että olisit tässä vierelläni. On va
      Ikävä
      25
      848
    9. Vastaa nyt kun kuitenkin valvot!

      Vai pelkäätkö että miehesi herää? Ppm:lle 😉
      Ikävä
      111
      798
    10. Pimahdan kohta ihan kunnolla

      Entä, jos otan sitten yhteyttä sinuun? 🫨🫥🥴
      Ikävä
      20
      764
    Aihe