PC Fórum
  • Kisebb betűméret
  • Eredeti betűméret
  • Nagyobb betűméret
Linux-gyűlölők klubja
2014-10-24T01:13+01:00
TomX
TomXPC Fórum
regisztrált tag
A témaindító hozzászóláshoz elmondom, hogy nem egy fősulin kötelező a linux ismeretéből vizsgázni. Szerencsére. Én windowst használok, de örülök a linux létezésének, és a ,melóhelyemen is Linuxon kell fejlesztenem. Ha nem értenék a linuxhoz, nem mehettem volna oda dolgozni. Ennyi.

Szóval nyugodtan parázz, már kötelező a Linux


doors
Mutasd a teljes hozzászólást!
Üdv!

Nem olvastam egy hozzászólást se de véleményt szeretnék mondani! Az aki ezt a topicot nyitotta valószínűleg egy pancser aki kipróbálta a linuxot és az első 10 percben nem volt benne profi ezért lefikázta. Vagy ha ki se próbálta akkor meg miért fikázza?

Mikor elkezdtem használni linuxot suseval kezdtem. Furi volt áttérni windowsrol linuxra mert windowson nöttem föl. Érdekes volt megszokni hogy ha valamit csinálok nem kell újraindítgatni a gépet és szinte nincs is hibaüzenet. Két hét után arra kényszerültem hogy windowshoz nyúljak. Ez is az általam legstabilabnak ismert windows ami céljaimnak megfelelt a Windows Server 2003 Enterprise Edition. Még be se töltött de lefagyott. Szal ennyit a topic nyitójárol meg a többi linux fikázóról. Csak egy hónapig hazsnáljanak linuxot! Megnézem utána marad-e a windows.
Mutasd a teljes hozzászólást!
Linux gyűlölök klubja? Na ez nekem új, ilyenről sem olvastam még egy fórumon
sem. Éppen ezért most tudatosan átnyálaztam a hozzászólásokat és azt
kellett megállapítanom, hogy na igen
hát kissé mellé ment a fórum, s inkább
Linux kedvelő központtá vált ;)

Na de akkor erre még teszek rá egy lapáttal én is :)

Látogassatok el ide, ha akartok magatoknak szerezni egy rekeszizom
mozgató kellemes, kb, 2 percet ;)

http://www.linuxbazis.hu/kampany.php]http://www.linuxbazis.hu/kampan..

Itt kattintsatok a Microsoft reklám
linkre :)

Üdv.
Tamás]
Mutasd a teljes hozzászólást!
eddig is peace volt, ezután is az marad
Mutasd a teljes hozzászólást!
igazad van, pongyolán fogalmaztam, általánosságban csomagkezelőkre gondoltam linuxon.


Akkor... peace?

Jaj, most tényleg én írjam be neked gugliba, hogy "linux security update incompatible" és csemegézzek belőle?


Beirtam, de "linux security update broke"-re ertelmesebb dolgok jottek ki. Atneztem az elso kb. 200 talalatot, talaltam 1 par foleg Mandrake, RedHat, SuSE bugreportot, debianbol csak 1-et, ahol az volt a sztori, hogy update utan az illetonek elszallt az X, amig ujra nem inditotta, mert me'g a regi libek voltak a memoriaban...

Udv. ax
Mutasd a teljes hozzászólást!
igazad van, pongyolán fogalmaztam, általánosságban csomagkezelőkre gondoltam linuxon.

De nem banom: mondj akkor inkompatibilis linux frissitest. Csak valami ertelmes dologgal legyen inkompatibilis...


Jaj, most tényleg én írjam be neked gugliba, hogy "linux security update incompatible" és csemegézzek belőle? Ennél azért magasabb szinvonalon állunk, mindannyian...
Mutasd a teljes hozzászólást!
Elég baj, mert a topic nem arról szólt...


Valo igaz.

Neked szövegértelmezési gondjaid vannak?


Nem, az ALU-mmal lehet valami, mert ezt most logikailag nem sikerult konzisztensse tenni. Segfault, coredump:

ha majd tudod mi az a wsus, sms, mom, akkor majd rájössz, hogy ezek fényévekre vannak az apt-get-től
(Lola)

idézd gyorsan nekünk, hol fikáztam az apt-t. Nincsen vele semmi baj, leszámítva, hogy alkalmatlan komoly vállalati környezetben, központosított patch menedzsment eszközök nélkül.
(Lola)

ax_ 2005.06.28. 15:50-es hozzaszolasa, amire valasz:
A mellébeszélést meg hagyjuk, én is tudok inkompotabilis linux frisítéseket mondani, de minek.
(Lola)

Es ugyebar, azt te is tudod, hogy apt mint olyan hol lelheto fel... Igen, mondd csak ki: a debian-ban.



De nem banom: mondj akkor inkompatibilis linux frissitest. Csak valami ertelmes dologgal legyen inkompatibilis...

Ja, talaltam meg 1 gyongyszemet:
nem csak security updatekről beszélünk, hanem patch menedzsmentről.


Mint emlitettem, a debianban van: dist-upgrade (ami megfelel 2 windows-verzio kozotti atallasnak, es szerintem ezt igen ritkan vegzitek patch-managementtel), es van security upgrade. A security upgrade meg ugyebar security upgrade.

Udv. ax
Mutasd a teljes hozzászólást!
ez igaz. bár amiről beszélünk (patch menedzsment komoly vállalati környezetben) nem ide tartozik.
Mutasd a teljes hozzászólást!
Nem csak most, en mindig is arrol beszeltem.


Elég baj, mert a topic nem arról szólt...


Neeem! Ne keress! Mondj!

Tudod: én is tudok inkompotabilis linux frisítéseket mondani, de minek..


Neked szövegértelmezési gondjaid vannak?

Megkérdezem akkor mégegyszer: debian=linux?
Mutasd a teljes hozzászólást!
...hogy scripthez akkor nyúl az ember, ha nincs a problémának kész, profi, megoldása.


Vagy ha nem akar ágyúval verébre lőni. Pl 1 sorból lerippelek 1 cd-t parancssorból és még ki is töltöm az ID3 tagokat. Pedig vannak profi cdrippelő progik.
Mutasd a teljes hozzászólást!
ja, hogy most már csak szerverekről (abból is kis számúról) beszélünk?


Nem csak most, en mindig is arrol beszeltem.

azt várhatod még, ugyanis egy szóval nem mondtam, hogy debiant használok keresni meg nem fogok...


Neeem! Ne keress! Mondj!

(Tudod:
én is tudok inkompotabilis linux frisítéseket mondani, de minek.
).

Have a lot of fun!
Udv. ax
Mutasd a teljes hozzászólást!
Biztos


biztos. pont ebben a fórumban tárgyaltunk ki egy egyszerű 10 soros wsh+wmi scriptet amit nem tudtatok értelmesen megoldani semmilyen scriptel unixon...

persze konkrét esetekben bármikor előfordulhat, hogy az egyik vagy éppen a másik a hatkékonyabb. Ezért írtam, hogy GYAKRAN.

Egyebkent meg nem ertem a negativ velemenyedet a scriptekrol, mint konfiguracios eszkozokrol.


Ezt is rosszul látod, napi szinten scriptelek mindenfélét. Semmi gondom a scripteléssel, ettől még tény marad, hogy scripthez akkor nyúl az ember, ha nincs a problémának kész, profi, megoldása.
Mutasd a teljes hozzászólást!
Miért kéne folyamatosan változtatni? Jah a telephely állandóan költözik és mindig ezer új gépet kapnak? Nem teljesen értelek.


Azt látom...
Azért kell változtatni, mert időben is változik, hogy melyik gép és mikor érheti el a rep-t és annak is mely részeit. (kijavították-e már a hibát stb)

ha változás van azt le kell kezelni. Akár scriptekkel is.


Igen, linux esetén folyamatosan változtatni a tűzfalbeállításokat, ami egy vicc egy ilyen problméára. (az meg a másik vicc, hogy így a teljes 80-as porot el kell zárjad a géptől...)

Mostanában a win nagyon erőlteti a parancssoros használatot a scripting hostot is, meg társait és ha valamit azzal meg akarsz osztani akkor bizony az megint "gányolás" a Te szavaiddal élve.


Bizony, ha scriptelnem kell, az ebből a szempontból ugyanúgy gányolás. Csak éppen - mint megint láttuk - egy újjabb probléma amire winen nem kell gányolni, linuxon meg igen, és sosem lesz olyan funkcionalitása mint winen.
Ahogy winen se lenne, ha nekem kéne "összegányolnom" a teljes patch menedzsmentet. Csak ugye winen nem kell...
Mutasd a teljes hozzászólást!
Aztán még folytathatnánk, hogy még, ha saját bütykölésre kényszerülsz, akkor is gyakran nagyságrendekkel kevesebb erőfeszítés winen scriptelni mint linuxon


Biztos? Perl, python, rubby mellett is tartod? Mert akkor kivancsi lennek, h. tudnal-e pl. egy SA (tudom, mostmar C, regebben Perl-ben volt, es nem is a megoldhatatlan problemak miatt valtottak) v. portage szintu dolgot gyartani barmilyen szabadon valasztott windowsos scriptnyelvben.

Egyebkent meg nem ertem a negativ velemenyedet a scriptekrol, mint konfiguracios eszkozokrol. Nezd csak meg pl. a Zorp-ot. Python-ban konfiguralhato, es allitom neked, barmilyen, akar a hajanal fogva elorangatott problemat is meg lehet vele oldani. Probald ezt utana csinalni pl. egy registry-szemleletu dologgal.

Udv. ax
Mutasd a teljes hozzászólást!
ja, hogy most már csak szerverekről (abból is kis számúról) beszélünk?
Ott persze, hogy nem érvényesül a patch ill. általában a központosított menedzsment különbsége. (de ezt le is írtam már, otthonra meg pár db géphez semmi szükség ezekre a fejletebb technológiákra, oda elég egy buta apt-get vagy winupdate. És münchent se véletlen hoztam fel, ennek ellenkezőjére, mikor is nagyszámú gépet kell karbantartani)

Innentől teljesen értelmetlen amit írsz, szó nem volt erről.

meg mindig varom a nalad hibat okozo debian-frissitest szamat, nevet, idopontjat, vagy barmilyen jellemzojet, ami alapjan be lehet azonisitani.


azt várhatod még, ugyanis egy szóval nem mondtam, hogy debiant használok keresni meg nem fogok, mert mint azt már korábban leírtam, már az elméleti síkon sem vagy képben a témában tesztelés nélkül nincs patchelés semmilyen rendszeren...
Mutasd a teljes hozzászólást!
Tűzfal rule-okat folyamatosan változtatni egy ilyenért, durva lenne... (és ugye iptables majd tudja, hogy mi az a szervezeti egység, telephely stb-stb)


Miért kéne folyamatosan változtatni? Jah a telephely állandóan költözik és mindig ezer új gépet kapnak? Nem teljesen értelek. Egyszer kell beállítani akár csak win környezetben is, ha változás van azt le kell kezelni. Akár scriptekkel is.

A scriptes gányoláshoz meg annyit még. Hányan használnak fórumokat amiket valakik összegányoltak annak idején és folyamatosan fejlesztik. Sőt a legtöbb opensource is

Szóval óvatosan a gányolással. Mert a wines programok sem úgy születtek, hogy egy zseni fél nap alatt egy egész vállalat managmentet leprogramozott és az egész világ ezt használja.

A másik. Mostanában a win nagyon erőlteti a parancssoros használatot a scripting hostot is, meg társait és ha valamit azzal meg akarsz osztani akkor bizony az megint "gányolás" a Te szavaiddal élve.

Peace
Mutasd a teljes hozzászólást!
Ugyannyi az esély, hogy egy hibás patch becsúszik a rendszerbe, ha vállalati policy alapján tesztelik, mintha tesztelés nélkül ráengedik minden gépre.


Nem. Kb. ugyan akkora az esely (ha nem kevesebb), hogy a debian fejlesztok hibaznak a patch tesztelesenel, mint hogy te.
Ettol meg persze tesztelheted, sot kell is, de biztos vagyok benne, hogy disztrib-enkent nem fogsz tudni 1 hibanal tobbet megfogni vele.

Debian=linux?


nem, linux=1 monolitikus kernel, aminek jo esetben nem feladata a patch-management. apt-get meg altalaban a debianban (meg a forkjaiban) van.

De inkompatibilitások mindenhol vannak, lehet, hogy "3rd party" alkalmazásokkal, de az teljesen mindegy.


Ezzel sosem vitatkoztam. De ha egy tiszta debian rendszert nezunk (a debian szerverek donto tobbsege), akkor nincsenek 3rd party alkalmazasok.

Mi meg biztos csak a kernelt futtatjuk több ezer gépen...


Azokat meg minek update-elitek...

Kérdezd meg egy hozzáértőtől, hogy komoly vállalati környezetben kell-e bármelyik rendszeren patcht tesztelni, terítés előtt és meglátjuk vicces-e.


Nem az volt a vicces, hanem a
Aki mást mond az nem kompetens a témában.
mondat. Azaz finoman leforditva, aki nem igy gondolkodik, az hulye. Kicsit kozepkor (meg a XX. sz. 2. fele)-feeling. Meg ha igaz, akkor is.

Mas: en a magam reszerol a debiant (meg a linuxot altalaban) szerver distrib-nek (OS-nek) tartom. Szervereknel pedig sokkal kevesbe ervenyesul a kozponti management (nem csak a patch~) aldasos hatasa, hiszen egyreszt kevesebben vannak, masreszt nincs 2 egyforma konfig, innentol kezdve mindegyiken egyenkent tesztelni kell.

egyébként ez a vita is a szokásos séma szerint ment:


Dejo-dejo, mar semank is van ra... Lola, nem akarsz vmelyik IT-konferencian eloadast tartani a linux-windows flame-ekrol?

Ps.: meg mindig varom a nalad hibat okozo debian-frissitest szamat, nevet, idopontjat, vagy barmilyen jellemzojet, ami alapjan be lehet azonisitani.
Mutasd a teljes hozzászólást!
te le tudod ennek ellenkezőjét vezetni az idézett mondatomból? Kétlem...


Mi alapján jött ki nálad a nagyságrendbeli különbség? Ez nem tetszett, erre írtam, amit.

Windowson is meg linuxon is megvannak a megfelelő eszközök, másképp kell használni őket és kész. Nem olyan egyzserű összehasolítani, hiszen van, amit az egyiken rövidebb megírni, van, amit a másikon. wsh-t, stb nem nagyon ismerem.

Szóval egy másik fizetős cuccot ajánlasz, ha menedzselni is kell? Érdekes. Habár olcsóbb mint a tivoli, nagyságrendekkel kevesebbet is tud. De abban igazad van, hogy legalább a központosított menedzsment csírája benne van...


Az volt a gondod, hogy linuxon nincs. Szerintem van, Valamelyik korábbi meddő linux-windows vitában már volt róla szó.
Mutasd a teljes hozzászólást!
aki nagyon sok szkriptet írt linuxon, annak semmiség összedobni.


te le tudod ennek ellenkezőjét vezetni az idézett mondatomból? Kétlem...

Szóval egy másik fizetős cuccot ajánlasz, ha menedzselni is kell? Érdekes. Habár olcsóbb mint a tivoli, nagyságrendekkel kevesebbet is tud. De abban igazad van, hogy legalább a központosított menedzsment csírája benne van...
Mutasd a teljes hozzászólást!
iptables scriptet szerkeszt, és itt állítgatom hogy melyik gép térben, időben, dimenzióban mikor férjen hozzá a z adott repóhoz.


Ezt azért külön ki el emelni, ez mekkora gányolás már?
Tűzfal rule-okat folyamatosan változtatni egy ilyenért, durva lenne... (és ugye iptables majd tudja, hogy mi az a szervezeti egység, telephely stb-stb)
Mutasd a teljes hozzászólást!
Aztán még folytathatnánk, hogy még, ha saját bütykölésre kényszerülsz, akkor is gyakran nagyságrendekkel kevesebb erőfeszítés winen scriptelni mint linuxon, de ezt már korábban kiveséztük...


Ezt hajtogathatod, attól még igaz, hogy aki nagyon sok szkriptet írt linuxon, annak semmiség összedobni.

Bár én valszeg egy SLES, vagy hasonló cucc környékén nézelődnék mindenféle management tekintetében - Novellnek jó cuccai vannak, csak nem használtam, mivel nem kerültem soha ilyen helyzetbe :)
Mutasd a teljes hozzászólást!
lásd 17:06-os hsz utolsó részét.
Szóról-szóra leírtad, linuxos mentalitással, ahogy kell...

A linuxos elképzelés a világról talán inkább olyan hogy ha valamire szükségem van akkor megoldom/elkészítem magamnak.


Csak az a bökkenő, hogy erre win alatt is megvan a lehetőséged (wsh,wmi,com,adsi stb-stb) csak éppen tizedannyi esetben sem kell ilyennel időt tölteni, mint linuxon, mert ezek beépítve elérhetőek winen, linuxon meg összegányolsz valamit, ami valjuk be évek alatt se tudna annyit mint amit korábban felsoroltam, csak a "naugye, hogy megoldható linuxon" kagegória. (amit egyébként gyönyörűen képviseltél ebben a hsz-edben)

Aztán még folytathatnánk, hogy még, ha saját bütykölésre kényszerülsz, akkor is gyakran nagyságrendekkel kevesebb erőfeszítés winen scriptelni mint linuxon, de ezt már korábban kiveséztük...
Mutasd a teljes hozzászólást!
tényleg nem érzed a különbséget a kézzel karbantartott kismillió repo között (teli redundáns anyaggal) és egy valódi központosított patch menedzsment között ahol egy repoból, policy alapján teríti a patcheket kismillió feltétel alapján


Ha mindenáron valami egységes felületen akarom a policy kezelést intézni akkor fogom és csinálok egy php -s oldalt ami egy iptables scriptet szerkeszt, és itt állítgatom hogy melyik gép térben, időben, dimenzióban mikor férjen hozzá a z adott repóhoz. Ezeknek a repoknak sima web foldereknek kell lenniük amit nem egy nagy kaland karbantartani, ráadásul nem is kell teli lenniük redundáns anyaggal mivel ugye feltalálták már a linkelést, ezeket meg ugyan úgy lehet a php alól intézni. Kliens oldalom meg simán beütemez az ember egy scriptet ami akár gépindításonként és óránként lecsekkolja a repot aztán vagy hozzáfér vagy nem, Ráadásul itt mivel nem több száz megás állományokban kell gondolkodni nagyon nem kell kétségbeesni a szávszélesség terhelés miatt, de ha mégis akkor arra is lehet megoldást találni. Fapados és barkács megoldás de működik, és a célnak tökéletesen megfelel.

persze, hogy nem, ha csak apt-get-ig jutottál a patch menedzsment témakörében,


Honnan tudod hogy meddig jutottam patch management témakörben? Miért nem lehet személyeskedés nélkül folytatni egy társalgást? Egyáltalán van e szükség linuxnál patch managementre, mivel itt alapvetően nem patchek hanem csomagok vannak. Az apt is alapvetően egy csomagkezelő frontend és ebből adódóan alkalmas csomagfrissítésre. Ezeknél a rendszereknél meg valahogy nem jellemző hogy ha felteszek egy hivatalos csomagot akkor az hazavág 3 másikat, főleg mivel az apt tud rekvizit és konfliktuskezelést végezni.
Lehetne tovább ragozni és komplikálni a kérdést de tök felesleges mivel nemigazán van rá életszerű igény. Ha valamely csomag túlélte a teszt periódust akkor nyugodtan mehet a gépparkra mivel nem sok vizet fog zavarni.Az meg hogy ez mikor történjen úgy is a lokális körülményektől függ és olyan jellemzően nagyon nem változik.

Persze ez tipukus linuxos elkpzelés a világ működéséről.


A linuxos elképzelés a világról talán inkább olyan hogy ha valamire szükségem van akkor megoldom/elkészítem magamnak. De ha mégis azt akarom hogy mint a sültgalamb a számba hulljon vagy éppen nem vagyok képes arra hogy magam találjak megoldást a felmerült problémára vagy igényre, akkor lehet használni meglévő alkalmazásokat akár jó sok pénzért is. A lényeg, mindenre lehet találni megoldást csak esetleg lehet hogy igényel némi kreativitást. Aki viszont ezt nem tudja vállalni az szerintem inkább keressen magának más hivatást.

Ahogy az is, ha a dpkg -l -t valaki patch állapot kimutatásnak gondolja. (szerv. egységenként, telephelyenként csoportosítva, action-ökkel, értesítésekkel megtűzdelve stb-stb)


Itt megint felmerül hogy az ember fogja kicsit megdolgoztatja az agyát és megoldja hogy a parancs outputja egy adatbázisba kerüljön, onnan meg már olyan lekérdezéseket intéz amilyen jólesik neki.

Ráadásul az így trenírozott probléma megoldó képesség és kreativitás az élet más-más területén is hasznossá tud válni:)
Mutasd a teljes hozzászólást!
Debian stable, valamint stabil windows összehasonlítása


én amikor az apt-get és egy valódi patch menedzsment szükségességét vizsgálom nem korlátozom le egyetlen disztrib egyetlen verziójára a kérdést.
De akár le is korlátozhatom ugyanis nem csak security updatekről beszélünk, hanem patch menedzsmentről. (de biztos vagyok benne, ha érdekelne és keresnék, ott is találnék valami inkompatibilitást, de nem érdekel, mert a téma szempontjából teljesen lényegtelen)

Ez is automatizálva van?


Van ami igen, van amit az alkalmazásgazdák tesztelnek.
Mutasd a teljes hozzászólást!
legalább a fele nem a patch problémája, hanem a felhasználói alkalmazásoké


És hogy történik a felhasználói programok tesztelése? Ez is automatizálva van?
Mutasd a teljes hozzászólást!
Debian stable, valamint stabil windows összehasonlítása mellett nem értelmezhető a köv megjegyzésed.

Debian=linux? Nocsak.
Mutasd a teljes hozzászólást!
változó, mondjuk 5-10-re saccolnám, amibe beletartoznak a nem oprendszerek patchei is.

persze ismét kiemelném ennek legalább a fele nem a patch problémája, hanem a felhasználói alkalmazásoké, ilyenkor policy-val kivételt képzünk az adott alkalmazást futtató userek gépére, a többire felmegy a patch, értesítjük a 3rd party alkalmazás fejlesztőjét aki kijavítja a programot, kivesszük a kivételt és felmegy a maradék gépekre is a patch. (értesítés megy a rendszergazdáknak, hogy mely gépekről hiányzik melyik patch és miért)

És persze olyan is van, hogy csak apró kozmetikai problémát okoz valamelyik programban egy patch, ilyenkor ugyanúgy terítődik minden gépre a patch, csak jelezzük a fejlesztőnek a hibát.
Mutasd a teljes hozzászólást!
egy hibás patch becsúszik a rendszerbe


Saccra évente hány hibás patch-et fogtok a "vállalati policy alapján" történő teszteléssel?
Mutasd a teljes hozzászólást!
egyébként ez a vita is a szokásos séma szerint ment:

L: gagyi a win, mert xy-t se tud.
W: dehogynem tud, sőt jobban is tudja mint a L, mert ...
L: Áh, L-al ... simán megoldható
W: kiderül mégsem megoldható
L: tényleg nem megy, de igazából nincs is rá szükség (vagy: pár ezer soros scriptelből megcsinálható, igaz, hogy karbantarthatlan és még mindig a felét se tudja, de "naugye, hogy a L is tudja")

Mutasd a teljes hozzászólást!