Fedora, a megmentő!

Az elmúlt napok sok-sok óráját fecséreltem arra, hogy találjak egy megfelelő (értsd: használható) rendszert, VMWare alá. Megpróbáltam Ubuntu 12.04 -től kezdve Debian Squeeze-ig mindent, ami csak eszembe jutott. (Na jó, Gentoo-val nem pöcsöltem, az azért kicsit túlzás lenne.)

Hiába próbálgattam a különféle distro-kat. Egyikben a kép szétesett (xorg regresszió), másikban nem ismerte fel a felbontást (szintúgy). Mígnem, egyik ismerősöm feldobta. Fedora. Verziók óta nem használtam. Na de, miért is ne?

Felpattintottam egy XFCE-s x64-es Fedora-t. Meglepődésemre a weblapok egyből normálisan néztek ki (ami egy pozitív pont, mert még Ubuntu alatt is, hiába rakom fel a restricted-extras-t, sok weblap nyomott marad.) Frissítés simán ment, semmi hiba. Reboot, vadonatúj kernel, vmware-tools telepít, felmegy.

Azóta is boldogan használom fejlesztői környezetként.

(ui.: Mikor a distro-kat pörgettem, már annyira elfogyott a türelmem, felraktam egy openSUSE-t fő distroként. A flash esett-kelt, ahogy azt illik. Persze, miért is nézzek flash-t, dolgozni kell. Ez igaz, de ha az ember találkozik egy videóval, vagy valami marhasággal, azt szeretné megnézni. 2012-t írunk elvégre is.)

( csuhi | 2012. 04. 27., p – 22:29 )

Fedorát használok, nálam is ez vált be legjobban, de a flash Fedora 16-ban is sz@r éppen. Viszont nem gondolnám hogy a disztró hibája, főleg mert a Fedora nem szállítja hanem az Adobe saját repójából telepítettem és frissítem.

--
http://csuhai.hu

Nálam 64 bites flash-plugin egész jól működik, nem szokott elesni. Fedora 17-ben is minden működik. Egészen apró bajaim vannak csak:

- Skype-on a context menü ikonjai eltűntek. Gondolom, valami Qt nyűg, elérési út, kompatibilitás, akármi

- a hangerőszabályozó tooltip-je eltűnik, ha egérgörgővel állítom a hangerőt. Kellemetlen, mert le kell húzni az egeret a hangszóró ikonról, aztán visszatolni fölé, hogy megint feljöjjön a tooltip, s lássam, mit állítottam be

- tiszta 32 bites Fedora 17-en nem sikerült életet lehelnem a flash-plugin-ba. A Firefox az about:plugins által látja, de nem működik. Fogalmam sincs, miért, majd megjavítom. Remélem...

- pulseaudio ugyan egész jó, de még az 1.1-esben sem javult ki az a hiba, hogy az elején furán szól a hang. Leginkább Skype-on jön elő. Olyan, mintha fésű szerűen a hangminták egy része a memóriában rossz címre másolódna, így szörnyen "szőrösen" szólal meg, aztán fáziskéséssel mintha a köztes hanganyag is megszólalna. Néhány másodperc után persze magához tér. Ez Fedora 16-on is így volt

- hibernáláskor kikapcsol a gépem, ahogy kell, de kb. 1 másodperc múlva újra elindul. Workaround: raktam a Grub menük közé egy Power Off! menüpontot. Ez is régi hiba, talán 2.6.33 után jelent meg

Minden más jól működik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( vargad | 2012. 04. 28., szo – 11:01 )

Nem tudom mit csinálnak a VMWare-nél, de Virtualboxon nekem még egyik linuxal sem volt problémám.

( Vladi | 2012. 04. 28., szo – 13:23 )

Örülök, hogy bevált.

xfce engem is egyre jobban érdekel. lxde-t használok, de néha a fapadossága már nyomja a seggemet, úgy látszik öregszem. :))

gnome 3-hoz is már öreg vagyok. :DD

>>: sys-admin.hu :<<

Vagy te a Wi-Fi-t is 802.11-nek hívod?

Nem. De (1) a "Wi-Fi" kifejezést a Wi-Fi Alliance definiálja, így szállítófüggetlen (vagy legalábbis rengeteg szállítót ölel fel), (2) a "Wireless Fidelity" egy (úgy-ahogy) eredeti fantázianév, nem egy másik név/rövidítés ízléstelen eltorzítása.

És nem, én addig nem tudtam, mi az az x64, amíg valahogy évekkel ezelőtt el nem vetődtem egy 64-bites windows-programozást oktató oldalra (ahol is az LLP64 modellen harsány kacajra fakadtam).

http://en.wikipedia.org/wiki/LLP64#64-bit_data_models

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's Visual C++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code, but code is often written with implicit assumptions about the widths of integer types.

(i) A "long szélesebb az int-nél" egy 100%-ban természetes és magától adódó ötlet. (ii) A C89 (SUSv1 / UNIX 95, SUSv2 / UNIX 98) alapú platformokon a legszélesebb hordozható egész típus a long, így egyáltalán nem elrugaszkodott ötlet arra számítani, hogy beleférjen a pointer. A SUS szabvány(ok) által leírt négy modellból (amelyből a platformnak legalább egyet kell támogatnia) három garantálja, hogy a long-ba belefér a pointer.

Egyszóval az LP64 egy természetes továbbgondolása a típusoknak.

Az LLP64 a Windows-ra írt források minőségéről tanúskodik. A Microsoft kompatibilitási okokból (*) arra figyelt, hogy a long beleférjen az int-be. Ki a retek kódol ilyet? Ráadásul C89-alapokon megírt program Windows-on fordítva nem fog hozzáférni 64 bites egész típushoz, hiába tudja a platform / compiler (az off_t ebben a megközelítésben lényegtelen); valamint a pointer-to-long konverzió (ami nem garantált ugyan, de azért értelmes elvárás) pofára fog esni.

(*) Itt forráskód-szintű kompatibilitásról van szó:

Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit.

Nem azon aggódtak, hogy a létező ILP32 binárisok ne futottak volna el, hanem hogy AMD64-es windows-on (LP64-en) újrafordítva fejreálltak volna.

Szerk: azt természetesen nem vitatom, hogy a Microsoft részéről talán ez volt az egyetlen kereskedelmileg járható út.

Jogos, azonban ennek van egy másik oldala is. 64 bites platformon elvárod, hogy lehessen 4G-nél nagyobb tömböd. Ez magával vonja, hogy a size_t (és majdnem biztosan a ptrdiff_t is) 64 bitesek lesznek.

Nem magát a pointer-t akarod long-ba rakni, hanem pointerek különbségét. Pointerek különbsége ptrdiff_t típusú, ami ugyan nem garantálja egyazon tömb két tetszőleges eleme közötti indextávolság ábrázolhatóságát sem, a gyakorlatban azonban számítasz erre, ahogy arra is, hogy a ptrdiff_t-t bele tudod rakni long-ba. Például bináris kereséssel megkeresel két elemet (külön-külön), és a távolságukat ki akarod íratni fprintf()-fel. C89-ben / SUSv2-ben ehhez long-ra fogsz cast-olni.

Ha a long 32 bites, akkor az a faramuci helyzet áll elő, hogy a hordozható C89 / SUSv2 programod pl. nem tud fprintf()-fel garantálható módon kiírni tetszőleges size_t-t (mert normálisan long unsigned-re cast-olnád), valamint az strtol() által felnyalható értékkészlet (pl. parancssori opció valamilyen buffer méretére) csak töredéke annak, amit a size_t ábrázolni tudna.

C89-ben / SUSv2-ben egyszerűen a long a legszélesebb egész típus, amit a szabvány teljes körűen támogat / leír. A hordozható program a platform képességeiből elég sokat elveszít, ha a platform a long-ot szűkebbre veszi, mint a size_t vagy a ptrdiff_t.

Ellenben ma már te, és bárki más is megérti, hogy mire utal az x64 elnevezés, arról nem is beszélve, hogy ez nem egy hivatalos leírás, csak egy naplóbejegyzés.
Nekem speciel elég undorító látvány az x86_64, körülbelül olyan mint egy belső változó neve, amit egy szép getter úgyis elfed.
Ha már mindenképp "hivatalos" nevén akarja valaki szólítani, hívja inkább AMD64-nek.
------------------
My Open-Source Android "Projects"