A tesztgép (kép) egy Clevo barebone-ból felépített notebook (inkább desknote) volt. A gép lelke egy 1800MHz-en futó, AMD64 3000+ jelölésű processzor (kép). Akit bővebb részletek érdekelnek a gépről, az látogasson el a blog-omba ide.
Az tesztben szereplő operációs rendszerek a következők voltak: OpenBSD 3.6 (amd64), FreeBSD 5.2 (amd64), FreeBSD 5.2.1 (amd64), FreeBSD 5.3-RC* (amd64), FreeBSD 5.3-RELEASE (amd64), NetBSD 2.0 BETA (amd64), Ubuntu Linux Warty release (amd64), DragonFly BSD legújabb stabil ISO-i. Hogy miért volt ennyi verzió, az a későbbiekben kiderült.
A tesztelések során soros terminálon keresztül telepítettem és debug-oltam az operációs rendszereket. Az egyes rendszereknél megadom majd, hogy milyen paraméterrel indítottam a telepítést, hogy a soros terminál használható legyen. Nézzük:
Ubuntu Linux Warty release (amd64)
------------------------------------------
Az operációs rendszer simán települ, probléma nélkül beállítható.
--------------------------------------------------- I data) BIOS-e820: 000000000fefa000 - 000000000ff00000 (ACPI NVS) BIOS-e820: 000000000ff00000 - 0000000010000000 (reserved) BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved) No mptable found. On node 0 totalpages: 65264 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61168 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f68e0 ACPI: RSDT (v001 PTLTD RSDT 0x06040000 LTP 0x00000000) @ 0x000000000fef607e ACPI: FADT (v001 AMDK8 PTLTW 0x06040000 PTL_ 0x000f4240) @ 0x000000000fef9e66 ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000000fef9eda ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x000000000fef9fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) IOAPIC[0]: Assigned apic_id 1 IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ10 used by override. Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ e0000000 size 256 MB Built 1 zonelists Kernel command line: root=/dev/hda1 ro console=tty0 single Initializing CPU#0 PID hash table entries: 16 (order 4: 256 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1804.122 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 249704k/261056k available (1463k kernel code, 10632k reserved, 963k data, 112k init) Calibrating delay loop... 3547.13 BogoMIPS Security Scaffold v1.0.0 initialized Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: Mobile AMD Athlon(tm) 64 Processor 3000+ stepping 0a Using local APIC NMI watchdog using perfctr0 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-16, 1-17, 1-18, 1-19, 1-20, 1-21, 1-22, 1-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. Detected 12.528 MHz APIC timer. checking if image is initramfs...it isn't (ungzip failed); looks like an initrd NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *9, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *11, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *10, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *5, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs *9) ACPI: PCI Interrupt Link [LNKB] (IRQs *11) ACPI: PCI Interrupt Link [LNKC] (IRQs *10) ACPI: PCI Interrupt Link [LNKD] (IRQs *5) ACPI: Embedded Controller [EC] (gpe 11) usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing IOAPIC[0]: Set PCI routing entry (1-17 -> 0xa9 -> IRQ 17 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 17 IOAPIC[0]: Set PCI routing entry (1-19 -> 0xb1 -> IRQ 19 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 19 (level, low) -> IRQ 19 IOAPIC[0]: Set PCI routing entry (1-16 -> 0xb9 -> IRQ 16 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 16 (level, low) -> IRQ 16 ACPI: PCI interrupt 0000:00:0e.0[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: PCI interrupt 0000:00:0e.1[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: PCI Interrupt Link [ALKD] disabled and referenced, BIOS bug. ACPI: PCI Interrupt Link [ALKD] BIOS reported IRQ 0, using IRQ 21 ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 21 IOAPIC[0]: Set PCI routing entry (1-21 -> 0xc1 -> IRQ 21 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.1[B] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.2[C] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.3[D] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug. ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 23 ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 23 IOAPIC[0]: Set PCI routing entry (1-23 -> 0xc9 -> IRQ 23 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 23 (level, low) -> IRQ 23 ACPI: PCI Interrupt Link [ALKC] disabled and referenced, BIOS bug. ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 IOAPIC[0]: Set PCI routing entry (1-22 -> 0xd1 -> IRQ 22 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 22 ACPI: PCI interrupt 0000:00:11.6[C] -> GSI 22 (level, low) -> IRQ 22 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16 number of MP IRQ sources: 15. number of IO-APIC #1 registers: 24. testing the IO APIC....................... IO APIC #1...... 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) Linux amd64mobile 2.6.8.1-3-amd64-generic #1 Tue Oct 12 11:40:38 UTC 2004 x86_64 GNU/Linux |
OpenBSD 3.6 (amd64)
--------------------------
Az operációs rendszer simán települ, probléma nélkül beállítható.
--------------------------------------------------- OpenBSD 3.6 --------------------------------------------------- set tty com0 --------------------------------------------------- (1200MHz 54C) root@alderaan:/home/trey/!download/ISOs $ kermit booting cd0a:/3.6/amd64/bsd.rd: 1179600+218118+2169464+0+320808 [80+140640+80475]=0x7eb834 OpenBSD 3.6 (RAMDISK_CD) #119: Fri Sep 17 12:48:12 MDT 2004 amd64mobile# uname -a |
NetBSD 2.0 BETA(amd64)
-------------------------------
Az NetBSD 2.0 BETA szintén simán települ, egyetlen probléma az volt, hogy nem ismeri fel az alaplapi GE Ethernet vezérlőt, és még néhány eszközt (lásd: dmesg). Valószínű, hogy a legújabb snapshotokkal ezek a problémák a múlté lesznek...
--------------------------------------------------- NetBSD 2.0 --------------------------------------------------- consdev com0 --------------------------------------------------- (750MHz 50C) root@alderaan:/home/trey $ kermit >> NetBSD/amd64 BIOS Boot, Revision 3.1 NetBSD 2.0_BETA (INSTALL) #0: Thu Apr 22 17:00:22 PDT 2004 >> NetBSD/amd64 BIOS Boot, Revision 3.1 NetBSD 2.0_BETA (GENERIC) #0: Thu Apr 22 16:47:08 PDT 2004 NetBSD/amd64 (Amnesiac) (console) login:root NetBSD 2.0_BETA (GENERIC) #0: Thu Apr 22 16:47:08 PDT 2004 Welcome to NetBSD! Nov 5 17:54:33 login: ROOT LOGIN (root) ON console |
FreeBSD 5.3-RC*, FreeBSD 5.3-RELEASE (amd64)
----------------------------------------------------------
Sajnos az operációs rendszer nem települt. A bootolás során ``Fatal trap 19: non-maskable interrupt trap while in kernel mode'' üzenettel elpánikolt a kernel. A hibát jelentettem a -current listán. Reakció egy esetet kivéve (ami használhatatlan volt) nem volt. A soros konzol kód szemlátomást broken, ez sem érdekelt senkit.
DragonFly BSD 1.0-A, legújabb stabil kiadások (i386)
------------------------------------------------------
A DragonFly BSD jelenleg nem érhető el AMD64-re. Csak ellenpróbaként került telepítésre, de az tisztán látszik, hogy ha egy probléma AMD64 port alatt jelentkezik, akkor az nagy valószínűséggel előjön i386 alatt is. A rendszer szintén nem települt. A hiba ugyanaz volt, mint a FreeBSD-ben. Nem csoda, hiszen egy a gyökerük. A kernel pánikot jelentettem a dragonfly-kernel listára, ahol Matthew Dillon azonnal válaszolt. Ő RAM hibára, melegedésre, felhúzott CPU-ra gyanakodott. Mikor írtam neki, hogy ez egy vadonat új gép, 6 különböző memória modullal próbáltam, a hiba reprodukálható és mindig ugyanott jelentkezik, akkor egy másik fejlesztő egyetértett abban, hogy ez nem RAM hiba, hanem sokkal inkább firewire inicializációs bug. Később írtam, hogy valószínűleg FreeBSD/DragonFly BSD specifikus bug, mert sem az OpenBSD, sem a NetBSD nem pánikol el a telepítéskor. Persze, hogy nem, mert egyik sem inicializálja telepítéskor a firewire-t. Kicsit eljátszottam az OpenBSD-vel, és kiderült, hogy nem GENERIC, hanem firewire támogatással rendelkező kernellel sem pánikol az OpenBSD, hanem szépen inicializálja az eszközt. Majd ezután készítettem egy saját FreeBSD 5.3-RELEASE kernelt firewire támogatás nélkül, egy saját telepítő CD-t, és sikeresen feltelepítettem a FreeBSD 5.3-RELEASE-t. Ezután Matt is egyetértett, hogy firewire bug lehet, és felajánlotta, hogy készít patchet, ISO image-et és teszteljünk. Ezután 3 napos patchelés, tesztelés vette kezdetét. Közben felbukkant Hidetoshi Shimokawa, a FreeBSD firewire kódjáért felelős fejlesztő, aki egy patchet javasolt. A patch alapján Matthew elkészítette a legfrissebb stabil DragonFly BSD ISO-t. A patch meghozta az eredményt. A DragonFly BSD telepítő végre bebootolt és inicializálta a firewire eszközt. Ezután Matt commit-olta a DragonFly BSD-be a változásokat. A teljes thread itt.
Jelen állapot:
---------------
A FreeBSD 5.x (beleértve a FreeBSD 5.3-RELEASE-t is) sorozatának kivételével mindegyik felsorolt operációs rendszer telepíthető. A DragonFly BSD Matthew Dillon gyors reagálásának köszönhetően szintén telepíthető a gépre. A fix valószínűleg hamarosan meg fog jelenni a FreeBSD-ben is, így azzal sem lesz probléma. Az AMD64 alapú gépek támogatottsága mind Linux, mind *BSD oldalról jónak mondható. Ilyen gépet használva valószínűleg könnyebben bele lehet futni hasonló hibába, mint amilyenbe én is belefutottam. Ez betudható annak, hogy lényegesen kevesebb ilyen hardver van közkézen, mint mondjuk i386 gép, és lényegesen kevesebben bugreportolnak... Talán közrejátszik az is, hogy ezek a hardverek talán kevésbé teszteltek még jelenleg, kevésbé kiforrottak. Azoknak érdemes ilyen gépet venni, akik nem riadnak vissza egy kis debugolástól, Google használattól (bár ez sok esetben nem segít), bugreportolástól... Persze a gép használható i386 módban is... Mindenesetre az látszik, hogy nem kell azonak félni, akik AMD64-es gép vásárlására adják fejüket, mert támogatás lesz hozzá...
Néhány tesztelés közben készített kép itt.
- A hozzászóláshoz be kell jelentkezni
- 8924 megtekintés
Hozzászólások
Termeszetesen nem Opteron, hanem Athlon.
- A hozzászóláshoz be kell jelentkezni
Nem unod meg, hogy fogsz egy szamitogepet, amiben lehetoleg van egy olyan alkatresz amit nem tamogat a FreeBSD, es a vegeredmeny mindig az, hogy a FreeBSD *****, mert nem telepul fel.
Lattal mar egyaltalan FreeBSD-t mukodes kozben, vagy valami aura van korulotted ami megakadolyozza hogy meghittebb kapcsolat alakuljon ki koztetek?
A FreeBSD levlistan pedig mar tuti ismernek, es azert nem valaszolnak.
- A hozzászóláshoz be kell jelentkezni
Picinykét furcsa is volt, de nem mertem szólni, mondván Te tudod jobban... és tényleg... :)
Ügyes vagy, gratulálok a teszthez... :)
- A hozzászóláshoz be kell jelentkezni
"Lattal mar egyaltalan FreeBSD-t mukodes kozben, vagy valami aura van korulotted ami megakadolyozza hogy meghittebb kapcsolat alakuljon ki koztetek?"
hmm..
/me ránéz a hatalmas "Powered by FreeBSD" logóra az oldal alján
- A hozzászóláshoz be kell jelentkezni
Nem tudom, hogy vegigolvastad-e a thread-et. Javaslom tedd meg. A hozzaszolasod eros hozza-nem-ertesrol es arroganciarol tanuskodik.
- A hozzászóláshoz be kell jelentkezni
Többek között azt sem tudja, hogy a HUP elég régóta FreeBSD -n fut... na meg asszem nem tudja jópár dologról a véleményedet... :)
- A hozzászóláshoz be kell jelentkezni
A freeBSD 5.3 nekem szintén nem települt fel, sem AMD64 sem i386 módman. A vas: Athlon64 3200+, VIA K8T800Pro, GF5700Ultra, 2x256M Samsung, 120G Maxtor (nem SATA). Már CD bootolás alatt elszált mindkettő üzemmódban ugyanott. Szóval van még mit fejlődni...
Jelenleg egyébként kb 2 hónapja a Debian SID erősen béta AMD64-es portját használom teljas megelégedettséggel, eddig egy hibát találtam (vtun segfaultol), egyébként megy mint a golyó.
- A hozzászóláshoz be kell jelentkezni
Erdekelne mi a hibauzenet, es hogy hol szall el. Meg tudnad nezni?
- A hozzászóláshoz be kell jelentkezni
Le a kalappal trey!
Ha élhetek egy hasonlattal, akkor azt mondanám, hogy ezzel a cikkel képzeletben mégegy képzeletbeli téglát tettél bele az OpenSource rendszerek, és munkásság képzeletbeli házába.
- A hozzászóláshoz be kell jelentkezni
Nu, akkor egy további, amit nem tudom javítottak-e:
iperf 64 bites client behal...
pontosabban melóba se kezd :-)
- A hozzászóláshoz be kell jelentkezni
A netistall CD-vel bootoltam i386 és AMD64 módban is.
Bármelyik menüpontot kiválaszva ezt produkálja:
vge0: MII read timed out
vge0: failed to start autopoll
vge0: MII without any phy!
Kernel trap 12 with interrupt disabled
Total trap 12: page fault while in kernel mode
utána regiszterértékek címek stb
- A hozzászóláshoz be kell jelentkezni
Ugyanolyan gagyi cikk, mint a nagyvallalatis. Van, aki telepitse helyette a freebsd-t. Betat :-) Nahagyjuk.
- A hozzászóláshoz be kell jelentkezni
Nekem az teccett az egeszben hogy a kepek szerint a laptoprol nincs eltavolitva a vedo muanyag folia....
Ha jol sejtem jo videki szokas szerint ez is el lesz "ujkent" adva.... na ezert nem vasarolok videken... Haverok letett vackat sosem szerettem megvenni...
- A hozzászóláshoz be kell jelentkezni
A gep nem lesz eladva. Egyebkent nemtom lattal-e mar barebone-t. A barebone-t ugy szerelik ossze, kesobb kerul ra operacios rendszer, es legalabb 8-10 munkafolyamaton megy keresztul. Kozben megfogja kb. 6 ember, es folyamatosan dolgozik vele. a gepek legalabb 48 oras teszten esnek keresztul, es kozben rajta van a folia, hogy ne legyen a gep, TFT maszatos, stb.. Ez az osszes gepnel igy van. Mi ebben a csoda? De ez igy van a cegek altal gyartott nem brand gepeknel is.
>Ha jol sejtem jo videki szokas szerint ez is el lesz "ujkent" adva.... na ezert nem vasarolok videken... Haverok letett vackat sosem szerettem megvenni...
Ezt a reszet nem ertem. A videki jelzo nevetseges, ugyanis szamos cegnek videken van osszeszerelo uzeme, amit utana te FOVAROSI elit megvasarolsz orommel, mert hiszed, hogy az Oktogonnal szerelik ossze. Felvilagositalak. Majdnem az osszeset videken szerelik ossze.
- A hozzászóláshoz be kell jelentkezni
Uhh, ez a "videki" szoveg nagyon gaz...
Tegnap en is megkaptam:
{tonyo} ne magadbol indulj ki videki suttyo
...mondja a nagyvarosi paraszt... ;)
- A hozzászóláshoz be kell jelentkezni
trey, koszi a tesztet, igy batrabban merem javasolni az amd64es gepeket.
- A hozzászóláshoz be kell jelentkezni
Szerintem eszre sem venned hogy melyik a "haverok letett vacka" ha meg eszre veszed akkor viszakell vinni, vagy a vasarlas elott megnezni. Egyebkent meg ott vasarolsz ahol akarsz, hozzateszem ott b@sszak at az agyad ahol akarjak _ha akarjak_ fuggetlenul videk vagy bp, de bp-n szerintem sokkal surubben.
- A hozzászóláshoz be kell jelentkezni
En kerek elnezest
- A hozzászóláshoz be kell jelentkezni
Szerintem nem az a gaz, hogy valami nem megy. Az a gaz, hogy a www.freebsd.org oldalon ugy hirdetik, hogy tier1 platform.
Jobb lenne tenyleg csak azokat a platformokat bevallalni, amiken viszonylag jol mukodik a cucc (fel tud bootolni, alapszoftverek rendesen, normalis sebesseggel mukodnek). Ehhez persze kell userbase, tesztkornyezet stb stb.....
Azert meg kar leugatni trey-t, hogy leirta, amit tapasztalt. Egy kezdo user igy legalabb nem fog palira menni, ha FreeBSD-t probal felinstallni. All right, ha nem szereti a Linuxot, mehet az OpenBSD. Maris egy kellemetlen szopassal kevesebb. Mert ha lecincalja az image-t es mar bootolaskor kiderul, hogy az egesz tok felesleges volt az nem egy jo pont.
Nekem mar csak az a kerdesem maradt, hogy Debian v. Gentoo probalkozas miert nem volt?
Andrei
Andrei
- A hozzászóláshoz be kell jelentkezni
> Az a gaz, hogy a www.freebsd.org oldalon ugy hirdetik, hogy tier1 platform.
Igy van, es emellett a FreeBSD 5.x sorozat nagyon-nagyon messze van a production-tol. Az 5.3-RELEASE meg talan a legrosszabb FreeBSD kiadas, amit eddig lattam. Eleg csak megnezni az utobbi napok levlista termeset.
>Egy kezdo user igy legalabb nem fog palira menni, ha FreeBSD-t probal felinstallni.
Arrol nem beszelve, hogy ennek a tesztnek koszonhetoen fixalasra kerult egy reprodukalhato kernel panik, ami szerintem mindenkinek jo. Kivancsi leszek, hogy Dillon utan a FreeBSD-sek is commitoljak-e a patchet...
>Nekem mar csak az a kerdesem maradt, hogy Debian v. Gentoo probalkozas miert nem volt?
Mert ezek egyertelmuen mennek. Ha egy Linux disztro megy, akkor mennie kell a tobbinek is. A kernel a lenyeg. Egyebkent probaltam Debian-nal is. Nem volt vele gond.
- A hozzászóláshoz be kell jelentkezni
Ugy latszik, tonyo meggyogyult :-)
- A hozzászóláshoz be kell jelentkezni
Igen, dolgozzanak a videkiek a FOVAROSI elitnek :-) Jo ez igy. Minek jonnek akkor a fovarosba a videkiek... Ha a fovarosiak csutkak, ne jojjenek ide, kergessek a tikokat es mossanak fogat rendszeresen.
Kar elterelni a szot, felbontottad es hasznaltad. Ha nincs eltavolitva a folia, az azt jelenti, ujkent kerul majd forgalomba, ami nem is baj. Neked. De ez nem csak videken szokas, fovarosban is. Csakhogy nem mindenhol.
- A hozzászóláshoz be kell jelentkezni
Ezen a 'paraszt' dolgon asszony mindig felhorkan, teljesen jogosan. :) A paraszt ember tisztességes kétkezi munkával eteti az esetleges nagyvárosi bunkót, szóval maradjunk meg max. ebben. :)
Amúgy ezen a 'vidéki' dolgon nekem is feláll a szőr a hátamon, mert mégiscsak a vidék miatt élhet Budapest, de Budapest nélkül az ország még működne, fordítva viszont már nem.
- A hozzászóláshoz be kell jelentkezni
>Kar elterelni a szot, felbontottad es hasznaltad.
LOL. Persze hogy felbontottam. Hiszen en raktam ossze. A barebone notebook (gyengebbek kedveert: barebone = haz + alaplap) mar csak ilyen. Ossze kell szerelni... tudod bele kell tenni a processzort, akkut, memoriat, DVD-t, HDD-t... persze ehhez kell legalabb 2 agysejt, hogy ezt az infot valaki feldolgozhassa, igy veled nem is probalkozom... :-)
- A hozzászóláshoz be kell jelentkezni
kohinoor wrote:
> Ugyanolyan gagyi cikk, mint a nagyvallalatis. Van, aki telepitse helyette a
> freebsd-t. Betat :-) Nahagyjuk.
>
Nemtudom feltunt-e az a karaktersorozat, hogy: "5.3-RELEASE" ?
Nekem nem betanak tunik...
IroNiQ
--
Web: http://ironiq.hu
Email: iron@ironiq.hu
LinuxCounter: #331532
- A hozzászóláshoz be kell jelentkezni
trey,
mennyire érezhető a különbség pl. egy 2800 Mhz celeron és AMD64 sebessége között standard X alkalmazások (mozilla, evolution, konqueror, OOO, etc..) esetén?
- A hozzászóláshoz be kell jelentkezni
Hat ha nativ 64 bit akkor azt mondom h jol erezheto, bar ez lehet, hogy csak a ``bebeszelesi'' effektus. Konkret mereseket meg nem vegeztem.
- A hozzászóláshoz be kell jelentkezni
Gratula Trey, ez nagyon tetszett!
Egyébként egy ilyen gép mennyivel jobb ár/érték arányban, mint egy x86-os ?
- A hozzászóláshoz be kell jelentkezni
Hat nezd. Arban ugyanott van, ahol egy hasonlo kategoriaju P4. Viszont ha fejleszteni vagy tesztelni akarsz es fontos neked a 64 bit, akkor erdemes ilyen gepet venni. Lassan jonnek szerintem az Intel 64 bites mobil CPU-i is, ugyhogy lehet majd valogatni.
- A hozzászóláshoz be kell jelentkezni
Hmm... Én mindig nagyokat lepődök, mikor pestiek vidékiznek...
Pl. első nagyobb FSN kuratóriumi ülésnél bra úgy talált fogalmazni, hogy majd ők (bpestiek) igazodnak a hozzánk (trey, al3x, /me), mert mégiscsak nekünk kell oda vidékre (gyek.: Budapest) leutaznunk... :-P
Azóta ha pesten járok mindíg így fogalmazok, hogy leutaztam vidékre...
- A hozzászóláshoz be kell jelentkezni