Patrick - Hogyan nehezithetik meg rossz eszkozok az egyszeru dolgokat

 ( hrgy84 | 2009. január 22., csütörtök - 8:53 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

"Ha en beutom, hogy apt-cache search valami, akkor a valami-t a nevukben es/vagy a leirasukban tartalmazo csomagokat keresem"

Akkor mi is a probléma? Pontosan ez történt.

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:

Patrick írta:
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.

Vess egy pillantást a blogbejegyzés címére.

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.

Szerintem az 1-es a járható út. Frugalware esetében csak rövid leírása van a csomagoknak, és az ember általában nem is kap irreveláns találatot egy pacman -Ss foo után, vagy ha mégis akkor még mindig van regexp.

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.

Mondjuk mi lenne, ha aptitudeban keresnének, az csak a csomagnévben keres.

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."

És akkor még nem is beszéltünk az eix-ről :)

--
\\-- blog --//

Siman lehetne esearch is.
--

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

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ú.

Te is fuss neki megeccer a linkelt cikknek. Siman atsiklottal az elejen.
--

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

Ok, látom.

Idézet:
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.

Hint: Gentoo user. Ne legyenek túl nagy elvárásaid tőle!

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.

Hát ez szörnyű.

Jót nevettem így reggel szerencsétlen blogszerzőn...

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"

Igen, mond. Tessek nekem elmeselni, hogy a gkrellm-ben mi matchel az openoffice-ra. Nagyon izgat, legyszi mondd el...
--

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

$ 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...)

ezert kell mogerakni egy | grep -i openoffice-t

mondjuk a debian csomagkezeloje elvileg tok jo, ubuntu alatt nem is nagyon volt vele problemam, debian alatt viszont erdekes modon rengeteget szoptam...

szoval debian nekem sem bejovos, bar vannak pozitivumai

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.

Milyen adatbázis dump eszköz?!
Egyrészt text alapú az egész "adatbázis", másrészt elnézve a 'grep openoffice /var/lib/apt/lists/*_Packages' kimenetét, én inkább maradnék az apt-cache-nél.

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.

"Edesanyam. Jajnekem. Oke, ez esetben a csomagkeszito volt a farok."

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.

"Valoban, Adi kisse korabban kezdte"
Ez itt a kulcsmondat.

De ha már itt tartunk, van nekem egy idézetem 7:53-ról: "Barki, aki ertelmes ember"

Végszó, függöny.

Abban a mondatban semmilyen kontextusban nem szerepelt a debian user, mint pejorative pelda. Egy debian user is lehet ertelmes, es egyben zavarhatja az apt-cache search ilyten mukodese.
--

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

Hát, nekem valahogy úgy tűnt, hogy aki szerint viszont apt-cache ilyen működése nem zavarja, mitöbb, egyenesen jónak tartja, az nem lehet értelmes ember. De biztos csak rémeket látok (;

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.

Sz@r? Lehet nekiugrani, és írni egy jobbat/sajátot, módosítani az eredetit úgy, hogy neked megfeleljen... Tudod: openszósz, úgyhogy akkor és azt túrsz/írsz bele a forrásba, amikor akarsz.

Tudod, az van, hogy hiaba talalod meg eleted szerelmet, az nem azt jelenti, hogy semmilyen nonemu egyeddel nem vagy koteles tobbe beszedbe elegyedni. Ez pont igy van a linuxoknal is.
--

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

gkrellm-hdplop

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.

pch

ha te ezt most komolyan gondolod meg a tobbiek, hogy egy searchre ezt kikell basznia, akkor ajanlom a dilihazat...

dehat mindig is tudtam, hogy a debian egy fos (legalabbis miota atalltam rhelre), pont az ilyenek miatt :)

Vegre valaki, aki megerti a problemamat. Az osszes ertetlenkedot el kellene kuldeni olvasni tanulni...
--

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

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.

Az a baj egyébként, hogy a csomagadatbázis két elemét defaultban egyként kezeli a keresés, ami logikailag tényleg nem jó, viszont leírás szerint működik, és van kapcsoló, amivel rá lehet beszélni a fejlesztők szerint kevésbé hasznos/kevéssé logikus működésre.

Nem csak a fejlesztők szerint kevésbé hasznos.

Mit keres egy gkrellm csomag leírásában az openoffice string? Nem a nevében, a leírásában? Főleg, ha nem függősége és tkp. semmi köze a két csomagnak egymáshoz?

Ezert mondtam azt, hogy az ilyen szovegeket jobb helyen jova kell hagyatni. Mondom jobb helyeken.
--

()=() 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...

Gyönyörű hozzászólás! +1

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.

Oracle? Annak RH dukál, az rpm csomagkezelő hülyeségeivel karöltve. Kutya vagy eb...

Igen, csak ennek meg a regi fajta RedHat kellene, nem ami most van yum-os meg minden kellemes. Na most azt meg meg az ellensegemnek se szoktam kivanni.
--

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

Hát a szitu az, hogy ha Oracle, akkor supported linux kell alá, mert ha beüt a baj, akkor a Metalinken azt fogják mondani, hogy reprodukáld a hibát supported linuxon, csak akkor foglalkoznak vele. Szóval linuxos Oracle DB szervernek nagyon jó választás a Redhat.

FYI: a 9i mar regen nem supportalt Oracle, innentol meg annyira mindegy.
--

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

Ha jól emlékszem, turul16 egyszer azt mondta, hogy ha neki Oracle-t kell telepíteni, akkor megmondja az Oracle programnak, hogy gentoo redhatje van. (echo x.y > /etc/redhat-version)

A kernel, a libek és az fs apró eltérései azért oda tudnak alattomosan tenni az Oracle alá...

Annyira nem. En szepen felpakoltam egy 10-es vagy 11-es ora-t G-re.
--

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

Érdekes, én a rhel-t tartom fosnak, miután debian után használnom kellett egy darabig (;

biztos sok enterprise cuccot futtatsz, es nagyon fontos a megbizhatosag, meg hogy ne fossa ossze magat a rendszer..

(gyk a sok hobbikoder biztos jobbat csinal a debiannal, mint a fizetett rhel fejlesztok! ;-))

Hát, enterprise-nak éppenséggel nem nevezném (ibm csak rhel-en támogatja rendesen a cell-re való fejlesztést), de rendszeresen összefosta magát. És igen, pont a csomagkezelő.

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.

"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.

+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 --//

Igen, sajnos mindenkepp kell moge a grep. Az aptitude annyival jobb, hogy asszem az csak a short description-t nezi meg, a hosszut mar nem.
--

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

Nem kell mindenképp. Már írták fönt: --names-only

A grep rovidebb.
--

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

--na<tab> = 5 karakter
| grep ^openoffice = 18 karakter

szerk.: hup megette a kacsacsőreimet (;

Te mondtad már valaha az életben, hogy "igazad van"?
(Költői kérdés.)

Manual olvasasa utan rajohetsz hogy nem kell kiirni a --names-only -t, ugyanis -n a roviditese. :)

Udv
-krix-

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.