Näytä kirjoitukset

Tässä osiossa voit tarkastella kaikkia tämän jäsenen viestejä. Huomaa, että näet viestit vain niiltä alueilta, joihin sinulla on pääsy.


Aiheet - Ux64

Sivuja: 1 2 [3] 4
41
http://www.tietokone.fi/uutta/uutinen.asp?news_id=36622&tyyppi=1
Lainaus
Xeonia käyttävien palvelinkoneiden kannalta asia on mielenkiintoinen. Tavallinen kahden prosessorin peruspalvelin tarjoaisi käyttöjärjestelmälle näin ollen 32 säiettä, eli ohjelmien kannalta kyseessä on 32 prosessorin kone.

Tätähän on kyllä ounasteltu tekniikkapiireissä pitkään. Kysymys onkin siitä, miten ohjelmointityökalujen pitää muuttua. Aina vain on sanottu, että ei se vielä ja kyllä vielä pärjää. Mutta entäs kun prosessorien määrän kasvu jatkaa Mooren lain mukaan?

Ainakin vanhalla ajattelumallilla tehdyt sovellukset putoaa auttamattomasti kelkasta. Omissa sovelluksissani käyttämäni pipelining / assembly line tekniikka putoaa myös, koska se vaatii ohjelmoijalta työtä suorittavien yksikköjen luomiseen.

Miten siis kirjoittaa sovellus joka hyödyntää tehokkaasti esimerkiksi tuhatta tai kahtatuhatta prosessoriydintä? Ja ettei jäädä alkukuoppiin niin lisätään noihin vielä nolla perään.

Ainakin ensimmäinen asia joka on aivan selvää on se, että tuo on huomioitava ohjelmien suunnittelussa. Python GIL on ainakin ongelma, samoin virtuaalikoneen GC, joka ei välttämättä kykene hoitamaan asiaa täysin rinnakkaisesti pyörivien sovellusten kanssa.

Mitä muuta, olennaista olen tässä unohtanut?

Jos siltä tuntuu tän saa toki siirtää tänne: Ohjelmointi, palvelimet ja muu edistyneempi käyttö

42
https://jdk6.dev.java.net/6uNea.html

No niin! Vihdoinkin, nyt pitäisi saada siis oikeasti 64 bittinen java toimiman myös selaimen kanssa ongelmitta (?) ja päästä icedteasta eroon. IcedTean kanssa, ainakin monissa siteissä mulla java kaatui jo "applet is being initialized" kohdassa.

Kokemuksia hieman myöhemmin tänään kun pääsee oikeasti testaamaan. ;)

43
Avaan network configurationin, otan sieltä eth0:n, syötän IPV4 osoitteen, gatewayn, maskin ja dns:n.

Painan ok ja sen jälkeen close ikkunoihin.

ifconfig näyttää edelleen vanhaa DHCP:llä saatua osoitetta. Puuttuuko systeemissä jossain vaiheessa joku "refresh" kutsu joka muuttaisi tuon asetuksen kun se on käyttöliittymästä muutettu?

Yritin myös sudo ifdown ja sudo ifupit, joiden kuulemma (joku websivu) mukaan pitäisi laukaista dhcp:n uusiminen / verkkotietojen päivittäminen. Ei vaikutusta. Laitoin taikaisin DHCP:lle, boottasin koneen ja nyt sain vasta uudesta networkista IP:n. Teinkö siis itse jotain totaalisen väärin, vai puuttuuko jostain olennainen triggeri kun painan ok tuohon IPV4 manual asetus ruutuun?

Jos vika on käyttäjässä, niin jotain on jäänyt kyllä huomaamatta. Mutta sehän ei olisi mitään uutta.

44
Morjens!

Tietääkö kukaan miten VLC:n saisi käyttämään fiksumpaa methodia kuin klassista "pixel resizeä". Esim cubic tai Sinc tekisivät aivan huimasti parempaa jälkeä skaalauksessa.

Kiitos!

45
Mielestäni mielenkiintoinen artikkeli

Lainaus
Ubuntu 7.04 to 8.10 Benchmarks: Is Ubuntu Getting Slower?

Major slowdowns after Ubuntu 7.04 "Feisty Fawn" in so many different tests certainly weren't what we had expected.

http://www.phoronix.com/scan.php?page=article&item=ubuntu_bench_2008&num=1

46
Laitealue / Satunnaiset boot failuret
« : 22.10.08 - klo:15.50 »
Ajoittain bootti failaa ja jää jumiin.

Tarkka virheilmoitus (kuva):
http://picozilla.com/en/192749/ubuntuongelmia.jpeg.html

Lyhyesti ongelma johtuu ongelmista IRQ 19:n kanssa. Tuntuu liittyvän varmaan tähän IP35 emolevyyn? Ilmeisesti mitään kovin kätevää ratkaisua tuohon ongelmaan ei ole. Ongelma ilmenee ehkä kerran 50 bootista, eli joku Timing issue tms?

47
Tervehdys,

Nyt on mielenkiintoinen ongelma. Eli jostain syystä päänäytöllä (kaksi näyttöä käytössä) aukeaa ikkunat noin sekunnin viiveellä. Käytössä tämä on todella raivostuttava feature. Mutta suuresti ihmetyttää se mistä, moinen voi johtua?

Pitäisi varmaan kysyä ubuntuforumssista jos löytyisi guruja sieltä. Mutta eihän sitä koskaan tiedä vaikka olisi vähän yleisempi ominaisuus.

Eli käytössä Nvidia 8500GT ja Gutsy Gibbon 64bit. Asiaan ei vaikuta se onko näytöt erillisinä vai yhtenä isona työpöytänä.

Kun avaan minkä tahansa valikon, vaikka selaimesta, "ubuntu menun" tai vaikka tästä tekstistä valikkoikkunan oikealla hiirennapilla. Kestää ikkunan aukeaminen aina noin sekunnin. Niin omituista kuin se onkin. Koitin asiasta jo googlata noin puolisentuntia, enkä löytänyt mitään ongelmaan viittaavaa keskustelua.

Ideoita?

 - Kiitos!

Mielestäni ei ole kyse multimediasta, eikä laitealueestakaan. Epäilen vian piilevän jossain rutiinissa joka liittyy noiden ikkunoiden luomiseen tavalla tai toisella.

48
Multimedia ja grafiikka / VLC 0.9.2
« : 16.09.08 - klo:20.11 »
VLC 0.9.2 on sitten julkaistu. Eipä tullut vielä Ubuntun päivitysten kautta, vaikka pitäisi tulla.

http://www.videolan.org/vlc/download-ubuntu.html

Anyway, minua kiinnostaa eniten, onko vihdoinkin ongelma h.264 videoiden poistossa korjattu. Eli filtterit jne, on tehty(?) multi threadaaviksi. Kukaan ei VLC foorumissakaan ole osannut vastata ongelmaan. Useimmiten annetaan ohje, että ota filtterit pois päältä -> kuvan laatu laskee. Oikea ratkaisu olisi segmenteissä jakaa kuva eri coreille, jolloin tehoa olisi jakaa muillekkin, vaikka lampaat söisi.

Onko kukaan ehtinyt / päässyt kokeilemaan onko ongelma vihdoin pois päiväjärjestyksestä. Tuo oli siis omalta osaltani sarjassa yksi polttavia Linux/Ubuntu ongelmia.

 - Kiitos!

49
Tässä on nyt reilusti ylikuukausi ihmetelty miksi kuvanlaatu on niin huono. Syyksi selvisi linuxi. Olen koittanut vaikka kuinka säätää kuvaa ja kuvaa ei saa linuxilla kuntoon.

Onko multimedia nyt se viimeinen naula arkkuun, joka pakottaa ostamaan Vistan? Jos joku sanoo, että vista maksaa. Niin voin tähän kommentoida sen verran, että kuvan säätäminen on maksanut varmasti jo 3-6 kertaa Vistan verran.

Kenelläkään ei näytä olevan ongelmaan ratkaisua. Testasin vistaa ja  ongelma ratkesi 15 minuutissa, sisältäen kuvan tarkan säätämisen kuntoon.

http://www.nvnews.net/vbulletin/showthread.php?t=117936

Nyt tulee sitten ratkaisu tai Vista koneeseen, niin vastenmielinen ajatus kuin se tavallaan onkin.

 - Kiitos, alkaa sarvi kasvamaan. ;(

50
Näytönohjaimena NVIDIA 8500GT, Ubuntuna 64 bit Hardy Heron.

Hirveän säätämisen jälkeen tilanne on nyt hallinnassa. Eli molemmat screenit toimivat ja tv:lle menee myös full hd kuva. Jos joku haluaa tarkempaa selvitystä aiheesta voin pistellä hieman xorg.conf:ia ja .nvidia-settings-rc tiedoston leikkeitä tulemaan.

Jäljellä oleva ongelma on kontrastin säätäminen kakkos screenille, joka ei onnistu käyttöliittymän kautta. Enkä onnistunut sitä tekemään asetustiedostonkaan kautta. Ilmeisesti teen jotain väärin, mutta mitä?

http://img139.imageshack.us/my.php?image=settingsoi2.png

Eli tuon näytön yksi (kakkosnäyttö, fullhd tv) asetuksia pitäisi päästä muokkaamaan.

Tällaisia asetuksia on nyt tiedostossa. Arvot ovat tarkoituksella tolkuttoman suuria, että varmasti huomaa kun ne alkavat vaikuttaa.

Koodia: [Valitse]
1/RedContrast=-0.500000
1/GreenContrast=-0.500000
1/BlueContrast=-0.500000

Olen testannut luonnollisesti vaihtoehdot prefixeissä 0/ 1/ 0.1/ 1.0/ 1.1/.

Koodia: [Valitse]
ERROR: Invalid X Screen 1 specified on line 57 of configuration file
       '.nvidia-settings-rc' (there is only 1 X Screen on this
       Display).

Eipä löytynyt Ubuntu Forumssistakaan vastausta, joten uusi lanka on sitten täällä:
http://ubuntuforums.org/showthread.php?t=887762

Olisi todella hienoa jos joku osaisi vihjata mitä tuohon nvidia-settings-rc tiedostoon pitää tuupata.

- Kiitos!

En ole näköjään ainoa: http://www.osnews.com/thread?237647 ;)

51
Kirjoittelinkin tästä jo toisaalla UbuntuForumssissa ja täällä. Mutta ehkä täältä laitealueelta löytyy parempia osaajia. Tosin en ole lainkaan varma onko tämä laiteongelma.

Ongelma on lyhyesti se, että näppäimistö ja hiiri lakkaavat toimimasta yhtäkkiä. Näppis ja hiiri on kytketty PS/2 porttiin emolle suoraan. Ongelma ilmeni vasta Hardy 8.04 päivityksen myötä, Feistyllä ongelmaa ei samalla raudalla ollut.

Raudasta sen verran, että käytössä on luotettava vanha hiiri ja näppis jotka ovat toimineet pitkään ja hartaasti. Emolevynä on Abit IP35-E jossa siis Intel P35 piirisarja ja Awardin bios v16, jonka päivitin juuri v18 versioon kun sanottiin että se voisi vaikuttaa asiaan. Ilmeisesit ongelmat kuitenkin BIOSin osalta koskevat pääasiassa Foxconnin lankkuja joissa oli jonkun muun kuin Awardin BIOS.

Ongelma ilmenee siis yleensä mutu tuntumalla silloin kun järjestelmässä on IO kuormaa ja järjestelmä on ollut käytössä muutaman tunnin. Usein miten ongelma ilmenee esim silloin kun on verkkolatauksia käynnissä, jotain muuta taustalla mm. vlc toistamassa mediaa ja selaimessa on useita tabeja -> aktiivista hiiren käyttöä ja verkosta lataamista, välimuistiin tallentamista tms. Yhtäkkiä hiiri ja näppäimistö halvaantuvat. Kone on käytettävissä SSH:lla ja myös virtanapin painaminen johtaa normaaliin shutdowniin. Eli ainakaan ns. hardis jumituksesta (muisti, prossu tms) tai kernelin täydellisestä kosahtamisesta ei ole kyse.

ACPI:tä on epäilty ongelman lähteeksi ja jotkut myös suosittelevat IRQPOLL option käyttämistä. Noita olen kokeilemassa seuraavaksi. Ideoita ja ehdotuksia otetaan mielellään vastaan.

Tässä linkki aikaisempaan ketjuun tuolla Ubuntun käyttö puolella:
http://forum.ubuntu-fi.org/index.php?topic=12999.0

 - Kiitos!

52
Asiantuntijoilta otetaan vastaan kysymyksiä ja aatteita. Mä en tämän tarkempaa analyysiä tehnyt. Mutta vaikuttaa siltä, että vika on käyttiksen verkkopuolella tms.

Ongelma lyhyesti. DNS tuntuu joskus järjettömän hiltaalta. Samoin jos koneessa toimii torrent (deluge), niin yhteys on välillä tolkuttoma hidas. Eikä tämä todellakaan johdu siitä että yhteys olisi tukossa kumpaanakaan suuntaan. Onko vika siis linux kernelissä joka ei osaa hanskata 100 rinnakaista tcp/ip yhteyttä? En kyllä oikein usko, muuten olisi serveri käytössä Win'95 tasolla.

Kysymys onkin siinä, että mikä tuon tahman voisi aiheuttaa? Onko Elisan netti jotenkin jumissa, DNS jumissa, onko Linuxissa jotain tunnettua vikaa? Onko Delugessa jotain tunnettua vikaa? En oikein itse saa kiinni siitä mistä ongelma johtuu.

Huippu mielenkiintoista, system monitor näyttää että 10% kapasiteetista on käytössä. Mutta pingi kertoo että yhteys on täysin tukossa. Humm..

Tarkistetaan vielä lennossa toi ADSL:n status, linja ok täys nopeus, ei crc virheitä, snr ja attenuation marginaalit ok.

Lopetin torrentin, pingi edelleen täysin jumissa. Outoa.

Firestarter näyttää kasan yhteyksiä joiden olisi pitänyt sulkeutua Delugen sulkemisen yhteydessä, jotka roikkuu auki. Tietysti palomuurin toimintaperiaatteesta riippuen tämä on enemmän tai vähemmän normaalia.

Koodia: [Valitse]
WTF?
64 bytes from 192.168.0.254: icmp_seq=11 ttl=64 time=92535 ms
64 bytes from 192.168.0.254: icmp_seq=12 ttl=64 time=92536 ms
64 bytes from 192.168.0.254: icmp_seq=14 ttl=64 time=91531 ms
64 bytes from 192.168.0.254: icmp_seq=107 ttl=64 time=464 ms
64 bytes from 192.168.0.254: icmp_seq=18 ttl=64 time=89528 ms
64 bytes from 192.168.0.254: icmp_seq=108 ttl=64 time=463 ms
64 bytes from 192.168.0.254: icmp_seq=109 ttl=64 time=460 ms
64 bytes from 192.168.0.254: icmp_seq=111 ttl=64 time=447 ms
64 bytes from 192.168.0.254: icmp_seq=25 ttl=64 time=86516 ms
64 bytes from 192.168.0.254: icmp_seq=114 ttl=64 time=444 ms

Ongelma poistui kuin poistuikin, koneen bootilla. Ei ADSL modemin...

Eli käyttiksen puolella jotain todella hämärää vikaa. IMHO. Koska oli mikä tahansa realistinen kuormitus internettiin, niin 100 meganen full duplex yhteys modemin ja koneen välillä EI VOI olla noin tukossa. Ja huom. Modemi on sitten normaalisti siltaavassa tilassa, eli kyse ei ole myöskään modemin ylikuormittumisesta jolta tuo olisi tietysti voinut näyttää.

No tulipahan samalla leikkiessä päivitetty ADSL modemin firmis. ;)

Kellään vastaavia kokemuksia? Hieman outoa kyllä.

Jossain vaiheessa epäilin "syn limittiä" niin kuin Windowssissa. Mutta sekin on järjetön rajoitus. Aiheuttaa kyllä juuri selaimen ärsyttävää jumittumista kun synit on käytetty ja selaimenkin pitäs avata vielä nippu HTTP yhteyksiä johonkin siteen.

KW: Netti jumittaa, Elisa, ADSL, Ubuntu, kernel, tcp/ip, torrent, DNS, transmission, bittorrent, hidas, jumitus, ei toimi, poikki, katki, puhki, deluge, 64 bit, hardy heron, ip35-e, intel

53
Yleistä keskustelua / Wikia haku käyttöön
« : 04.06.08 - klo:14.30 »
Wikia haku on avattu nyt yleisölle ja päivityksiä tarvitaan.

http://re.search.wikia.com/search.html#ubuntu

Tuo on jo jonkinlaisessa mallissa, mutta hienosäätämistä tarvitaan vielä.

http://re.search.wikia.com/search.html#ubuntu%20suomi

Jne.

Avoin yhteisö varmaan hoitaa päivitykset kuntoon. ;)

54
Eipä näytä toimivan kyllä kirveelläkään. ;(

Ali about plugins ei listaa javaa.

Java on kyllä asennettu ja toimii täysin.

Koodia: [Valitse]
java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode)

Plugin kytkennässä siis on ongelma. Mä kyllä toisaalta käsitin jostain ubuntuforumsin jutuista, että ei toimisi lainkaan.

Synaptic ei löydä sopivaa plugin pakettia, eikä firefoxikaan sitä tarjoa.

Ilmeisesti siis jotain ratkaisevaa tuosta kytkennästä puuttuu, mitä?

32 bittisen javan asennus olisi mahdollisesti ratkaissut ongelman, kuten kaikkien muiden mahdollisten JVM:n kokeilu. Mutta en haluaisi lähteä siihen. Todennäköisesti pikkujutusta kiinni kun sen vaan tietää. Tarkistin jo noita hardy 32bit version ohjeita. Mutta sieltäkään ei löytynyt mielestäni mitään ratkaisevaa informaatiota.

Java itsessään kyllä toimii mainiosti. Monessa ketjussa oli sotkettu javan toimimattomuus sailmeen. Mulla kyllä java toimii, mutta pluginin kautta selaimesta ei toimi.

 - Kiitos jo etukäteen




55
Kun ei noita lehtien testejä aina jaksa, niin tein oman testin. Tulos oli totaaisen järkyttävä.

Luodaan ensin ja sitten tuhotaan tuhotaan 10000 kpl 1 kilotavun (1024 bytes) kokoista tiedostoa samaan hakemistoon.
 
Ubuntu:
 
Process finished!  @  2008-05-10 19:59:18.138880
And it was started @ 2008-05-10 19:59:17.535340
Time used 0:00:00.603540 for processing 10000 files

Vistalla:
 
Process finished!  @  2008-05-11 08:37:08.289000
And it was started @ 2008-05-11 08:35:31.725000
Time used 0:01:36.564000 for processing 10000 files
 
Hervotonta! 160 kertaa hitaampaa tai nopeampaa riippuu kummin päin asiaa katsotaan.
 
Samalla raudalla ajettu testi dual boot ympäristössä. Eihän tuo voi olla totta, mutta on se vaan!
 
Eipä ole suotta Windowssin nopeutta kehuttu. ;)

En oikein tiennyt mihin tämän pistäisi niin pistin sitten tänne. Halukkaille on myös tarjolla python source.

56
Miksi oheinen koodi kuormittaa prosessoria vain 35% tasolla? Mielestäni siinä on neljä erillistä threadia jotka voivat toimia vapaasti toisistaan välittämättä. Prosessorina on Q6600. Jos sitten ajankin vain yhtä threadia niin se kyllä kuormittaa yksittäisen coren tappiin. Missä tuossa koodissa on se osuus joka vaatii syknronointia? Minä en sitä siitä löytänyt ainakaan nopeasti sen tarkemmin pythonin sielunelämää tuntematta.

Ainoa juttu mikä tulee nopeasti mieleen on se että cntr olisi synkronoitu. Mutta käsittääkseni sen pitäisi olla privaatti ja funktion / blokin sisäinen muuttuja.

Koodia: [Valitse]
import threading
from time import sleep, time
 
def loop(i, event):
    while not event.isSet():
      cntr = 0
      while cntr < 1000000:
        cntr += 1     
        store='handle some data etc.'
 
event = threading.Event()

print 'starting'
 
th1 = threading.Thread(target=loop, args=(1, event))
th1.start()
th2 = threading.Thread(target=loop, args=(2, event))
th2.start()
th3 = threading.Thread(target=loop, args=(3, event))
th3.start()
th4 = threading.Thread(target=loop, args=(4, event))
th4.start()

#Lisä testi threadit kun testasin 8 threadilla, ei vaikutusta.
#th11 = threading.Thread(target=loop, args=(1, event))
#th11.start()
#th12 = threading.Thread(target=loop, args=(2, event))
#th12.start()
#th13 = threading.Thread(target=loop, args=(3, event))
#th13.start()
#th14 = threading.Thread(target=loop, args=(4, event))
#th14.start()

print 'running...'

sleep(10)

print 'stop...'

event.set()
 
th1.join()
th2.join()
th3.join()
th4.join()

print 'end'


57
Tämä tuli eteen yllätyksenä.

Ainakin aikaisemmin kun valitin Nautiluksen sekoilusta suurilla tiedostomäärillä minulle sanottiin että käytä komentoriviä.

No päätin sitten käyttää komentoriviä ja lopputulos oli varsin huvittava.

Koodia: [Valitse]
~/tmp/file-test$ rm test_file_*
bash: /bin/rm: Argument list too long

Mitenhän tuollainenkin ongelma on päässyt jäämään tuonne. Lienee joku legacy tekniikkaan perustuva ongelma.

58
Yleistä keskustelua / IPSEC on painajainen(?)
« : 06.05.08 - klo:19.05 »
Onko muilla kokemusta IPSEC virityksistä? Olen noita jo pitkään ja hartaastit tutkinut. Ja lopputulos on se, että koko ratkaisu on totaalisen susi. Se jättää aivan liikaa avoimia tekijöitä. Eri versioita, eri toteutuksia jne. Lopputulos on se, ettei voi koskaan tietää toimiiko kaksi laitetta yhteen oikeasti ilman mittavaa testausta.  Edes se että yhteys näyttää toimivan ei takaa sitä että tunneli toipuu virhetilanteista.

Joskus jopa kahden samanlaisen laitteen välisen tunnelin toimimaan saaminen luotettavasit on hankalaa.

No onneksi tuo SSL VPN on tulossa hyvää vauhtia.

59
http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=207200145

We tested openSUSE, Ubuntu 8.04, PCLinuxOS, Mandriva Linux One, Fedora, SimplyMEPIS, and CentOS 5.1. All performed well, and each had at least one truly outstanding feature.

As predictable as this may sound, Ubuntu 8.04 remains one of the best desktop distributions for many good reasons: it works with almost any hardware you throw at it, and has tons of features for both existing Linux users and prospective converts from Windows

Sekä tietysti keskustelua Slashdotissa aiheesta:
http://tech.slashdot.org/article.pl?no_d2=1&sid=08/05/05/1440214

60
Koska tästä aiheesta riittää varmasti erilaisia näkemyksiä, ajattelin että on parempi pistää ihan oma ketjunsa.

Juttu lähti liikkeelle siitä että miksi Ubuntu ei tue NCQ:ta.

Oma näkemykseni asiaan:

Olen huomannut monessa yhteydessä että kun on selviä teknisiä parannuksia jotka pitäisi tehdä, niitä halutaan jostain syystä vastustaa viimeiseen asti. Tai niiden merkitystä vähätellään suuresti. - Tämä ei ole mitään uutta minulle, kun olen sovelluskehityksen parissa työskennellyt yli kymmenen vuotta. Omasta mielestäni erinäköiset optimoinnit pitäisi ottaa käyttöön kun se vain suinkin on mahdollista ja järkevää. Lisäksi jos joku asia on selvästi teorian tasolla osoitettu suorituskykyä parantavaksi, niin sen lyttääminen matonalle sillä perusteella että sitä ei tarvita on mielestäni väärin. Mutta ehkä tästä aiheesta voisi keskustella jossain ihan muussa ketjussa. Sanotaan vaan, että nyppii silloin kun asiasta on jäänyt jotain hampaankoloon. Olen kutenkin pohjimmiltani idealisti ja jos jotain voidaan parantaa, sitä pitäisi mielestäni parantaa. Eritoten kun kyseessä on käytettävyys tai optimointi. En kuitenkaan tue bloatwarea jossa varsinkin puutteellisisesti toimivia tai olennaisen kannalta tarpeettomia ominaisuuksia lisätään tolkuton määrä sovellukseen.

Yksi projekti jonka osalta olen monta kertaa sanonut tuhon olleen tulossa oli edonkey2000. eMuleen otettiin selvät loogiset parannukset käyttöön, mutta edonkey2000 ei niitä valitettavasti tukenut.

Tämä on varmasti koeteltu asia kyllä erilaisten distrojen tms asioiden puolesta ja yksi syy siihen miksi projekteja on niin monia. Demokratia kun ei välttämättä toimi aina yhtä tehokkaasti kuin diktatuuri.

Toinen referenssi on asiallisen ext3 defragin puute. Useimmat vastaajat eivät edes paneutuneet aiheeseen, vaan sanoivat että sitä ei tarvitse tehdä. Miksei? Missä selvät perustelut miksi ei? Niissäkin paikoissa joissa asiaa on perusteltu, sanotaan että fragmentoitumista imenee. Eikä sen jälkeen ole kerrottu mitään menetelmää joka eliminoisi sen. Näin ollen tilanne pahenee, vaikkakin hitaasti.

Tulen huomenna suorittamaan pari testiä NTFS:n pre-allokointiin liittyen, odotan innolla tuloksia. Tein sovelluksen joka allokoi levyltä 10% sen vapaasta tilasta. Toistan testit ennen ja jälkeen defragmentointia. Siten että toisella kerralla tila pre-allokoidaan ja toisella kerralla sitä ei varata. Otos on tietysti äärimmäisen pieni, mutta antaa edes jotain hajua asiaan josta on paljon spekulointia mutta ei mitään faktaa. Ainakin ideologisella tasolla pre-allokoinnin etu on selvä levyllä jossa on suhteellisen paljon tilaa.

Ihailen myös estotta projekteja joissa on oikeasti pyritty täydellisyyteen työmäärästä välittämättä. Töissä tulee jatkuvasti eteen resurssien riittämättömyys ja se, että joudutaan syöksymään pää kolmantena jalkana tuntemattomaan. Kun mielestäni erilaiset ratkaisut pitäisi arvioida jos on epäselvää, pitäisi simuloida ja testata tms. Voitaisiin siis tieteellisesti toistettavin tuloksin todeta, että tehdyt ratkaisut ovat oikeita.

Sivuja: 1 2 [3] 4