10 dolog, amit utálok a (U)NIX-szal kapcsolatban

UNIX, UNIX-szerű

``10 Things I Hate About (U)NIX'' címmel jelent meg egy kritikus hangvételű cikk a UNIX rendszerek jellegzetes tulajdonságairól az Informit.com-on. A cikk szerzője szemügyre veszi a ``minden file'', ``minden text'' dolgot, szóba kerül az X11, a standard I/O, stb.Természetesen az ilyen cikkeket nem szokták kommentek nélkül hagyni. Érdemes elolvasni a hozzászólásokban született megjegyzéseket is.

A cikk itt. Érdekes hozzászólások itt és itt.

( Emulgeator | 2005. 11. 07., h – 13:27 )

Hmm a 10 pont nagy resze imho a Unix/Linux erossege:)

( Andrei | 2005. 11. 07., h – 13:37 )

A Unix Hater's Handbook az egyik kedvencem... Hasonlo kerdeseket boncolgat, csak sokkal humorosabban.

( anr | 2005. 11. 07., h – 13:37 )

balf@sz egy srac. vannak problemai, nem tudja megoldani oket, es ezert a UNIX filozofiat okolja.

pedig csak 2 problemaja van: nem tudja hasznalni a man-t, es a a google sem a baratja.

Plusz mint nem angol elfelejtetted hogy a legtobb angol program angol nyelvueknek olyan mint neked olvasni. Pl egy angolnak az ls utan a h kapcsolo eccerubben megjegyezheto mivel human readable mint neked... es akkor meg finom voltam... egy kis nyelvi logikaval egy csomo dolog megfejtheto nekik....

Nagyon-nagyon egyetertek veled snq. A Google es man nem segit azon, hogy a Unix-like rendszerekben a 70-es evek koszonnek vissza, es sokszor a falat kaparja az ember amikor szembesulnie kell azzal, hogy a sendmail a levelkezelo programok non-plus ultraja es a vi-ert erdemes rajongani. Biztos lehetne jobban csinalni.

Arrol meg, hogy az X11 egy balfek design gondolom senkit nem kell meggyozni. Sokkal jobb megvalositast lathatunk Windows-on es Mac-en. Illetve lehet, hogy a megvalositas *****, de legalabb nem gurulok a rohogestol, amikor ranezek az egeszre. A multkor elinditottam a xine-t es majdnem lehanytam a monitort.

( siposa v | 2005. 11. 07., h – 17:14 )

Az ilyen cikkek utan mindig elkap a depresszio.

Az egyik nagy baj, hogy ha jotet lelkek ebben a pillanatban nekiallnanak orvosolni a problemakat, ugy 5-10 ev mulva lenne belole valami komolyan hasznalhato, ami a distro-kban is megtalalhat a felhasznalo.

Pont ugyanazt csinálod, mint amit az egyik kedves hozzászóló az eredeti cikkhez: a formát bírálod, a szerzőt támadod, nem pedig a lényeget próbálod megérteni (lásd ls-paraméterek elmagyarázása -- a lényeg nem az hogy az ls magától is tud sortolni, mert ez csak egy triviális PÉLDA -- más feladatnál, más programokkal ugyanez a probléma (minden kimeneti karakter csak karakter, nem definiált karaktersor, pl. mérőszám és mértékegység) előfordulhat, és ott nem feltétlenül megoldható!!)

Tehát a cikkíró feltárja a VALÓS problémákat, de csak üres támadással tudtok visszavágni -- mi ez a hozzáállás?? Nem vagyok coder, de asszem erre mondták azt hogy inkább "shut up and hack" ...

Az ilyenek miatt tudja a Microsoft dinoszauruszként ábrázolni a UNIX rendszergazdákat a reklámjaiban. És igaza van? Tegyetek már valamit azért hogy NE legyen! Nem csak BSD-ből és sh-ból áll a világ... Az, hogy ezt valaki megszokta, és használja, egy másoktól független dolog.

Szerintem a UNIX ereje a választás szabadságában rejlik. Hogy ki tudod választani az utat, amit bejársz, amilyen módszerrel majd nap mint nap dolgozol. És az új igényekhez szükség van új szemléletmódra is. Például egy szerényebb képességű, de könnyen beállítható grafikus serveralkalmazás. (már hallom is a fújolókat - "Kattingatós, menj a má$ik rendszerbe!!") Vagy egy kézreálló, egységes grafikus környezet (ez már kezd kikristályosodni - KDE, Gnome). Az alacsony szintű funkciók közt is ésszerű lenne rendet tenni, például egy tv-tuner vagy videokártya miért szövegfájl? Lemezmeghajtóknál van értelme, ilyen eszközöknél viszont NINCS.

Ezzel persze nem feltétlenül kell megszűntetni a régit. De a forradalom áldozatokkal is jár. A 35 éves örökség felesleges, elfeledett, régóta nem használt részeit kíméletlenül ki kell dobni, a megmaradtakon pedig lehet, hogy változtatni kell. De amíg ilyen emberek is használják a UNIXokat, addig erre nincs sok esély.

És most lehet engem is elküldeni a bús ***-ba, kikiáltani árulónak, lamernek, mittoménminek, de ettől még semmi nem változik; akik nem értették a cikk lényegét, csak mocskolódni tudnak, sajnálom...

>a formát bírálod, a szerzőt támadod, nem pedig a lényeget próbálod megérteni

ugy tunhetett, pedig nem, csak rovid voltam. a lenyeg az az, hogy semmi gond a UNIX filozofiaval: miden _valos_ problema megoldhato vele. donto reszuk egyszeruen. az hogy miert minden file, az nem _valos_ problema. az a valos problema, hogy sorban akarod latni a filejaidat, le akarsz jatszani egy videot, vagy webet akarsz bongeszni.

A minden file filozofia nagyon egyszeruve teszi a programozast. ugyanazokat a fv-ket kell hasznalni egy soket, vagy egy szovegfile irasara. es ha belegondolsz ugyanaz is tortenik. az hogy a cucc bitjei a halokartyan, vagy az SCSI kartyan tavoznak nem mind1? dehogynem.

>Tehát a cikkíró feltárja a VALÓS problémákat

NEM. a cikkiro egyetlen valos problemat sem irt. olyan dolgokat irt le, amik szerinte akadalyozzak a valos problemainak megoldasat.

pl: valos problema, hogy X11 felett nem gyorsak az FPS-sek. hogy az X11 nem hasznalja ki a direktX-et tamogato kartyak featureit, es hasonlok. ezekkel kell foglalkozni, es ezek megoldasa erdekeben lehet felvetni, hogy akadalyoz az X11 halozat transzparenciaja. de szerintem nem kidobni kell, hanem local gepen megkerulni. akkor lokal gepen gyors, de meg mindig konnyu diskless remote terminalt csinalni.

>Szerintem a UNIX ereje a választás szabadságában rejlik.

nem.

a UNIX ereje abban rejlik, hogy nyilt rendszer (pl: a VMS zart), es most nem a kod nyitottsagarol beszeltem.

>És az új igényekhez szükség van új szemléletmódra is. Például egy szerényebb képességű, de könnyen beállítható grafikus serveralkalmazás

ez egyaltalan nem jelent teljes szemleletvaltast. ha van valodi igeny X programra, akkor lesz ceg/projekt aki csinal egyet. pl: suse-nek van egesz teljes kattingatos szerveralkalmazasa.

nem kell emiat egy uj szerferprogramot irni, eleg hozza egy konfiguracios frontend, ugyanis minden file, a konfigfilek is. nyugodtan lehet fole irni egy csili-vili feluletet _HA VAN RA IGENY_

nem veletlen, hogy aki egy kicsit melyebbre merul a Unix/Linux/BSD vilagaban tobbe kevesbe elfelejti a kattingatos konfiguralast. ugyanis _isszonyatosan lassu_ ahhoz a sebesseghez kepest, amit szovegfajlok modositgatasaval el lehet erni. nem is beszelve a szriptelgetesrol, a tuti kis bash for ciklusokrol, amivel tomegesen lehet elintezni dolgokat. meg akkor is, ha olyan problema, amire a kattingatos csili-vili konfiguracio felulet keszitok soha nem is gondoltak. amikor ilyen problemaba utkozik egy win rendszergazda, akkor ott hajtepes lesz, es rengeteg munka amig elkeszul.

>például egy tv-tuner vagy videokártya miért szövegfájl

mi a turoert problema ez? kuloben nem szovegfile, hanem device:)

tudod egy eszkozzel 1 csatornan keresztul lehet kommunikalni. lehet neki kuldeni adatokat, es kapni tole. _pont mint egy file_

ezen csatorna folott van definialva egy protokoll.

a win-ek is filekent kezelik az eszkozoket, csak a protokoll specifikus API elfedi ezt. _megtiltja_, hogy te alacsony szinten beszelgess az eszkozoddel. korlatozza a szabadsagodat.

a unix-okban megadjak neked mindket lehetoseget.

>A 35 éves örökség felesleges, elfeledett, régóta nem használt részeit kíméletlenül ki kell dobni

mire gondolsz? mi az ami meg mindig benne van es "régóta nem használt"?

>megmaradtakon pedig lehet, hogy változtatni kell

folyamatosan valtozik a Linux/BSD nezd meg a changelogokat. csak az a kulonbseg, hogy valodi igenyek mozgatjak a valtozast, es nem lózungok. tudod a normalis dolgok ugy mukodnek, hogy akkor lesz kidobva valami, ha a nala _jobb_ mar mukodik, es bizonyitotta, hogy jobb. mutasd mire gondolsz a minden file filozofia helyett?

namegegy: nemreg volt egy valos problemam, at akartam nevezni 3764 filemat, amik 222 egymasbaagyazott konyvtarban voltak. nem akartam, hogy mindenfele csunya jel legyen a filenevekben.

Ez a problema konnyen megoldhato volt:

prename 's/[s][()!]+//g' $(find ~/konyvtar -type f)

hogy is lehetne ezt megcsinalni win-en? egyesevel kattintgatva?

( khiraly | 2005. 11. 07., h – 21:54 )

Csak eszembe jutott az 1-es pont alapjan:

Regi nagy almom, hogy igy tudjak DVD-t irni:

cat vickyVette.xxx.dvd.collection.iso > /dev/dvd

Most valtottam 2.6-os kernelre 2.4-rol (ideje volt;), es beteljesult az almom!;)

Probaltatok mar?

Nincs szukseg semmifele dvd iro programra, egyszeru cat-tal fel lehet irni a fajlt. Vegre valahara, ezt is megertuk.

2.6.14-gyel probaltam.

Megy a direkt iras is:

cat skeletonKey.avi > /dev/dvd

Ezek utan:

dd if=/dev/dvd of=/mnt/big/lolza.avi

mplayer lolza.avi

Es muxik yol. Igaz tudni kell, hogy hany bajt hosszu az avi, kulonben nem lehet benne tekerni ;)

Sajnos mplayer /dev/dvd sig11 -ezik, dehat nem lehet minden kerek;)

Khiraly

Meg a cikk írójának a balfiságát is mutatja...:

1. Minden fájl -- való igaz, a programnak kell tudnia, hogy amit open() az micsoda. De _mindenre_ open() és nem eszközönként, fájl tartalomtól függően valami más ugye...

2. Az, hogy minden text, az így ebben a formában... Egyébként meg a KISS-elvet úgy néz ki, nem ismeri... ls listázza, sort meg sortolja...

3. Nem tol minden lehetséges opciót/paramétert a keze alá a shell... való igaz, de pl. a Win-en a sima Tab-os parancssor-kiegészítéshez regedit köll...

4. Mi a baja az X-szel? Igen, elmegy egy esemény, meg visszajön egy esemény... Még mindíg jobb, mint az rdp-s bitmapvándoroltatás...

5. Nem látott ksh-t a kétirányú csövekke, bash-t a tetszőleges számú filedescriptorral...Persze, az stdin/stdout/stderr az a standard, de nem tilos többet megnyitni...

satöbbi...

( buran | 2005. 11. 08., k – 09:02 )

Hehe, azt hittem, nagyobb flame lesz ebből. :-)

Szerintem azzal a filozófiával, amit a szerző itt sugall, a unix már rég halott lenne. Én éppen ellenkezőleg gondoltam eddig, tehát mivel annyira szerteágazó (volt, van, lesz) a fejlesztés, ezért nem lehet egy API-t vagy egyetlen felületet ráerőltetni senkire sem, főleg ha a forrás ott a kezében és elég ideje van. Szoktam én is keseregni, hogy mennyire rossz, hogy nincs összefogva a fejlesztés, mint a Microsoft esetében, ahol okos tervezők megmondják, hogy merre haladjon a fejlesztés, és a programozók nem vitatkoznak hetekig/hónapokig a levlistákon, hanem dolgoznak a pénzükért. Mivel itt nincsenek határozott irányelvek, ezért jó ötlet volt az egész alapjait egységesre tervezni, hogy legalább a programok logikája azonos legyen, így van minimális esély a portolásra.

Vannak jó megfontolások a cikkben, nem mondom, de szerintem a unix ma pont az emberek gondolkodásának, igényeinek sokféleségét mutatja ezzel a rengeteg felülettel, shellel stb. a Windows felület és API pedig határozottan és egyértelműen megmondja, ezt _így_kell_ használni és nem máshogy. (Hozzátéve, hogy ez az "egységes használat" kb. 3-4 évenként lecserélődik, csak hogy a programozók is meg tudjanak élni valamiből, hehe.)

Mindenki döntse el saját maga, hogy külön utakon akar járni, vagy elfogadja azt, amit mások mondanak és aszerint dolgozik. Mindkettőnek megvannak az előnyei és hátrányai, ezt most hadd ne soroljam.

Még egy: majd ha az Intelnek meg tudjátok magyarázni, hogy dobja már ki azt az ócska ***** 286 és 386 utasításkészletet, vagy a videókártya-gyártóknak, hogy nincs szükség CGA, EGA és VGA módra, akkor majd a unixból is ki lehet dobni ezeket a dolgokat... :-)

zeller wrote:
> 4. Mi a baja az X-szel? Igen, elmegy egy esemény, meg visszajön egy
> esemény... Még mindíg jobb, mint az rdp-s bitmapvándoroltatás...
Zizzents be egy 33k6-os modemet, csattanj fel az internetre és próbálj
meg grafikus programokat használni RDP-n és X-en keresztül.

Az RDP használható, az X nem, legalábbis nekem ez a tapasztalatom.

On 2005-11-08, Nagy Attila <bra@fsn.hu> wrote:
>
> zeller wrote:
>> 4. Mi a baja az X-szel? Igen, elmegy egy esemény, meg visszajön egy
>> esemény... Még mindíg jobb, mint az rdp-s bitmapvándoroltatás...
> Zizzents be egy 33k6-os modemet, csattanj fel az internetre és próbálj
> meg grafikus programokat használni RDP-n és X-en keresztül.
>
> Az RDP használható, az X nem, legalábbis nekem ez a tapasztalatom.

Jaja, ezt csak megerositeni tudom.

Ott a szegeny VNC is, de low bandwidth mellett csak 8 bites
szinmelyseggel hasznalhato so-so, ami nagyon faj.

Na de... vannak X proxy-k is a vilagon... problata mar valaki?
(En egyszer akartam, de vmiert nem ment es hagytam a fenebe az egeszet.)
Ha csak egy hack is, de talan egy mukodo remote desktop megoldas.

No es... a kovetkezo meg eleg igeretesnek tunik
http://freenx.berlios.de/ bar meg ezt se probaltam.

Szoval a lenyeg, hogy nem olyan egyszeru elet, hogy az X
alacsonyszintusege minden ertelmes remote bizbazt dugaba dont Unix
alatt...

Cs.

a lényeg nem az hogy az ls magától is tud sortolni, mert ez csak egy triviális PÉLDA -- más feladatnál, más programokkal ugyanez a probléma (minden kimeneti karakter csak karakter, nem definiált karaktersor, pl. mérőszám és mértékegység) előfordulhat, és ott nem feltétlenül megoldható!!

Ertem, amit irsz. Van is benne logika. De itt szerintem az a szint van, ahol az ember alacsony szinten tudja nezni az adatokat, (pl. shell es ls), es magas szinten, pl. valami alkalmazas.

Egy shell-ben hogy a fenebe lehetne karakterek helyett mas a kimenet? Hogyan jelenitene meg?

Alkalmazasra meg van jo pelda. Lehet az ls kimenetet darabolni szovegfeldolgozo kis programokkal, vagy lehet C-bol lekerni a konyvtar elemeit, es minden strukturaelemet okosan kezelni, a szamot szamkent, mertekegyseget mertekegysegkent.

Pl. ha Konqueror-ban kerek egy konyvtarlistat reszletekkel, akkor nem csak karaktereket kapok az arcomba, hanem oszlopokat, amik megjelenitese a programozotol fugg.

Semmi akadalya annak, hogy a meret 3M es 5k legyen megjelenitve, es megis mukodjon a sorbarendezes.

Shell alatt ez nem megy egyszeruen, de szerintem nem is ez a cel.

Persze orulnek, ha du -sh * | sort mukodne, de ha nem megy, akkor ha akarom, irhatok ra egy scriptet.

Szoval szerintem van ilyen problema, de nem a shell szintjen kell ezek megoldasat elvarni, hanem az alkalmazasok szintjen.

( nil | 2005. 11. 08., k – 11:54 )

Ez itten mán nem lényegi hozzászólás, arról a vonatról már lekéstem :-D

Magyar parancssori opciók! ÉLJEN! Csak, hogy minél "könnyebb" legyen hordozható script-et írni!

LOL:

ls --hosszu --szines=automata --mind

visszhang --sorvegejelnelkul --menekulesszekvenciafeldolgozas "...a..."

Mekkora jó is lenne, ha egy magyar shell-scriptet egy angol vagy egy német rendszergazda nem tudna megérteni... Nem baj, ha a német nem érti meg, az a lényeg, hogy nem is fut le nála! :-D

SUM() vs. SZUM()

Megoldás: Shellscriptbe angolul írjuk, a sima parancsokat meg adjuk ki magyarul :-D

Szerintem maradhatunk valami olyasmiben, hogy a parancssor az rendszergazda és programozó interfész, a GUI() meg felhasználó interfész. És ez így van jól!

Üdv: Nil.

UI: Ha már így be vagyunk zárva az angol nyelvbe, legalább az vigasztaljon bennünket, hogy még mindig kibaszhatunk a német és egyéb kollegákkal, ha magyar változóneveket és kommenteket használunk. Javítottatok már német Java kódot, amelyben olyan változónevek is voltak, amiben umlautos á volt? :-DDD