Dropline GNOME 2.8.2

Miben nyílvánul meg, hogy kifejezetten slackira készítették?

slackware csomagokban ;-)

Korábban arról is volt hír, hogy a slack ejti a gnome-ot. Azóta

az abiwordot és a gnumericet le is választották a gnómról,

pont azért, hogy önállóan, a gnóm könyvtárak nélkül is

fussanak.

Sajnos nem látom át a gnome előnyeit. Mellesleg a KDE-jét

sem.

Szeretnék egyszer egy olyan disztribúciót látni, ahol

mindenből egy max 2 van. Nem kell 10 böngésző, 20

ablakkezelő és 30 csetelő program. Legyen 1 vagy kettő,

de az tuti legyen.

Őszintén: ki használ twm-et vagy olwm-et? ki használ

fvwm95-öt és még sorolhatnám. Ki használ elvist, hányan

használnak emacs-ot? Nem azt mondom, hogy ezek

a programok rosszak, csak az emberek 98 % nem használja

őket. Aki pedig használja, az elég vájtfülű ahhoz, hogy

le tudja magának tölteni.

Ez az egész ugyan nem tartozik szorosan az alaptémához,

ezért elnézést kérek, de a fejemben ez egy gondolatlánc.

A slack egyébként elég jól kordában tartott ilyen

szempontból.

És ki dönti el mi legyen benne és mi ne?

Szerintem a választási lehetőség jó dolog, nem muszáj mindent felrakni, a cd-n/dvd-n meg elfér.

Ki dönti el? Hát aki összeállítja a disztribúciót! A legnagyobb

gond szerintem a függőségekkel van. Az emberek nagyrésze

nem tudja hogy mi mire való, ezért nem meri babrálni

a csomagokat. Fenn van a vinyódon egy csomó felesleges

cucc, nem a helyet sajnálom, hanem nagyobb rendszer ==

nagyobb sebezhetőség és bizonytalanabb működés.

Erre valo a jo csomagkezelo, ami megmondja hogy ha ezt-meg-ezt le akarod szedni, mi minden jonne vele egyutt, meg ha upgradel az ember, akkor a nem hasznalt libeket leszedi (pl ha eddig minden libreadline4-et hasznalt, de upgrade utan mar mindegyik libreadline5-ot fog hasznalni, akkor libreadline4 felesleges -> leszedendo).

Debian + aptitude ezt szepen megcsinalja.

Nomeg, az ember feltesz egy kicsi alaprendszert, aztan kivalasztja mely egyeb dolgok kellenek neki - nem tesz fel olyat amirol lovese sincs hogy micsoda. Igy nem fog sokat foglalni a vinyon.

Az MP3 playeremhez kerestem drivert, találtam is, de valami elvetemült nyelven írták az userspace részét -> Objective CAML, hogy csak néztem, na mondom mi ez, jé van deb csomag, függöségekkel együtt felrakott volna 40MB-ot!!! csak azért , hogy le tudjam szedni a playáról a cuccot.

Ez van.... :)

de miért bizonytalanabb a működés abban az esetben, ha van 1 program amit nem használsz?!? szerintem nem ebben kellene keresni a sokszínűség hátrányait, hanem az emberi erőforrások szétforgácsolódásánál. pl. sok ablakkezelő -> sok programozó ugyanazt a funkciót kódolja le feleslegesen. de ez már maga nem a programok evolúciója? amelyiket nem használja senki, nincs karbantartója, az már nem kerül bele a következő kiadásba, szép lassan megszűnik. ha szükség van rá mert többen használják, akkor pedig igenis van létjogosultsága a programnak...

Hja, ilyen is van.. De ott a forras, at lehet irni mas nyelvre is (btw, milyen mp3 player?).. 40Mb meg manapsag alig valami (kiveve persze ha 20Mb-s vinyora rakod fel a stuffot, ami mellesleg egy 486-osban van, vagy hasonlo)

Igen, de aztán kell egy másik progi, aminek meg a komplett python környezet kell 70 tonna libbel, a harmadiknak ugyanez perlből és mindegyik gtk-s... :)

Aztán ott vagyunk, hogy 2 darab 500K-s progihoz 500mega libet kell telepíteni

üdv

Godot

Azert ennyire nem szornyu a helyzet szereny velemenyem szerint. Persze konnyu nekem, alapbol GNOME user vagyok, igy a 70 tonna libbol alapbol fent van 69 >;)

(Hozza teszem, jobb igy, mintha minden egyes libet minden egyes program sajat maga ujra meg ujra megirna, csakhogy a dependencyk ne legyenek olyan hosszuak)

On 2004-12-29, meditor <meditor@enternet.hu> wrote:

> Szeretnék egyszer egy olyan disztribúciót látni, ahol
> mindenb?l egy max 2 van. Nem kell 10 böngész?, 20
> ablakkezel? és 30 csetel? program. Legyen 1 vagy kett?,
> de az tuti legyen.

De igenis legyen 10 bongeszo es 20 ablakkezelo! Sot, legyen csomag minden
bongeszobol es ablakkezelobol ami el es mozog! Te majd telepited ami neked
kell. Esetleg legyenek installalasi profilok... Az, hogy egy adott csomag
altal hasznalhato lib-ek es egyebek kozul hany van megjelolve a metainfoban
mint fuggoseg, az mas kerdes. Ez az a pont, ahol a forrasalapu disztrok
elonyben vannak, mert ott ezek a fuggosegek dinamikusak (ld. Gentoo es USE
flags).

> ?szintén: ki használ twm-et vagy olwm-et? ki használ
> fvwm95-öt és még sorolhatnám.

Ha valamifele desktop emulaciot futtatsz (Xnest, Vmware, vnc, rdesktop,...),
akkor neha halas tudsz lenni egy ablakkezeloert, ami nem csinal semmit, csak
a minimalisat. Ill. ha az emulalt desktop is X+wm tipusu, orulsz, ha nem
ugyanaz a wm fut az emulalt desktopon, mint az igazin... Ilyenkor neha jol
jon a twm.

"Ki hasznal xlogo-t", kerdezhetned. Kinek kell, hogy a nagy X betu ott
logjon a kepernyo sarkaban? Senkinek. Szedjuk hat ki az xlogo-t a
disztribuciokbol! Node az xlogo nagyon hasznos diagnosztikai
eszkoz X engedelyek tesztjere, ne kelljen mar megvarnom, amig egy
Mozilla/OOo/Konqueror/... belapatolja a sok hulye libjet a memoriaba, azert,
hogy aztan azt olvassam, hogy "Unable to connect display :X.Y"...
Nem art, ha nem mindent a total end user - desktop user perspektivabol nezel...

Altalaban, tobb program ugyanarra a funckiora azert is kell, hogy ha az
egyik nem mukodik, akkor ki tudd talalni, hogy a programmal magaval van a
baj, vagy a backenddel... Pl. xmmsben elinditod az mp3adat, de nem hallasz
semmit. Az xmms installaciod broken, vagy az alsa beallitasokkal van baj?
(Esetleg kontakhibas a hangfalad...) Ilyenkor orulsz, ha van egy mpg123 is a
gepeden... (ez egy hirtelenjeben kiotlott mesterseges pelda, keretik a
peldat magat nem kritizalni).

> Ki használ elvist, hányan
> használnak emacs-ot? Nem azt mondom, hogy ezek
> a programok rosszak, csak az emberek 98 % nem használja
> ?ket.

Na azert az emacsot betenni ebbe a felsorolasba kicsit meredek...

> Aki pedig használja, az elég vájtfül? ahhoz, hogy
> le tudja magának tölteni.

Ha bamban csinalsz egy 'configure && make && make install'-t, v. bamban
kicsomagolsz egy third-party binaris tarballt a gyoker konyvtarban,
beszennyezed a rendszered: olyan fajlok kerulnek oda, melyek eredete,
hovatartozasa nincs nyilvantartva, nem tudod pontosan mit raktal be a
rendszeredbe, nem irt-e folul valamit, stb. Ha valamit adsz magadra, extra
erobefektetessel letrehozol egy csomagkezelodnek megfelelo csomagot, mielott
installalod a programot. Ez disztrib-fuggo mekkora erofeszites es mennyire
magatolertetodo eljaras... mindenesetre egy letezo csomag megkimel az ezzel
valo vacakolastol, es ez jo dolog.

Ha kivansagod szerint valo modon szukre veszi egy disztro a
csomagvalasztekat, nem kell valami nagy powerusernek lenni, hogy
megtortenjen veled az, hogy ki akarj probalni egy olyan programot, amihez
nincs csomag... Ok, hogy az ember "honositja" a kedvenc programjat, ha nincs
hozza csomag, nem nagy ugy. De ha mondjuk van 10 rajzoloprogram es ki akarom
probalni oket, nehogy mar 8-at honositani kelljen csak azert, hogy aztan
hatot ki is dobjak kozuluk azon frissiben...

A Windows usernek nem nagyon kell fajnia a feje az installacio mikentjetol,
csak letolti az install exet, vegigklittyelgeti, es rock'n'roll. Ez egy jo
dolog. Ennel mar csak az jobb, ha meg letolteni meg vegigklikkelgetni sem
kell, hanem csak kiadsz egy parancsot, mint pl. "emerge foo" v. "apt-get
install foo" es rock'n'roll. De hogy ez igy legyen, ahhoz kell, hogy szinte
mindenhez legyen csomag

On 2004-12-29, godot <szep@ekg.gov.hu> wrote:
>
> Az MP3 playeremhez kerestem drivert, találtam is, de valami elvetemült
> nyelven írták az userspace részét -> Objective CAML, hogy csak néztem, na
> mondom mi ez, jé van deb csomag, függöségekkel együtt felrakott volna
> 40MB-ot!!! csak azért , hogy le tudjam szedni a playáról a cuccot.

Az OCaml-rol tudni illik, hogy a belole keszitett binaris futasi sebessege
vetekszik a C/C++ bol forditottal, es amellett az OCaml megkimel a manualis
memoriakezelestol, a fuggvenyek elsoosztalyu objektumok ("functions are
first-class objects", nem tudom mi az/van-e adekvat magyar kifejezes), stb.
Na nehogy mar a fejleszto lemenjen ganyolni C-be azert, hogy neked ne
kelljen plusz negyven megat elhasznalnod a negyven gigas vinyodbol!

A C, C++, perl mellett kitalaltak mas nyelveket is, otletes, innovativ, a
programozo dolgat megkonnyito nyelveket, melyekkel konnyebb konnyebben
menedzselheto kodot irni, stb. Szerintem jo dolog, ha minnel hasznaljak
ezeket az "alternativ" nyelveket, es nem sajnalom toluk a helyet. "Hat, tok
jo lenne a programod, csak ne ilyen elborult nyelven lenne, ezt mifelenk
senki se beszeli" -- ez az egyik legbutabb kritika ami programot illethet.

Lasd a "better SCM initiative" kritikajat a (Lispben irt) Meta-CVS-rol
http://better-scm.berlios.de/docs/nice_trys.html, ill. az erre valo valaszt
http://users.footprints.net/~kaz/mcvs-criticisms.html, no meg Paul Graham
kulonfele irasait (pl. Revenge of the Nerds
http://paulgraham.com/icad.html, If Lisp is So Great
http://paulgraham.com/iflisp.html, Beating the Averages
http://paulgraham.com/avg.html).

On 2004-12-30, dzsekijo <dzsekijo@freemail.hu> wrote:

> Lasd a "better SCM initiative" kritikajat a (Lispben irt) Meta-CVS-rol
> [0] ill. az erre valo valaszt
> [1]

Mivel a kritika, ill. a valasz sokmindenrol szol, a felreertes elkerulese
vegett inkabb bemasolom a ide a relevans reszeket.

A kritika:

"Another downside to Meta-CVS is that it is written in Common LISP. Granted,
Common LISP is a very powerful and flexible language. However, it is not
very common (pardon the pun) on UNIX and other systems, and few people could
be expected to install a client if they need to install it first. If
Meta-CVS' author wishes to make it more popular, I strongly advise him to
re-implement it in C, Perl, Python or something more standard."

A valasz:

"> Another downside to Meta-CVS is that it is written in Common LISP.

Lisp is what has enabled me to write Meta-CVS. I had the ideas for Meta-CVS
in my head before I learned this language. I did not write Meta-CVS then,
despite being an expert C and C++ programmer, and reasonably well acquainted
with Perl. I made an abortive attempt to write it in C++, but quickly
scrapped that. So Meta-CVS was essentially once a project in search of a
programming language. That search ended when I `discovered'' Common Lisp,
but the realization that it was the ideal implementation language for
Meta-CVS only came after months of learning Lisp. When I look at the
essential elements that constitute the Lisp source code of Meta-CVS, and how
they rely on the language, it does not surprise me that I could not find the
motivation to write in C++. To get the same behaviors out of C++, I would
have to write mountains of irrelevant code which does nothing more than
badly re-implement half of the semantics of Lisp. (The reader is invited to
do a web search for `Greenspun's Tenth Law of Programming'').

Regardless of what computing platform you write for, you can `teach'' it to
`understand'' whatever programming language you want. Users don't care what
programming language you used as long as the software works, and they don't
have to know that programming language in order to use it. Of course, if you
prefer a very rare and unusual programming language, or are targetting an
obscure platform, you may have to write your own implementation of the
language of choice, or compromise your preference by choosing another
language.

With Common Lisp you don't run into this problem, at least on mainstream
platforms, because there are many great implementations, both proprietary
and free. It's easy to package a Lisp program for distribution, so that it
can be installed and used by people that don't know Lisp. Just include your
software and all of the necessary runtime support in a binary package.

If I had to target an embedded system for which no Common Lisp
implementation is available, I would have to reconsider my preference. But
Meta-CVS isn't embedded software. I care about running on Windows and UNIX.

Although no knowledge of Lisp is required to install or use Meta-CVS, its
users can expect to occasionally interact with a text file containing data
stored in Lisp form. The structure of this data is so obvious as to be
largely self-explanatory. Lisp is absolutely the best markup language for
structured data, so I would use it for storing data even in software that is
not written in Lisp. PRCS is a version control system written in C++, yet
uses Lisp notation to store its data in files. The well-known Rational Rose
CASE tool for designing object-oriented software stores models in a format
called `Petal'', which is closely based on Lisp. The IMAP4 protocol by which
millions of people access their e-mail boxes also uses a Lisp-like notation.

> [R]e-implement it in C, Perl, Python or something more standard.

Of these three languages, only C has an ANSI/ISO standard. Common Lisp is an
ANSI language. In fact it was the first object-oriented language to have an
ANSI standard. I suspect that Fish uses the term `standard'' to mean
`commonly installed by distributions of Linux'' or `popular with the recent
crop of Computer Science undergraduates''.

In conclusion, all that really needs to be said is this: there is currently
but one program which enhances CVS in the way that Meta-CVS does, and its
author produced it with Lisp. A non-producer cannot prescribe to the
producer by which causes he ought to have produced the effects of his
success."

> Őszintén: ki használ twm-et vagy olwm-et? ki használ fvwm95-öt és
> még sorolhatnám. Ki használ elvist, hányan használnak emacs-ot? Nem
> azt mondom, hogy ezek a programok rosszak, csak az emberek 98 % nem
> használja őket. Aki pedig használja, az elég vájtfülű ahhoz, hogy
> le tudja magának tölteni.

Hehe, ebben amit irsz az a poen, hogy a 98% a user (tartalom
fogyasztoja), a 2% akit pedig kizarnal a fejleszto (a tartalom
eloallitoja). A kettonek kicsit masok az igenyei, ha a userek elmennek
valami miatt akkor semmi nem tortenik, ha a fejlesztok akkor meg meghalt
az egesz.

--
....sutongi tti olleh
What a person wills and not what they know determines their
worth or unworth, power or impotence, happiness or unhappiness.