kFreeBSD zyskuje oficjalne uznanie w Debianie

http://www.jmcresearch.com/projects/jail/ – to przypadkiem nie jest to, co we freebsd?

Nie tak latwo wyjsc z chroota, jeszcze jak uzywa sie grsecurity ktory nie pozwala m.in. na chroot w chroocie ktory pozwalal sie z niego wydostac.

Cytat ze strony: "Jail Chroot Project is an attempt of write a tool that builds a chrooted environment.". Czyli nie, kompletnie bez zwiazku – We FreeBSD, jail to wirtualizacja na poziomie systemu, a to tutaj to jakas atrapa. Zaimplementowanie prawidlowej izolacji procesow w jailach wymaga duzych zmian w kernelu.

A co do grsecurity – wiesz, fajnie, tylko ze nadal jest to zbior hackow obchodzacych problemy, ktore we FreeBSD rozwiazano w bardziej fundamentalny sposob. Poza tym jaile we FreeBSD dzialaja bez koniecznosci patchowania czegokolwiek.

No i pomijam juz VNET – wirtualne stosy TCP/IP to fajna rzecz jest.

Tak na marginesie tematu: jest jakiś sensowny sposób, aby odpalić FreeBSD na linuksowym pececie? Bo VirtualBox nie potrafi . No opcjonalnie druga kwestia: czy FreeBSD polane debianowym sosem może być w czymkolwiek lepsze od prawdziwego FreeBSD?

@maciek: Mi FreeBSD 8.0-BETA dzialalo calkiem dobrze pod VirtualBoxem – ale tylko z jednym procesorem. Zupelnie bez problemow dziala pod VMWare Fusion – wypada sie upewnic, ze wirtualny dysk jest ustawiony jako SCSI, nie ATA (dziala wydajniej).

Eeee w życiu nie widziałem strony do której linkujesz i nieświadomie, wieki temu, zainstalowałem na vbox freebsd… cud?

Działa bardzo ładnie.

Jest linuksowy odpowiednik – vserver. Zmiany w kernelu niewielkie, działa równolegle z grsec, zapewnia izolację procesów i virtualizację zasobów.

@cokolwiek: dokładnie- jest jeszcze OpenVZ, ale vserver jest zacny i w większości distr w paczkach.

@trasz,groszek : dzięki. Pooglądam sobie. 1 CPU wystarczy do zapoznania się z systemem (na razie z ciekawości, bo do pracy potrzebuję Solarisa i Linuksa tylko, ale cholera wie, może ta wiedza się kiedy nie przyda… )

Przy okazji jeszcze wspomnianych wyżej vnetów proponuję zainteresować się głębiej pakietem iproute2, a dokładniej macvlanami i przestać opowiadać o brzydkich hackach, tylko wcześniej poszukać odpowiedników funkcjonalności

@cokolwiek: Gdzie widzisz zwiazek miedzy funkcjonalnoscia Linuksowego macvlan i VNET we FreeBSD?

Jeszcze raz: VNET robi ci wirtualne stosy tcp/ip. Oznacza to, ze jail, w ktorym masz vnet, ma wlasne interfejsy (inne niz te dostepne na zewnatrz jaila), wlasny routing, firewalling i co tam jeszcze zechcesz. Root wewnatrz jaila moze je sobie dowolnie konfigurowac, ale nie moze zrobic niczego, co zmieniloby stan interfejsow lub ogolnie konfiguracji poza jailem.

System jak system… ino nie za bardzo widzę przewagę Nexenty nad OpenSolarisem Nevada. Dla przypomnienia: Nevada to "oficjalny" opensolaris robiony przez Iana Murdocka (tego od Debiana), system operacyjny Solaris podany w strawnej dla "linuksiarzy" postaci

@Precz: Kernel FreeBSD skaluje sie niezle – zwlaszcza stos TCP/IP, gdzie roznica w wydajnosci serwera DNS na szesnastu rdzeniach pod FreeBSD i pod Linuksem potrafi byc kilkukrotna na korzysc FreeBSD – natomiast GCC faktycznie, jest stare. Nowsze wersje sa na GPLv3 i z tego powodu FreeBSD (podobnie jak Apple) utknelo na gcc 4.2.1; dlatego taki wazny jest rozwoj LLVM.

Oczywiscie jak ktos chce, to moze sobie doinstalowac inne GCC z portow (jest wersji do wyboru, do koloru, wlacznie ze snapshotami wersji rozwojowych z repo) i przekompilowac caly system.

Skąd wziąłeś te rewelacje?

używałeś kiedykolwiek freeBSD ??

A co? Kłamię? Przedstaw argumenty. I jeszcze dorzucę o FS:

UFS jest już przestarzały i odstaje w porównaniu z konkurencją. Dlatego developerzy FBSD rzucili się na ZFS – jedyna dostępna nowoczesna alternatywa. Tylko czy ktoś spojrzał JAKIE to ma wymagania sprzętowe?

Tak! Nie jestem ani użytkownikiem(tak próbowałem!), ani tym bardziej developerem FreeBSD – szkoda mi czasu na bzdety; swoje rewelacje czerpię głównie z news://pl.comp.os.advocacy gdzie to trasz (w miarę)regularnie sieje FUD i dostaje po pupie (i wyładowuje swoje frustracje na takich forach jak to, gdzie miesza w głowach naiwnym maluczkim) od prawdziwych specjalistów w swojej dziedzinie. Znalazcą ostatnio sławnych exploitowalnych bugów jest polak (bynajmniej nie trasz – specjalista od spraw szelkich a w szczególności niezawodny programista systemowy) ale FriBźdzarze nie mają w zwyczaju odpowiadać na bugraporty.

@precz – "UFS jest już przestarzały i odstaje w porównaniu z konkurencją. Dlatego developerzy FBSD rzucili się na ZFS – jedyna dostępna nowoczesna alternatywa. Tylko czy ktoś spojrzał JAKIE to ma wymagania sprzętowe?"

Tutaj się zgodzę (UFS), Co do wymagań ZFS – faktycznie wysokie ale przy dzisiejszych serwerach nie jest to istotna bariera.

Developerem nie jestem i daleki jestem od fanatyzmu, jednak, z obserwacji własnych, freeBSD bije wydajnością linuksy (tutaj zgodzę się częściowo z traszem – różnica na wielu rdzeniach potrafi być miażdżąca)

Oj, mój kochany! Akurat trash się IMHO trochę ustatkował. Natomiast ty ewudentnie wyładowujesz swoje frustracje. W większości podajesz ogólniki. Zachowujesz się strasznie agresywnie. Co Ci zrobił FreeBSD, że tak na niego najeżdżasz? system jak system, ma zady i walety. Ma też sporo fajnych rozwiązań. Linux zawdzięcza mu implementację pamięci wirtualnej (ok wersji 2.4, nie wiem, ile z tego kodu jest tam teraz ). A że na licencji BSD? Zawżdy otwarta. Są ludzie, którzy uważają ją za lepszą. Mają prawo. Co zaś do developerów… linuksowi też potrafią nie odpowiadać na bugreporty, łatać z opuźnieniem, odwalać prowizorkę… a nawet się kłócić Tak na prawdę nikt nie wie, który system nam kiedyś "życie" uratuje (może być to Win, los lubi być zgryźliwy), więc lepiej traktować to wszystko z większym dystansem

@Precz: Pozwole sobie zauwazyc, ze funkcjonalnie UFS jest gdzies pomiedzy ext3 (ma ficzery, ktorych ext3 nadal nie ma, w rodzaju snapshotow czy duzych blokow, a'la extenty) i ext4. Wiec opowiesci o przestarzalosci sa jedynie dowodem niedouczenia opowiadajacego; chyba ze mowi w kontekscie porownania z czyms naprawde nowoczesnym, w rodzaju ZFS.

A co do ZFS – wymagania sprzetowe ma takie, ze kazdy pecet dostepny na rynku spokojnie nie spelnia, i to od dobrych kilku lat (kiedy standardem stalo sie 512MB RAM?).

A co do ostatnich bugow – bug dotyczacy aktualnej wersji FreeBSD byl dokladnie jeden. A odpowiedz na bugraport owszem, trwala dlugo, bo i sam blad, i poprawka byly dosyc… nietypowe. Przy czym nie zmienia to faktu, ze wykorzystanie dziury nie bylo mozliwe przed ukazaniem sie oficjalnej poprawki, bo nie byly znane szczegoly, w szczegolnosci nie bylo wiadomo, gdzie jest. Podobnych dziur w Linuksie bylo kilka, i za kazdym razem eksploit krazyl po sieci przez pewien czas przed pojawieniem sie oficjalnych poprawek.

można jeszcze potrolować odnośnie FS

Developerzy linuksa w przeciwieństwie do BSD mają na tyle inwencji twórczej, że są w stanie opracować własny FS.

Po co iść na łatwiznę i gotowe rozwiązania portować?

@trasz: czemu ciągle powtarzasz o tych krążących eksploitach przed poprawkami w Linuksie, skoro na usnecie udowodnili ci że kłamiesz.

Choć nie- poprawiłeś się- już nie ma tekstu 'miesiącami' a sformułowanie 'pewien czas'. Wychodzi na to, że cię jednak specjaliści spacyfikowali.

Od siebie dodam- jak dla mnie fakt, iż nie pokazał się eksploit do TEJ dziurki w FreeBSD to tylko fart, nie zasada i może wreszcie być to przyjął do wiadomości.

PS.

Tak ciężko przyznać, że objęcie opieką jądra FreeBSD odbije się na jego jakości dzięki wsparciu developerów LINUKSA? Z tego faktu cieszą się np. ja, z lekkiego sentymentu dla wolnej bestyjki.

@bobycob: Bo gotowe rozwiazanie (ZFS) jest i dziala, a developerzy Linuksa nadal nie potrafia doprowadzic do dzialania Btrfs, mimo bardzo okrojonej, w stosunku do ZFS, funkcjonalnosci?

@Tomasz Woźniak: Dlatego, ze eksploity krazace przed wydaniem poprawek w Linuksie to fakt, niezaleznie od tego, co napisza usenetowe trolle. Pozwol, ze pokaze ci konkretny przyklad: eksploit krazacy od 13. sierpnia (http://www.securityfocus.com/archive/1/archive/1/505751/100/0/threaded), poprawka RH dla czesci systemow to 24 sierpnia (https://rhn.redhat.com/errata/RHSA-2009-1457.html), dla reszty – 22 wrzesnia (https://rhn.redhat.com/errata/RHSA-2009-1457.html). I tak jest zwykle – najpierw eksploit, co najmniej pare dni pozniej poprawka, niezaleznie od tego, co na pcoa opowiada pewien administrator systemow biurowych. ;->

A co do twojej tezy o 'tylko _tej_ dziurce' – caly myk polega na tym, ze we FreeBSD praktycznie zawsze poprawka jest przed eksploitem, a w Linuksie praktycznie zawsze eksploit jest przed poprawka. Poszukaj, sam zauwazysz.

A co do opieki – o jakiej opiece mowisz wlasciwie?

Z tym działanie jest różnie – świadczy o tym zgłoszony przez Ciebie błąd. "Zapomniałeś" wspomnieć o ext4:P.

Odnośnie BTRFS – mogłeś wprost napisać – a, u was biją murzynów – bo to argument na tym samym poziomie. Dobrze wiesz, że BtrFS dopiero powstaje nie jest to cudo wyjęte z Teczki Tymińskiego jak ZFS w BSD gdzie brudną robotę ktoś już zrobił.

Jeszcze wypda dodać, że dzięki temu iż projekt tworzony z myślą o linksie nie muszą się oglądać na "wzorcową implementację" (czy jak to nazwać). W przypadku Fribździ po ogłoszeniu ukończenia prac nad ZFS taki kwiatuszek wyrósł:

kern/139072: [zfs] zfs marked as production ready but it used a deprecated checksum algorithm

@trasz – kłamiesz!

Nie mam nic przeciwko xBSD ale kłamcy i zeloci niesamowicie mnie wku****ą

i dlatego tak wojuję z traszem

Co to jest święta wojna?

każdy na swój sposób mówi prawdę – choć czasem może się okazać prawdą trzeciego rodzaju.

No tak trasz znowu manipuluje przedstawiając RHEL jako Linuksa… Podasz kotku kiedy był commit w drzewie Linusa czy będziesz tu też pieprzył od rzeczy? Aż dziw, że ktoś Cię jeszcze traktuje poważnie…(*)

(*) Opowiadając sobie: tak, wiem, że liczysz na ludzi którzy nie czytają pcoa/lwn. Bo jeśli ktoś czyta któreś z tych źródeł to traktować Cię poważnie nie może.

Z resztą nie musisz, w cytując wskazane przez Ciebie securityfocus: ,,Linus committed a patch correcting this issue on 13th August 2009.''.

Pieprzysz od rzeczy tak, że szkoda Cię czytać. Ani grama powagi…

@bobycob: ext4 to ewolucyjny rozwoj ext3. Nadal nijak sie ma do funkcjonalnosci ZFS-a – ot, przypudrowany ext3, usuwajacy chyba ostatnia zaszlosc w stosunku do UFS-a we FreeBSD, czyli koniecznosc uzywania malych blokow i zwiazany z tym spadek wydajnosci.

A co do Btrfs – wiesz, uzytkownika nie obchodzi, ze to jest dopiero tworzone i ze developerzy bardzo sie staraja. Wazne, ze ZFS dziala, a Btrfs nie. A wyciaganie (poprawionego) bledu w implementacji funkcjonalnosci, ktorej w Linuksie w ogole nie ma (usuwanie uzywanych snapshotow) tudziez problemu czysto potencjalnego (fletcher) i tez w funkcjonalnosci nie istniejacej w uzywalnych produkcyjnie filesystemach w Linuksie, to raczej slaby argument.

@bies: W swiecie doroslych ludzi liczy sie moment wypuszczenia _oficjalnej_ latki. Eksperyment myslowy – wez produkcyjny serwer Oracle'a na RHEL, przekompiluj sobie kernel z jakimis łatkami, a potem sprobuj przekonac RH i Oracle, zeby ci to supportowali.

@trsh

To Oracle suportuje jakieś BSD?

Ak47: Tia, BSD, jasne…

Trasz: oficjalne łatki do Linuksa są na kernel.org. RHEL, to RHEL. A może powiesz mi, że instalacja na SLES-ie to nie Linux, albo Debianie to nie Linux?

Ile zajęła ta poprawka w kqueue, miesiąc? To co, boli Cię, że programiści Linuksa są ponad 30 razy szybsi niż fribzdi?

A co do supportu: czy będą czy nie będą to zależy od zapisów kontraktu — specjalisto od ,,świata dorosłych ludzi''…

@bies: Ile czasu uplynelo miedzy ujawnieniem szczegolow dziury we kqueue a oficjalna poprawka? Podpowiem – zero sekund, gdyz szczegoly zostaly ujawnione razem z poprawiajacym problem patchem. Ile czasu uplynelo miedzy cichym zalataniem dziury w kernelu przez Linusa, a wymuszonym przez pojawienie sie eksploita przyznaniem sie uzytkownikom, ze byla dziura i wypchnieciem oficjalnych latek przez dystrybucje? Podpowiem – o kilka dni dluzej.

A co do supportu – no, dalej, opowiadaj, jaki udalo ci sie wynegocjowac kontrakt z Oracle na support niesupportowanego systemu. ;->

Bla bla bla… Programiści fribzdi dostali pełny opis błędu. Linuksa też (razem z resztą świata, ale to nieistotne). Programiści Linuksa (Linus) poprawili błąd tego samego dnia. Programiści fribzdi o wiele później. Zatem programiści frinbzdi są od programistów Linuksa wolniejsi. ile dokładnie, nie wiem (nie śledzę fribzdi z wypiekami na twarzy; co ja mówię — w ogóle nie śledzę).

Nie negocjuję z Oracle a o umowach moich klientów nie mam prawa mówić. Natomiast osobiście udzielam wsparcia gdzie czas reakcji na błąd w moich rozwiązaniach to np. 4 godziny.

@bies: Z punktu widzenia uzytkownika nie ma znaczenia to, na ile programisci sa szybcy. Ma natomiast znaczenie fakt, iz we FreeBSD oficjalna poprawka pojawila sie natychmiast w momencie ujawnienia szczegolow pozwalajacych na wykorzystanie dziury, a w Linuksie pozniej.

A co do wsparcia – wiesz, fajnie, ze udzielasz. Do FreeBSD tez pare osob udziela. Ale rozmawiamy o duzych firmach udzielajacych wsparcia w krytycznych systemach, gdzie nikt nie nałoży "łatki od Linusa" – latka oficjalna jest od producenta dystrybucji, zwykle RH.

@trsh

Weź pod uwagę że dystrybucja X jeśli ma umowę supportowania Oracle nie wypuści poprawki puki nie przetestuje tego Oracle.. Czas się wtedy wydłuża.

Trasz: przepraszam, odbiło mi i znowu z Tobą dyskutuję. Przepraszam, już nie zawracam głowy. Ave fribzdi.

@tsh – nowy shell? -tak odnośnie wytykania braku ZFS przypomniał mi się dowcip polityczny z okresu stalinowskiego.

Na granicy rozmawiają dzieci polskie i rosyjskie:

- A my mamy chleb! – wołają dzieci rosyjskie.

- A my mamy chleb z masłem!! – rzekły na to dzieci polskie.

- A my mamy Stalina!!! – rzuciły dzieci rosyjskie.

- My też możemy mieć Stalina!!! – odrzuciły gryps dzieci polskie.

- To nie bedziecie mieli chleba z masłem!!! – odrzekły dzieci rosyjskie.

Naprawdę przepychanki typu my mamy zfs (bsd) – a my mamy sterowniki (linuks) są bez sensu.

Nie można mieć wszystkiego na raz. Mało tego, gdy btrfs w końcu ujży światło dzienne jestem gotów się założyć, że zaraz zacznie się wytykanie – błe w BSD ZFS jest od 100 lat, błe miało być lepsze a nie ma opcji "X". I wogóle z zasady gorsze bo dla Linux a nie BSD.:P

Lepiej napisz pełną informację jak działało, a nie, że działało.

To tak jakbym napisał, że DOS do dziś jest w użyciu, a nie dopisał, że przykładowo oprogramowanie dla sklepów jest wystarczająco dobre w wersji dla DOS.

Poza tym Windows dzialalo na tych Alphach ladnych pare lat przed Linuksem.

chronologię warto tu oczywiście sprawdzić, ale jest to możliwe, w końcu linux zaczął się w 1991r. Natomiast co do działania winNT na procesorach alfa, to zdania są podzielone. Ja od znajomego, który próbował użyć tego OS słyszałem, że nie działa i jak zwracał go potem sprzedawcy, to nikt go nawet nie pytał dlaczego. M$ faktycznie jakiś czas taką wersję produkował, ale ona chyba niezbyt działała, dlatego w końcu sobie ją odpuścił.

@JG: Windows NT dzialalo calkiem dobrze; zreszta bylo oficjalnie supportowane. Problem byl z tym, ze praktycznie nie bylo aplikacji skompilowanych na AXP, a aplikacje intelowe dzialajace w trybie emulacji chodzily wolniej niz na normalnym pececie.

@bies: Jedna z fajnych rzeczy zwiazanych z LLVM jest to, ze jest duzo lepiej zaprojektowany. Juz teraz kod generowany przez LLVM potrafi byc wydajniejszy niz ten generowany przez GCC w dowolnej wersji, mimo ze sam kompilator jest prostszy wewnetrznie. Jesli dorzucimy do tego przyjaznosc dla programisty (lepsze warningi i ogolnie statyczna analiza kodu), przyjaznosc dla osob chcacych go wspoltworzyc (zadnych lojalek, ktore trzeba podpisywac w przypadku projektow GNU), przyjaznosc dla uzytkownikow koncowych (licencja) oraz wsparcie dla rzeczy w rodzaju Grand Central Dispatch, ktore maja szanse mocno namieszac, jesli chodzi o sposob pisania aplikacji efektywnie wykorzystujacych sprzet, wybor jest prosty. Z tym, ze najpierw trzeba nadrobic "tyly", ktore LLVM nadal ma w stosunku do GCC – czyli glownie dopracowac wsparcie dla C++. Na podstawie obserwacji dotychczasowego rozwoju – ktory jest bardzo dynamiczny, m.in. ze wzgledu na silne wsparcie ze strony Apple – wydaje mi sie, ze zajmie to mniej wiecej rok.

A co do "uparcia sie" – nie chodzi o to, ze Apple sie uparlo. Nie chodzi o to, ze GCC ma dwadziescia lat i wewnetrznie to sterta hackow, podobnie jak cale GNU binutils. Nie chodzi o brak checi developerow GCC do wspolpracy, o lojalki, bez ktorych nie przyjma ani linijki kodu, ani o licencje napisana specjalnie po to, zeby utrudnic zycie tworcom IDE wykorzystujacych GCC, czyli, konkretnie, firmie Apple. Chodzi o to, ze w opinii czesci prawnikow z kilku roznych firm GPLv3 to licencyjne i patentowe pole minowe, i ze pare procent roznicy w jakims amatorskim benchmarku nie jest warte ryzyka dla firmy. A poniewaz w BSD chodzi o to, aby nie utrudniac uzytkownikom zycia durna pseudofilozofia i NIH-em, to decyzje biora pod uwage opinie uzytkownikow – takich jak te firmy.

No to że Apple zrobiło sobie z fribzdi prywatną piaskownicę to już pisałem.

LLVM generujący wydajniejszy kod, gdzie?

O C++ to raczej wiesz o wiele za mało aby w ogóle podnosić ten temat, nie łudź się — może za 3 lata pomijając C++0x i OpenMP.

Libdispatch, łomatko toż nowość. TBB ma już 3 lata. Wiesz co to jest TBB w ogóle? Napisałeś kawałek kodu używający tego. Widziałeś źródła? Zrozumiałeś je? Jeśli na któreś z tych pytań odpowiedziałeś nie — marnujesz mój czas.

A teraz odnieś się do: CK, CFS, tickless i IBM — czyli tematów których próbujesz uniknąć przez zagadanie. I napisz gdzie (z dokładnością do pliku źródłowego) są hacki w gcc i binutils.

Albo napisz po prostu, że się nie znasz i marnujesz mój czas.

@bies: TBB sluzy do czegos zupelnie innego niz GCD. Ogolnie – poczytaj troche na ten temat. Na pozostale (o sytuacjach, gdy kod generowany przez LLVM jest efektywniejszy niz GCC albo o postepach nad clangiem) zreszta tez by ci sie przydalo. ;->

Co mam poczytać? Źródła libdispatch czy TBB? Zonk, oba już czytałem. Oba służą do tego samego (z grubsza, TBB potrafi znacznie więcej): rozrzucenie kawałków kodu (to paskudztwo bloki, funkcje, funktory, lambdy) po dostępnych procesorach/wątkach. W TBB funkcjonalność libdispatch uzyskasz korzystając bezpośrednio z Task Schedulera a nie z abstrakcji wyższego poziomu (algorytmy i kontenery).

Mam poczytać — dawaj linki cwaniaczku. I odpowiadaj na poprzednio zadane pytania specjalisto od wklepywania hasełek w google.