Patrick - Hogyan nehezithetik meg rossz eszkozok az egyszeru dolgokat

Sokan kerdezik, miert utalom a Debian-t. Csak egy momentum: link.
Barki, aki ertelmes ember, belatja, hogy ez NEM az, amit az ember szeretne. Nem kicsit nem az, NAGYON nem az. Foleg, hogy ez sokeves bugg/rossz feature mar.
Es igen, ilyen apro dolgokkal tudja az ember elcseszni a napjat - mar az elejen.

( pch v | 2009. 01. 22., cs – 08:03 )

1.: van csomagkezelö
2.:

pch@pch-laptop:~$ sudo apt-cache search openoffice
....
....
....
openoffice.org - OpenOffice.org irodai programcsomag
openoffice.org-base - Openoffice.org irodai csomag – adatbázis-kezelő
openoffice.org-base-core - OpenOffice.org irodai csomag -- libdba
openoffice.org-calc - OpenOffice.org Calc – táblázatkezelő
openoffice.org-common - Az OpenOffice.org irodai csomaghoz szükséges architektúrafüggetlen fájlok
openoffice.org-core - Az OpenOffice.org irodai csomaghoz szükséges architektúrafüggő fájlok
openoffice.org-dev - OpenOffice.org SDK -- development files
openoffice.org-dev-doc - OpenOffice.org SDK -- documentation
openoffice.org-draw - OpenOffice.org irodai programcsomag – rajzoló
openoffice.org-evolution - Evolution címjegyzék-támogatás az OpenOffice.org-hoz
openoffice.org-filter-binfilter - Örökölt szűrők (például StarOffice 5.2) az OpenOffice.org-hoz
....
....
....

szal nekem jó

pch

Tudod, a ... altal eltakart reszekkel van a gond. Ha en beutom, hogy apt-cache search valami, akkor a valami-t a nevukben es/vagy a leirasukban tartalmazo csomagokat keresem, a gkrellm pedig baromira NEM az. Meg csak KOZE sincs hozza.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A probléma az, hogy hrgy84 (és mások is) megfeledkeznek a "leírásukban" részről.
A megoldás az lehetne, ha az apt-cache search alapértelmezésben csak a csomagnevekben keresne, és csak valami kapcsoló megadása esetén a leírásban. Mondjuk engem nem zavar így sem ahogy most működik.

Hhhhhh....

Oke, megint atsiklottal felette:

That's pretty much what I asked for. Now ...
apt-cache search openoffice
It spews out 936 results. That's about 934 more than I expected. And there's some gems included ... 

 
language-support-xh - metapackage for Xhosa language support
libhyphen-dev - ALTLinux hyphenation library - development files
bkchem - Python based chemical structures editor 
gkrellm-hdplop - A hard drive activity monitor GKrellM plugin
lsr - The Linux Screen Reader for GNOME
recoll - Personal full text search package with a QT GUI                                                        
strigi-utils - command-line tools for Strigi Desktop Search
xjed - editor for programmers (x11 version)
language-pack-gnome-oc-base - GNOME translations for language Occitan (post 1500); Provençal (post 1500)
language-pack-kde-fur-base - KDE translations for language Friulian
ttf-opensymbol - The OpenSymbol TrueType font

Kiprobaltam, hasonlo az eredmeny. Legyszives magyarazd el az okat, nagyon erdekel.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hát ha magadtól nem tudsz rájönni: benne van a nevükben vagy a leírásukban az openoffice string. Tehát pontosan azt csinálja, amit te mondtál, hogy csináljon.
Hogy miért van benne a leírásokban az openoffice string, az már más kérdés, és valóban megkérdőjelezhető. De hogyha ezzel van problémád neked és a mélyentisztelt linkelt gentoohuszár úrnak, akkor miért a csomagkezelőt fikázzátok?

Nem a csomagkezelőt fikázzák, hanem a projekt csomagolási elveit szerintem. A csomagkezelőnek vajmi kevés köze van ahhoz, hogy hány csomagot és milyen függőségekkel kell kezelnie. A csomagok létrehozása, a függőségi fa elkészítése emberi feladat. A csomagkezelő nem csinál mást, mint a neve mondja: kezeli a csomagokat, melyeket a kezelésére bíztak.

Azert, mert altalaban a rovid leirasban nincs is benne a keresoszo, csak a hosszuban. Amikor a keresesi eredmeny kijon a kepernyore, tomentelen irrelevansnak latszo talalat van, mert alapvetoen a rovid leiras jelenik meg, ahol nyoma nincs a keresoszonak. Ketto dolgot lehet ilyenkor tenni:
1) eleve nem keres a hosszu leirasban, mert 80%-ban irrelevans talalatokat fog adni, foleg ilyen csomagolasi policy mellett
2) a talalati lista vegere pakolja az ilyen talalatokat. A legvegere.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Na latod, ez mar egy hozzaallas. Mondjuk Gentoo alatt is csak rovid leiras van, igy itt is kisebb az irrelevans talalatok aranya, valamint esearch es eix eseteben van regex. De azert hangsulyozzuk ki, hogy nem a hosszu leiras a gond, hanem hogy abban is keres.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Dwokfur v | 2009. 01. 22., cs – 08:37 )

Ja, a linkelt oldalon az első példához nincs odaírva a parancs: 

emerge --search openoffice

.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( utpKabel | 2009. 01. 22., cs – 08:43 )

Nincs ebben semmi különös, csak te nem szoktad meg. Szokás szerint a -common az architektúrafüggetlen közös rész, a -core pedig az architektúrafüggő. -base meg azért van, mert ez az adatbáziskezelő neve, mint ahogy a táblázatkezelőnek Calc, a szövegszerkesztőnek meg Writer. A csomagok darabolásának van egy óriási előnye a bináris disztribúciókban, de ezt most nem árulom el, mert hosszú.

( f0xhu v | 2009. 01. 22., cs – 09:01 )

Uhm. Wow. base, core and base-core. It's really frustrating ... how do I know what to use?

Azért ez picit PEBKAC. Tény, hogy ilyen kontextusban félrevezető Base-nek hívni az OOo adatbáziskezelőjét,
de elvileg ha már ennyire advanced user, akkor ezzel igazán illene tisztában lennie.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

A gond nem is ott keresendo, hogy o nem lenne tisztaban vele. Itt inkabb a hozzaallas a problema. A Debian-nak van egy alap elnevezesi konvencioja a splitted csomagokra, az openoffice eseteben viszont elvi nevutkozes van (ugye, base). Meg csak kiserlet sincs a feloldasra.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( uid_228 | 2009. 01. 22., cs – 09:02 )

Az sajnos nem a Debian hibája, ha a linkelt cikk szerzője retardált és nem lát a Gentoon tovább, illetve a doksit sem olvassa el.

apt-get search ^openoffice

Regexp, nem tudom, hogy ez a kifejezés mond-e neki valamit. :)))

--
"Only an expert can deal with the problem"

$ apt-cache search -f gkrellm-hdplop
Package: gkrellm-hdplop
[...]
Description: A hard drive activity monitor GKrellM plugin
It monitors your hard drives by sending visual stimuli to your cortex
each time your /dev/hdx writes or reads anything. Try to launch
openoffice and enjoy the wmhdplop show.
[...]

Tehát mégegyszer: mi is a probléma? (Mármint azon kívül, hogy se a linkelt user, se te nem gondolkoztok...)

A fenti problema sajnos mindket apt eseteben fennall, ugy hiszem feature, vagyis inkabb tervezesi hiba.
Ertem en, hogy a grep ezert jo, de akkor ennyi erovel adjanak egy adatbazis dump eszkozt a kezembe, a grep abbol is kiszedi nekem ami kell, es gyorsabb, mintha az apt-cache search kimenetere varok.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mi a problema? Tenyleg nem latod? Biztos rajtad van a szemuveged? Es te tenyleg gondolkodsz?

Mi a jo budos edes nehezseget keres barmilyen gkrellm plugin egy alapvetoen OPENOFFICE-ra iranyulo kereses vegeredmenyeben?! MIT?!
De tudom, nalatok nem szokas az orrotok hegyenel messzebbre latni. Latod, ezert nem hasznalok debiant, hacsak tehetem.

Nem lenne szar, meg meg el is lehetne viselni a hibait, ha a kozossege nem olyan lenne, amilyen. Nem az a gond, hogy atsiklottal felette, hanem az, hogy nem feltelezed masrol, hogy jo okkal kepes hibanak felfogni a linkelt tenyt. Neked jo, mert te leszarod, mogeraksz egy grep-et es kesz, de... ahh, mindegy, ugyse erted meg.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

De, teljesen tisztán látom a problémát: nekiálltál fikázni valamit, amiről hamar kiderült, hogy alaptalan, mire lazán váltottál más fikázására, ami már történetesen jogos is, de mégis úgy csinálsz, mintha kezdettől fogva igazad lett volna. A gentoo közösségben ez a módi?

Figyelj, nekem kezdettol fogva a debiannal van problemam. A csomagkezelo keresoresze mindenkeppen szar, kicsit fejlebb leirtam, mit lehet a fenti esetben tenni. Maga a megkozelitese nem jo az egesz problemanak, de persze mivel evek ota igy van, jo ez. A tizmilliard legy tipikus esete.

Masfelol: eleve te kezdted a Gentoo-t hasznalo emberek fikazasat. Ismeretlenul. Fingod nincs, kicsoda flameeyes, mit csinal, mi fuzodik a nevehez, de mar lefikaztad (es nem csak te). Mert a Gentoo hasznalok hulyek.

Ezek utan megis milyen reakciot vartal?

Amugy meg mindig erdekelne, mit keres a gkrellm egy openoffice-ra iranyulo keresesben. Vagy akar annak az okara, miert szerepelhet egy teljesen irrelevans, viszont eselyes keresoszo egy ilyen program leirasaban. Bizonyitsd be, hogy oka van!
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az egy dolog, hogy a csomagkeszito farok volt. De tudod jobb helyeken az ilyen szovegeket nem lehet csak ugy onkenyesen belevagni a csomagba, foleg, ha le lesz forditva (peldaul *ubuntu eseteben), hanem jova kell hagyatni. A Debian ez alapjan vagy nem annyira professzionalis, mint amilyennek mondjak, vagy csak szimplan hanyagok a lektorok.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"A csomagkezelo keresoresze mindenkeppen szar"
Szerintem nem. Nem azért, mert mindig is így volt, hanem - mint azt már írtam is - mert legtöbbször a default viselkedésére van szükségem.

"eleve te kezdted a Gentoo-t hasznalo emberek fikazasat."
A hozzászólások timestampjein végignézve én nem így látom.

"Fingod nincs, kicsoda flameeyes, mit csinal, mi fuzodik a nevehez, de mar lefikaztad (es nem csak te).
Valóban nem tudom ki az, és mit csinál. De azt látom, hogy ha problémája van, akkor azt nem tudja kellő pontossággal leírni (hint: blogbejegyzés címe).

"Amugy meg mindig erdekelne, mit keres a gkrellm egy openoffice-ra iranyulo keresesben."
Mert benne van a csomag leírásában az openoffice string, amint azt fentebb már mondottam volt.

"Vagy akar annak az okara, miert szerepelhet egy teljesen irrelevans, viszont eselyes keresoszo egy ilyen program leirasaban."
Nem tudom, szerintem sem kellene benne lennie, de már ezt is írtam.
Viszont ez nem a csomagkezelő hibája.

" ( sz | 2009. január 22., csütörtök - 10:25 )
[ ... ]
(Mármint azon kívül, hogy se a linkelt user, se te nem gondolkoztok...)
"

"( hrgy84 | 2009. január 22., csütörtök - 10:47 )
Nem lenne szar, meg meg el is lehetne viselni a hibait, ha a kozossege nem olyan lenne, amilyen
"

Ez jelenik meg az en olvasatomba. Valoban, Adi kisse korabban kezdte, de kettonk kozul a tied a korabbi bejegyzes. Del ehet, hogy a 25 > 47, es en nem tanultam matekot.

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Erdekes, nekem az esetek 98%-ban arra van szuksegem, hogy adott nevu csomagra rajojjek, a debian konvencioi szerint hogy hivjak. Az apt-get meg a tobbi az meg hellyel-kozzel emberi default-okkal rendelkeznek, azt ketsegkivul alairom (mas baj van veluk, de mindegy).

Egy dolog az, hogy nem tudja valaki megfogalmazni pontosan esetleg a problemajat (vagy nem is akarja), es egy masik hogy ismeretlenul lehulyezed. Pont.

A masik ket kerdesre mar tobbszoros valasz szuletett.

Nyilvan en nem ertem meg jol a Debian feelinget, esetleg nem vagyok tulsagosan elvakult, es latom a hibakat. Ettol azonban nem kellene engem hulyenek nezni, es annak tartani. Ugy gondolom, azzal hogy Gentoo-t hasznalok sem tobb, sem kevesebb ember nem vagyok nalad. Nyilvan egy mas tudasbazisom van, de tartom magamat annyira hozzaertonek, hogy elfogulatlanul tudjak nyilatkozni arrol, hogy minek hogy kellene viselkednie _altalanossagban_ . Eleg sokaig hasznaltam Debian-alapu rendszereket, reszben ezeken tanultam meg a Linux alapjait. Tudom, hogy alapvetoen a Debian sem egy tul rossz rendszer - kezdoknek. De amikor mar ertem, hogy mi hajtja, es elkezdem latni a hibait - akkor elkezd sokkal kevesbe vonzo lenni. Amikor pedig talalok egy sokkkal jobb alternativat - akkor minden hiba egy kicsit felnagyitodik, ez teny. Am ne felejtsuk el azt sem, hogy az elvi hibaknak nem kell nagyito.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"A masik ket kerdesre mar tobbszoros valasz szuletett."
Részemről is.

"nem vagyok tulsagosan elvakult, es latom a hibakat."
Lassan tíz éve használok debiant, és a munkahelyemen - leegyszerűsítve - hibakeresésért fizetnek. Azt hiszem, hogy látok benne elég hibát magamtól is, még ha az itt felvetett csomagkezelős hibát nem is tartom hibának.

"Amikor pedig talalok egy sokkkal jobb alternativat"
Örülj neki, hogy találtál. Én még nemhogy sokkal jobbat, de még egy kicsit kevésbé szart se találtam, sajnos.

Szerintem téged kellene.
search regex [ regex ... ]
search performs a full text search on all available package lists
for the regex pattern given. It searches the package names and the
descriptions for an occurrence of the regular expression and prints
out the package name and the short description.

És FYI:
... if --names-only is given then the long description is not
searched, only the package name is.

Grrr... oke.

apt-cache search -> ez nalam azt jelenti, hogy a csomagadatbazisban keresek. Nem kell ehhez man-t olvasni. Eleve ugy kellene egy ilyent normalis programozonak megtervezni, hogy alapvetoen csak NEVEK kozt keresgeljen, es SUBSTRING match-el. Majd ha a kedves user ugy gondolja, hogy o regex-el es/vagy description alapjan is ohajt keresni, akkor majd beparameterezi. Erdekes modon, az advanced-nek nevezett Gentoo-ban ez az alapertelmezett viselkedes ugy az emerge mint az esearch eseteben. De sugok: yum-nal is substring match van by default (ha nem erzekeli regex kifejezes jelenletet), es csak a csomag ROVID leirasaban keres. Sot, amennyire emlexem meg YaST eseten is ez a helyzet.

Barmilyen furcsa, en nem szeretek olyan dolgokat latni egy kereses kimeneteben, aminek kurvara nincs koze a keresoszohoz. Ezen felul az apt-cache search mukodese is felgyorsulna, ha csak a RELEVANS talalatokat adna ki, az eleve eselytelenekkel nem is probalkozna. Hogy ez most a felhasznalok egy reszenek nem tetszik... ez van. Ugy gondolom a debian hasznalok jo resze viszont ezzel a reszevel eppen hogy szopik, meghozza szep iveseket. Nagyon szar dolog egy php modult keresve a fel gnome-t fellistazva latni amikor korbaccsal csapjak a hatadat. De neked meg biztos nem volt ilyen eseted.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A csomagadatbázis része a description is.
A saját tapasztalatom az, hogy gyakrabban van szükségem leírásban való keresésre, mint csak csomagnévben keresésre, ezért szerintem a default viselkedés jó.
Azt, hogy a yum és a yast borzalmak mit hogyan csinálnak, had ne tartsam már relevánsnak (;

En csinaltam mar debian csomagot, engedtessek meg, hogy ismerjem a felepiteset.

Alapvetoen kettofele description van, egy rovid, meg egy hosszu. A rovidet latod kiirva az apt-cache search kimeneteben, a -f pedig a teljes descriptiont kidumpolja. A gond arrafele keresendo, hogy az okre a hosszu description-ba megtalalja az openoffice-t (egy amugy teljesen irrelevans kontextusban, de errol mar elmondtam a velemenyem), es nagy boldogan kitolja a kepernyore. Ebbol szuletnek az ezres feletti talalati aranyok.
Nem tudom, en nem a wc -l kimenetevel szoktam versenyezni, hanem a relevans talalatok aranyszamaival. De PEBKAC, es kesz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hiába no, vagy tanuld meg használni a debiant, vagy használj másik rendszert, fentebb is mondták, meg má' én is mondtam szvsz, hogy nyílvánvalóan nem vagy debian hullámhosszon, ahogy pl. én sem vagyok a gentooén. Unalmas is lenne az élet, ha mind tökegyformák lennénk.

Nincs ezzel semmi gond, csak ettől még nem kell lehülyézni a debhasználókat (sem).

Amúgy aptitude search openoffice kész, ahogy mondták fentebb. Debian sarge óta 1ébként az ajánlott csomagkezelő az aptitude. ;-)

Nyílván tökéletes rendszer nincs. Mindegyikben vannak hibák, valamint olyan sajátosságok,melyeket egy egy használó hibaként él meg, úgyhogy találd meg azt a rendszert, aminek a hibáival, sajátosságaival együtt tudsz élni és használd azt :-)

---------------

r=1 vagyok, de ugatok...

A gond az, hogy ez a hiba meg az aprobbak kozul valo. Ezen felul a fonokomon kivul tenyleg senki nem kotelez a Debian hasznalatara, o meg ugye egy nem fontos szemelyiseg... Ez van.

(Oke, ez igy nem pontos. Elvben akarmilyen ingyenes linuxot hasznalhatnank, amennyiben megoldjuk, hogy a baromiregi (9i) oracle szerver valtoztatas nelkul elinduljon, illetve a tobbi oskovulet app is mukodesbe lepjen. Na most ez nagyobb szopas lenne, mint elviselni a mar kesz rendszer hulyesegeit).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Edesanyam. Jajnekem. Oke, ez esetben a csomagkeszito volt a farok. Ettol a debian minosege a szememben nem javult, mert egy normalis disztro eseteben az ilyen szovegeket jova kell hagyatni. Gentoo esetebe is van 1-2 ilyen, de 1-2 es nem tobbszaz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( zeroms | 2009. 01. 22., cs – 09:42 )

"Barki, aki ertelmes ember"

Ezek szerint erost rosz helyen jarsz, mert itt "keves ertelmes ember van" a te szemszogedbol nezve, ha jol sejtem min. 60%-a HUP felhasznalloinak debiant vagy debian alapu rendszert hasznal es kedvel.
--
UBUNTU 8.10 Rock's!
Type cat /vmlinuz > /dev/audio to hear the Voice of God.

( uid_14357 | 2009. 01. 22., cs – 10:44 )

+1 :D
Örülök, hogy nem vagyok egyedül a gondjaimmal.

Egyébként az "aptitude search" emészthetőbb kimenetet ad, de az sem az igazi.
--
\\-- blog --//

( uid_395 v | 2009. 01. 22., cs – 11:39 )

Probald meg pl. ezt:

apt-cache pkgnames openoffice

lass csodat. :) apt-cache manual javasolt :)

Bar tudom a pkgnames -el az lesz a bajod hogy a "rovid leirast, vagy a hosszut" sem irja ki.

De a pkgnames _csak_ a csomagnevekben keres es semmi mas infot nem ir ki csak a csomagneveket.

Udv
-krix-

Ertem en, hogy man rulez, nem kell magyarazni.
En viszont egyszeru ember vagyok, nekem a fogaskerekek nem bonyolult tancot irnak le, csak porognek.
Lassuk csak:
keresni -> szotar: find, search -> apt-cache find -> hibas -> apt-cache search -> jo.

Amugy nekem a pkgnames sokszor mar eleg, mert legtobbszor olyan esetekben hasznalom az apt-cache search -ot, amikor arra szeretnek rajonni, hogy pl. az oci8 ruby apijanak mi a csomagneve. Kosz a tippet.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szánalmas már sokadszor olvasni, hogy hogyan próbálod megmagyarázni a saját hozzá nem értésedet. Minden disztrónak van egy saját megközelítése, és a disztró megközelítése formálja az őket használó emberek megközelítését. Aki sokáig Debiant használ, az megtanul pár parancsot, és megszokja, hogy azokat úgy hívják. Az, hogy a Gentooban mások a szokások, az nem jelenti azt, hogy a Debian szar. Én például más disztribúcióban is gyakran az internetes Debian package search-öt használom, ha nem tudom, hogy egy paracs melyik csomagban is van.

Dehát én meg egyrészt azért utálom a Gentoót, mert a felhasználói 3x annyira beképzeltek, mint amekkora tényleges tudásuk.

Az az aprocska teny elkerulte a figyelmedet, hogy en Linuxozni is Debianon kezdtem el. Es mar akkor sem tetszett. Nem arrol van szo, hogy nagy lila Gentoo fan lennek, es fikazom a Debian-t.

A masik meg, hogy valoban nincs 25 ev gyakorlatom, de azert engedtessek mar meg, hogy egy iciripicirit ertsem, hogy mit irok. Vagy a Debianosoknal de facto ez a hozzaallas? Gyozz meg az ellenkezojerol.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.