jestli to ale nahodou neni "obchodni politika" provozovatele serveru. ;o)
posledni dobou zde vychazi jeden "clanek vyvolavajici kontroverzni diskuse" za druhym... coz samo o sobe neni spatne (moznost srovnavani pokud autor vi, o cem pise), ale v tech dikusich se pak neda najit nic kloudneho najit (nepocitam-li urazky ruzneho kalibru).
kazdopadne efekt retezove reakce odkazu "nejctenejsi" a "nejzhavejsi diskuse" prinasi provozovatelum vice ctenaru (a prodane reklamy). pokud to nebude "bulvar", nic proti.
nechapu ale, proc bylo napr. v tomto clanku "absolutne nutne" jakymkoliv zpusobem SROVNAVAT freebsd s balickovaci systemy jinych distribuci...?
ano, pouzivam tento kompletni system zalozeny na 44bsd jiz nekolik let a nemel jsem v umyslu oznacit jej jako DISTRIBUCI (a vubec ne linuxu), takze oprava:
"SROVNAVAT balickovaci system freebsd s balickovacimi systemy jinych kompletnich systemu unix a distribucich linuxu..."
dobry? aktualni zustava otazka o smyslu onoho srovnani.
...o smyslu onoho srovnani v TOMTO konkretnim clanku.
<offtopic>
a abych zas nezahajil "flame", krome nejmenovaneho kompletniho systemu zalozeneho na 44bsd aktivne a ke vsi spokojenosti pouzivam k RUZNYM UCELUM sun solaris, nejmenovanou distribuci linuxu, "o ktere se všeobecně tvrdí, že má nejlepší balíčkovací systém v současnosti" (a ma!) a zrejme brzy (rad) proniknu do ibm aix.
doma mam g4 s jinym bsd systemem (mac osx) a obcas si nostalgicky vzpomenu na svou "prvni lasku" - sgi irix. jinak plan9 rules! :o)
</offtopic>
ma predchozi reakce byla o jinem: "flames" a zvysovani poctu zobrazeni. potazmo obcasnem srovnavani nesrovnatelneho. sorry.
kdyz uz jsem u toho plan9
http://ask.km.ru/3p/plan9faq.html
---------cut--------------
Subject: What is the symbol of the system?
The symbol of the system is white bunny Glenda. Here is how bunnies compare with penguins:
bunny: faster, more (re)productive (effective plumbing?), extensive networks, prone to colonisation, cuddly.
penguin: rather slow and unstable (on land), limited area of operation, rather formal attire(?), but works great under water
-----------------cut-----------------
:)))
A jak se teda pozna co je distribuce a co ne? Neni treba MacOS X taky distribuci nad jadrem FreeBSD (stejne jako FreeBSD samotne)?
BTW, na jednu stranu si autor stezuje, jak je tezke stat se Debian maintainerem, a na druhou stranu pripousti, ze do FreeBSD ports se dostane cokoli co tam kdo posle. Neni tohle pak trochu srovnavani jablek s hruskami? Debianovske baliky maji stejnou bezpecnostni podporu jako zakladni system (ehm, on vlastne zakladni system je taky z komunity a ne z nejake centraly).
Pokud by autor napsal clanek o tom jak si vyrobit balicek pod FreeBSD, znelo by to daleko verohodneji, nez kdyz na zacatku prohlasi jak slozite je delat balicky jinde (a pritom je jasne ze tomu moc nerozumi).
-Yenya
PS.(inzerce :-): Pokud je tady nekdo, kdo rozumi Gentoo a chtel by udelat cca hodinovou prednasku, necht se mi ozve mailem.
nekdy v lete 2003 jsem nasel chybu v http://fsp.sf.net FSP serveru, kdyz jsem
jej predelaval pro jisteho zahranicniho telef. operatora, ktery ho pouziva pro komunikaci na flaky linkach. Poslal jsem to Debian
sec. teamu + s patchi proti verzi, kterou meli ve stable. Asi to 3 dnu mne
odpovedeli a chybu potvrdili. Tim to skoncilo. Pak jsem asi kazde 2 mesice
bombardoval package maintainera (ktery o ni taky vedel) a security team. Kdyz
mne to po 3/4 roce prestalo bavit, tak jsem nakodoval 2 exploity a rozeslal
jsem je vsude mozne. Pak to jiz opravdu opravili a vydali security advisory.
http://www.debian.org/security/2004/dsa-416
Krome toho ty informace o bugu jsou v CAN spatne. Nejsou schopni si
precist ChangeLog z FSP o tom co a kdy bylo opraveno.
"Debian takes security very seriously. Most security problems brought to our
attention are corrected within 48 hours."
zbyva zde jenom dopsat: tech 48 hodin se pocita od doby, kdy nam zaslete
spolu s patchi take funkcni exploit.
fps ma (melo) podle vsecho spoustu security problemu.
viz. http://cvs.sourceforge.net/viewcvs.py/fsp/fsp/ChangeLog?view=auto
http://www.debian.org/security/2004/dsa-416 se vztahuje ke 2 chybam, ktere byly autorem opraveny az ve verzi 2.81.b18 z 25.11.2003.
viz.
CAN-2003-1022: Unknown vulnerability in fsp before 2.81.b18 allows remote users to "escape from the FSP root directory."
http://xforce.iss.net/xforce/xfdb/14154
Dalsi info:
http://www.securityfocus.com/bid/9377/discussion/
Opraveny balicek pro debian (2.81.b3-3.1woody1) vysel 19.12.2003
viz. http://packages.debian.org/changelogs/pool/main/f/fsp/fsp_2.81.b3-3.1woody1/changelog
Pro zajimavost:
http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html
Autor FSP jsem ja, takze vim co jsem kdy a kde opravil:) Ta chyba co je zdokumentovana v b18 changelogu neni fixnuti security hole. Je to jen opraveni parsovani jmen souboru, ktere ma jako side-effect za nasledek to, ze drahy typu /../ jsou zdetekovany drive nez predtim. Krome toho ten buggy kod co byl ve starem fsp jsem vyhodil uz nekdy v lete 2003 a od te doby to tam nebylo. Ty 2 remote exploity jsem zrusil 2-jun-2003 a v te dobe jsem to poslal debianum (ovsem bez exploitu). O tom stat root escapu v b11-b13 co jsem tam mel vedel hned od zacatku, dulezitejsi bugfixy mely prednost. Takhle dira nesla exploitnout pomoci std klientu. Faktem zustava ze Debiani o tom vedeli 3/4 roku a kaslali na to dokud nedostali exploity. Takze moc vazne tu security neberou a to dostali povidani + patch. Stacilo jen patch aplikovat a vydat nove baliky.
Ja o tom vim jen to, co je mozne dopatrat na internetu:
"Buffer overflow in fsp before 2.81.b18 allows remote users to execute arbitrary code."
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0011
"Directory traversal vulnerability in fsp before 2.81.b18 allows remote users to access files outside the FSP root directory."
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1022
Blizsi popis tady (dlouhe):
http://xforce.iss.net/xforce/xfdb/14155
http://xforce.iss.net/xforce/xfdb/14154
Jestli jsou ty informace nepravdive, mozna byste mel pozadovat opravu.
V changelogu je nekolik dalsich vyskytu slovnich spojeni jako "memory leak", "buffer overflow", "security hole" a "security prob". Nemohlo toto byt pricinou zdrzeni?
Zajimave je take toto: "Version 2.8.1b5 -- 25 June 2003 ... merged security patch from Debian package fsp_2.81.b3-4, i have fixed this problem in 2.8.1b4; but Debian code looks better."
Vypada to, ze mate se security teamem i jine zkusenosti, o ktere jste se s nami nepodelil ;-)
Vydani sarge se blizi a fsp ma stale 1 RC bug. Takze hrozi nezarazeni do do stable. Chtelo by to popohnat spravce balicku.
Na zaver male upresneni: debian vydal opraveny balicek 19.12.2003, to je od leta 2003 maximalne 1/2 roku, ne 3/4 ;-)
O to se pokousel Sven (taky dela fsp) a dokonce se osobne zna s nekym z debian sec. teamu. Jak je videt, niceho nedosahl. Debian sec. team posila sice message encrypted ale nikdy jsem od nich nedostal signed. Ten zmineny patch nekodoval sec. team ale maintainer. Ja jsem ho tam kopnul misto sveho protoze byl hezky zformatovanej, kod byl ten samej. Jinak situace ohledne 'security announcu' je dost zvlastni. Nejlepsi je poslat patch autorovy at si to opravi, komercni vendori ty na to kaslou dokud se nedostane do obehu exploit. Jinak pokud poslete security announci tem velkym sajtam na netu, tak necekejte ze to taky announcnou pokud neni exploit in the wild. Za posledni rok mne neannoucnuli zadny z 6ti patchu, to ze si ukradnou credits pokud muzou, to ani nezminuju. Moje jmeno jsem v security announcich za posledni 2 roky nevidel. Ovsem pokud jim posle neco nekdo znamy (deb. sec team) tak to uz je jina, zjevne maji u nich dobry image. Posledni rok sem nasel chybu v softu od HP a ty mne vyhrozovali pravnikem, takze je videt, ze informace o bugach ve svem komercnim softu zrovna moc neocenuji. Security to je dneska predevsim velky byznys, protoze to vsichni dost zerou. K situaci fsp a rel. crit. bug: mne je to fuk, ja debos uz 3 mesice nepouzivam. Kdyz tak jim mailnete sam. Vyhoda FSP je mimojine v tom, ze se mne nepocita do download limitu, neb to jede pres UDP a ne TCP :) Jinak security problemy se nejsnadneji daji vyresit takto: http://scache.sf.net/ - soft se proste odpraskne a hotovo, clovek se nemusi matlat s nejakou patchi.
Ne, neni to obchodni politika provozovatelu.
Naopak posilam do haje clanky, u kterych si myslim, ze vyvolaji flame, pripadne nutim jejich autory, aby drsna tvrzeni zjemnili. Jinak jim ovsem nechavam svobodu, at si srovnava, pokud je to k veci (zde je) a pokud to vypada, ze tomu rozumi.
Jste fakt vsichni nejaky divny a vztahovacny, uvedomte si, ze se hadate proto, ze *chcete* - pokud byste nechteli, zadny clanek vas k tomu nedonuti, naopak touzite-li, pohadate se kdekoli. Ja si taky o balickovacich systemech nekterych distribuci myslim svoje a nektere mam radeji, ale proc bych se mela nekde hadat? Prispeju maximalne k clanku, ktery se tyka toho jedineho balickovaciho systemu, ktery dobre znam, pokud v tom clanku najdu nejakou faktickou chybu (teda presneji receno neprispeju do diskuse, ale servu autora rovnou, at to opravi, nicmene chapu, ze vsichni takovou prilezitost nemate :)). Ale jinak? Dost nerozumim lidem, kteri se musi vsude vysplechtnout, jenom aby se vysplechtli.
Ctenost mame IMHO dostatecne dobrou na to, abychom si ji nemuseli zvysovat takovymito berlickami, navic ctenost a reklamu resej uplne jiny lidi nez obsah (ktery resim ja) - a myslim, ze je to hodne dobre, ze se tyhle dve veci vubec neovlivnuji. Netusim, jakou mame ctenost a rozpocet a nikdy jsem nedostala zadny pokyn shora tykajici se toho, co zaradit a co ne, rozhoduju o tom zcela intuitivne a ctenost ovlivnuju pouze tim, ze prekecavam kvalitni autory (Mikulas Patocka, Martin Beran), aby pro nas neco psali, a naopak posilam do haje prilis zacatecnicky a prilis BFUnesni clanky.
1. 100% souhlas.
2. johanko, nebudte vztahovacna! :o)
s tou "obchodni strategii" jsem to myslel dobre a zrovna vam ctenost preju! uroven clanku stoupa, bohuzel myslim, ze klesa uroven diskusi (osobni nazor cloveka, jenz se pres uvodni test dostal na vase stranky hned napodruhe). :o)
hodne stesti. musim pracovat, takze pripadne dalsi reakce prosim na e-mail.