Forum Debian Users Gang

Jacekalex napisał(-a):

Minuta ciszy była dlatego, że przeczytałem o niebezpieczeństwie i "niepotrzebności" montowania linuxproc.

Z niepotrzebnoscia sie zgodze, ja w sumie nie mam tego zamontowanego, htop nie uzywam. Co do niebezpieczenstwa, nie wydaje mi sie aby bylo to niebezpieczne, po prostu inny sposob komunikacji, w tym przypadku, wirtualny system plikow, jak ma byc dziura to moze byc w tym jak i w czyms zupelnie innym.

Ja osobiście ani przeciwko *BSD ani LINUX_COMPAT nic nie mam.

Ja troche mam, mogliby w koncu zaimplementowac takze dla binarek 64bit z Linuxa, ale jakiestam kroki juz byly w tym kierunku, wiec moze niedlugo bedzie dostepne produkcyjnie.

Hal? a co to takiego? już zapomniałem, że kiedyś było ;)
Systemd - nie używam, i raczej nie zacznę, choć muszę przyznać, ze w Debianie jakośtam działa, nawet prawidłowo.
Integracja systemd z udevem spowodowała rozpoczęcie prac nad projektem eudev, które rozpoczęli developerzy Gentoo.
Istnieją istotne przesłanki do tego, abym bliżej zaprzyjaźnił się z tym projektem.

Mnie fascynuje fakt, ze srodowisko Linuxa toleruje takie zachowania jak Lennart'a czy Key'a, pisza sobie jakies rozwiazania w Red Hat, ok, ich prywatna sprawa i sprawa Red Hata, ale dlaczego caly swiat Linuxa na sile probuje te rzeczy akceptowac i wdrazac do reszty ekosystemu, tego nie jestem w stanie pojac.

ZFS się w Linuxie bardzo przyda, choć to jeszcze daleka droga, żeby się pojawił.

Nie wiesz moze czy mozliwy jest juz ZFS only Linux? Wiem, ze GRUB2 (conajmniej 1.99) potrafi bootowac FreeBSD z ZFS'a, pytanie jak to z Linux'em wyglada.

Do tego np kvm jest w każdym dystrybucyjnym jaju i chodzi nawet pod jajem z Grsec i Paxem, czego o Xenie  nie mogę powiedzieć, a i z Virtualboxem różnie bywa w takich warunkach.

Dla FreeBSD pisza wlasnie BHyVe, ale na razie jest to w fazie alhpa/beta:
http://wiki.freebsd.org/BHyVe

Pozdrawiam,
ver

Wszyscy kochaja ten 128 bitowy FS  :D

... ze ZFS na Linux jest to wiem (natywnie i przez FUSE), pytam czy mozna miec TYLKO ZFS i bootowac sie na to z  GRUB, bez znadnych dodatkowych protez pokroju osobne /boot itd.

Teoretycznie można, większego sensu bym w tym nie szukał.

Powody?

ZFS jest na innej licencji, niezgodnej z GPL. Dlatego nie trafił do kernela, jest dostępny jako moduł zewnętrzny, można go sobie skompilować z flagą rootfs.
Wtedy trzeba ten moduł dodać do initrd, jak go ktoś używa.

eix zfs-kmod
* sys-fs/zfs-kmod
     Available versions:  (~)0.6.0_rc10^t (~)0.6.0_rc11^t (~)0.6.0_rc11-r1^t (~)0.6.0_rc12^t **9999^t {custom-cflags debug +rootfs KERNEL="linux"}

Osobiście wolę mieć sterownik do systemu na rootfs wbudowany w jajo na sztywno i nie używam initrd.
Przy obecnych możliwościach ext4, na rootfs żadnej korzyści z posiadania zamiast niego ZFS nie zobaczę też dlatego, ze ext4 jest w większości testów szybszy, ma extundelete, e4-defraq, i komplet narzędzi do naprawy i wyłażenia z różnych problemów, a sam system ext4 już żadnych strasznych problemów nie powoduje..
Jeżeli jestem zwolennikiem ZFS dla Linuxa, to nie z powodu rootfs, ale ze względu na bazy danych, Mysql, Postgres i Sqlite niezbyt kochają ext4, dobrze chodzą na ext3 lub reiserfs, ale spodziewam się, że jeszcze lepiej pójdą na ZFS.
Stąd też moje zainteresowanie ZFS, a także UFS.
W Linuxie co prawda powstaje Btrfs, który ma być absolutnie cudowny i wspaniały, i idealnie ma nadawać się pod bazy SQL, głównym sponsorem jest Oracle, ale jeszcze sporo wody w Wiśle upłynie, zanim to będzie stabilne rozwiązanie, bo na razie jest tylko "unstable,  experimental, for non critical data".


Niezły ubaw miałem z TMPFSem we FreeBSD:
w /var/log/messages:

Dec  4 19:43:28 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.
Dec  4 20:14:20 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.
Dec  4 21:27:16 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.
Dec  5 00:06:11 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.
Dec  5 19:45:25 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.

Biorąc pod uwagę, że na Linuxie używałem najpierw RAMFS, potem TMPFS już w 2008 roku, po prostu poczułem się młodszy o kilka lat :D

? Wiem, ze GRUB2 (conajmniej 1.99)

Osobiście uważam Gruba-2 za najgorszy bootloader, jaki kiedykolwiek powstał na Linuxa.
Na razie używam jedynki, jakbym miał się wprowadzić na bios z UEFI, to albo łatki na gruba-1 albo elilo czy  extlinux.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2013-12-14 08:05:16)

http://www.rodsbooks.com/efi-bootloaders/grub_legacy.html
:)

azhag napisał(-a):

Jacekalex napisał(-a):

ZFS jest na innej licencji niezgodnej z GPL.

Problemy licencyjne są już podobno przeszłością.

W rzeczy samej: podobno. ;)

Ostatnio edytowany przez Jacekalex (2012-12-05 21:14:36)

Grub 1 - to lekki mały bootloader z dość prostym kodem.
Znam wersje na EFI, do TPM (trusted-grub), i osobno do modułu Linux-IMA.
Jedyny problem, to ożenić kilka łatek na raz, ale to jest znacznie prostsze, niż podobne akcje w Grub2.
Jeśli jedynka chodziła w Solarisie, to znaczy, ze można z niego wytargać, (ze źródeł) łatkę dla ZFS.
Gdzieś już widziałem łatkę na Btrfs.
W każdym razie wykonalne, jakby ZFS pojawił się w źródłach kernela, to już bym jej na bugzilli Gentoo szukał. :D

Nie wiem, jak w paczkowatych dystrybucjach typu *bunta, ale np w Gentoo jeszcze  trochę przetrwa,  Fedora też  czepiła się tej wersji jak rzep psiego ogona.

Jeżeli jedynka ma jakąkolwiek konkurencję, to bardziej extlinux czy elilo, aniżeli grub2.

Mnie fascynuje fakt, ze srodowisko Linuxa toleruje takie zachowania jak Lennart'a czy Key'a, pisza sobie jakies rozwiazania w Red Hat, ok, ich prywatna sprawa i sprawa Red Hata, ale dlaczego caly swiat Linuxa na sile probuje te rzeczy akceptowac i wdrazac do reszty ekosystemu, tego nie jestem w stanie pojac.

Proponuję odróżnić Cannonical, Novell'a i RedHat od ekosystemu.
Debian ani tak szybko ani tak radośnie nie łyka każdej pierdoły, choć są dostępne w repo, a integracja udeva i systemd tak kogoś wkurzyła, że Linux-3.7 ma  sam ładować firmware;y, bez udziału udeva.
Także niekoniecznie cały ekosystem wszystkie wypociny Lennarta łyka jak bocian żaby, to raczej taka czy inna firma stojąca za jedną czy drugą dystrybucja podejmuje takie czy inne decyzje, jedyny naprawdę patologiczny wyjątek od tej zasady, to silne uzależnienie nowego Gnome3 od Pulseaudio.

W każdym razie ani w Debianie, ani w Gentoo czy w Slackware nikt nikogo nie zmusza do używania Network-managera czy  Pulse, o ile to możliwe, nie ma też przymusu do systemd.
Nawet próba integracji systemd z udevem spotkała się z dosć ostrymi reakcjami, począwszy od kernela a skończywszy na forku udeva -  eudev.

Po prostu ekosystem Linuxa jest trochę za duży i zbyt rozległy, żeby mógł go trzymać za jaja jeden organ decyzyjny.
W każdym razie wolność wyboru pozostaje nietknięta, co najwyżej będzie trochę zabawy z konfiguracją. :D

Dla mnie wogole sama idea, zeby tworzyc taki twor jak initrd jest poroniona, nie dziwie sie, ze trzymasz sie od tego z daleka.

Ja mogę nie używać initrd, bo kompiluję jajo na swój komputer.
Zapewniam, ze gdybyś musiał przygotować jajo do nowego wydania Debiana, wiedząc, ze Ludzie będą to instalować na najróżniejszym sprzęcie, to maiłbyś bardzo prosty wybór:
wbudować wszystkie sterowniki chipsetów i kontrolery dysków w jajo, czy zostawić je w initrd?
Bo bez zamontowania roofs jajo nic nie wyciągnie z /lib/modules, a nawet pomijając potencjalne konflikty między kilkoma sterownikami, sama wielkość jajka, które ma wbudowane jakieś 50 czy 200 dodatkowych sterowników do wszystkiego, co produkowano po 1990 roku , wyglądała by niezwykle ciekawie.
Także w dystrybucyjnych kernelach, które mają chodzić na milionach komputerów, initrd jest po prostu lepszym rozwiązaniem, niż 10 czy 50  megabajtowy vmlinuz.
Sam system plików na rootfs, to drobiazg (raptem kilka modułów do ext4  (z obsługą 2 i 3), xfs, reiserfs i może jfs), przy długiej liście sterów do chipsetów i kontrolerów dysku.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2014-01-05 02:44:37)

Ja natomiast kompilowałem w moim życiu XX jajek na Linuxie, ostatnio kompilowałem jajo na FreeBsd, i zauważyłem, że w porównaniu z Linuxowym, jajo FBSD ma może 1/20 konfigu i sterowników.
Może, jak cały konfig ma ze 100 opcji, to można edytować w nano czy vimie, ale  konfig linuxa, to troszkę inna bajka.
Oczywiście zdaję sobie sprawę, ze w BSD jest np jeden ster do wszystkich Realteków, inny wspólny dla wszystkich kart Intela, ale listy sprzętu obsługiwanego przez FreeBSD nie porównywałbym z Linuxem, bo nie da się tego zrobić, pomijając np większość chipsetów do tunerów TV, jakie są na rynku, czy kamerek USB, czy pilotów.
Ciekaw jestem, czy FreeBSD kiedykolwiek będzie obsługiwało taką gamę sprzętu, i czy, jeśli dorobi się takiej bazy sterowników, dalej będzie malutki konfig kernela do edycji w normalnym edytorze.
Initrd jakoś w niczym nie przeszkadza, system tylko wstaje dłużej o sekundę czy dwie, ale chodzi, czego Debian jest najlepszym przykładem.

I jakiejś wielkiej różnicy nie widzę między Linuxem, a systemem, który nie ma modułu tmpfs, chyba że mu do loader.conf wpiszę TMPFS_enable="yes", to wtedy wstaje z tym modułem.
Inaczej się nazywają poszczególne foldery z modułami, ale zasada działania jest taka sama.

I wbrew pozorom, nie ma tu szansy na określenie, że jeden system robi coś lepiej, a drugi gorzej.
W obu to działa, i większych problemów z tym nie ma.
I Linux wcale nie próbuje tutaj "grzebać paluchem prawej nogi w lewym uchu", lokalizacja sterowników i firmware'ów jest w nim w miarę logiczna.

Pozdrawiam
;-)

Jak się aktualizuje FreeBSd z użyciem wyłącznie binarek?


Próbowałem portupdate -PRa i podobnie -Pa -PR ,a ten dziad się uparł, żeby wszystko co się da, kompilować, i zaczyna np mysql-serwer na dzień dobry.

Do środowiska testowego nie potrzebuję kompilować sobie życia, a na VMach kompilacja średnio wychodzi.
Poza tym,jak ktoś kiedyś słusznie zauważył, po co, jak paczka binarna i kompilowana są dokładnie takie same.

Jak się każe systemowi , "aktualizuj z paczusi co się da, albo fora ze dwora".
Bo np w Gentusiu jest opcja "emerge -Gua world" i on wtedy wie, że wolno tylko binarki z $PKGDIR i binhosta instalować.
Jest to o tyle wygodne, ze można na jednym kompie zrobić fabrykę, kompilujemy, robimy defaultowe  konfigi i testujemy, potem np

quickpkg --include-config=y `qlist -IC`

i quickpkg buduje strukturę katalogów i paczusie zgodne ze strukturą binhosta, potem opublikować przez www i gotowe, jak np tutaj.

Pozdrawiam
;-)

Dzięki, obaczym wieczorkiem.

Swoją drogą, jak na system typowo na serwery, to coś dużo tych eksperymentalnych rozwiązań, np TMPFS, czy czasów przyszłych wobec tak banalnych rzeczy, jakie w Linuxie są od XX lat.

wejdzie pkgng i składnia będzie wyglądać tak jak w aptitude

Muszę przyznać, że mnie serdecznie rozbawiłeś tą zapowiedzią :D

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-12 03:34:40)

Ja nie mam pretensji do pkgng, ale jak napisałeś w czasie przyszłym, to ja odruchowo sprawdziłem, którego dzisiaj mamy.
Sprawdziłem dlatego, że FreeBSD jest o wiele starszy od Gentoo, jest chyba nawet rówieśnikiem Debiana.
I takie częściowe wsparcie dla systemu binarek, w systemie, który ma 3 lata. może nie dziwić, ale w starszym trochę tak.
A FreeBSD powstało pod koniec 1993 roku,za rok będzie miało dwudziestkę. Jak na pełnoletni system, już ten komunikat o eksperymentalnym TMPFSie, który ciągle lata w logach, zakrawa na jakąś tragikomedię, biorąc pod uwagę, ze na niektórych serwerach cały /usr/bin /usr/lib pakuje się do ramu, żeby przyspieszyć ładowanie programów (bynajmniej nie od wczoraj).

I może fajnie, ze niedawno wprowadzono w kompilatorze flagę fstack-protector-all w gcc, ale porównując to z kompilatorem hardened z Gentusia, czy choćby kompilatorami z Ubuntu od wersji 8.10, troszkę blado to wygląda.
Co jest o tyle dziwne, ze niezbyt odległy projekt OpenBSD od zawsze bazuje na najnowszych rozwiązaniach w zakresie bezpieczeństwa, i to od kompilatora począwszy.

Pozdrawiam
;-)

... a co do OpenBSD, to juz nie od dzis z nich zartuja, ze to OS by developers for developers.

Żartować owszem, wolno, trochę się przyzwyczaiłem, Gen2 to też nie system tylko styl życia ;)

Tylko potem pocieszny dla mnie jest ten płacz na forum grsec, jak ktoś chciał odpalić PAXa na doskonałym, serwerowym CentOS, czy stabilnym Debianie, albo jak po zhakowaniu rootnode, widzę dyskusję fachowców, i hasło w stylu ' dałoby się zablokować takie ataki, ale trzeba by wszystkie birnarki z suid kompilować z PIE - ale kto to będzie robił....:D
Tam wjazd się udał z powodu podatności sudo na exploita.
A ja bym się zapytał, kto i po co w systemie ACL daje każdej duszyczce nieograniczony dostęp binarek do SUID?

Mam po prostu wrażenie, że 75% administratorów dlatego tak kocha stabilnego Debiana i CentOS, że jest znacznie łatwiejszy niż Ubuntu, i można go postawić w 20 minut.
Na tej samej zasadzie funkcjonuje w jakiejś części formie FreeBSD.
Czyli kolejny niezwykle zaawansowanym system, który w rzeczywistości obsługuje się praktycznie jak Debiana.

Przykład, porównanie 2 Firefoxów, pierwszy -binarka z mozilli, drugi kompilowany w domu:

checksec --proc firefox
* System-wide ASLR: PaX ASLR enabled

* Does the CPU support NX: Yes

         COMMAND    PID RELRO             STACK CANARY           NX/PaX        PIE
         firefox  11426 No RELRO          No canary found        PaX mprot off No PIE                  
         firefox  30327 Full RELRO        Canary found           PaX mprot off PIE enabled

Wyjaśnienie różnicy pie/nopie masz tutaj:
http://www.gentoo.org/proj/pl/hardened/pax-quickstart.xml
http://wiki.debian.org/Hardening
Flag PIE i bind-now na razie nie używają w Debianie, bo "mogą powodować problemy".
Co ciekawe, ostro poszło w tym kierunku Ubuntu, co akurat stanowi jego zaletę.

Co się uczepiłem TmpFS?
Po prostu nie uważam, żeby do korzystania z /var/run, /var/tmp czy /tmp miało generować jakiekolwiek obciążenie dysku operacjami we/wy, kiedy RAM leży odłogiem.
Ramu do grobu nie zabiorę, jest albo wykorzystany albo zmarnowany, a i szybkość działania ramdysku jest nieporównywalna z żadnym hdd.
A uczepiłem się dlatego, że dla mnie to już jest "normalność", ram dużo nie kosztuje, zazwyczaj jest w nim miejsce, wiec się to miejsce  po prostu używa.
Tylko tyle i aż tyle.

Kompilacja na KVM? w sensie praktycznym psu na budę mi to w domu, w dodatku FreeBSD chodzi na obrazie img umieszczonym na partycji ext4.
Gdybym od razu wrzucił go na partycję, byłoby prościej, obraz img nie jest najwydajniejszym rozwiązaniem dyskowym.
Parę paczek skompilowałem, jajo skompilowałem, nic trudnego, ale żeby się to przełożyło na jakąś super korzyść na poziomie paczek, nie zauważyłem, w jaju udało się włączyć ALTQ, którego nie było domyślnie.

W dodatku chce lepiej poznać to, co wyróżnia FreeBSD od Gentusia, do zabawy z kompilacją, razem z suportem do paczek binarnych i  localpatches  dla źródeł, jest portage.
Sposób kompilacji jest w FreeBSD banalny, kompilator zabytkowy, gdybym dziś miał przed nosem serwer z np i7, to W Gen2 mam wybór GCC, i np wersję 4.6 z -march corei7, gdybym chciał arch core2 - to potrzebuję >= 4.3.x.
We FreeBSD 9.0-RELEASE jest tylko gcc-4.2.x co mnie mocno zdziwiło.

A jeśli w jakimś systemie nie mam aktualnie dostępu do różnych opcji optymalizacyjnych kompilatora, to po kiego czorta w ogóle kompilacja?
Dla mnie to akurat nie jest "sztuka dla sztuki" tylko możliwość utrzymywania poziomu optymalizacji trudno dostępnego w Debianie.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2014-01-05 02:50:54)

W tym jedynym przypadku obyło się bez rc.conf:

grep tmp /boot/loader.conf
tmpfs_load="YES"

grep tmp /etc/fstab       
tmpfs /tmp tmpfs rw,mode=1777  0 0
tmpfs on /var/db/portsnap/files (tmpfs, local)
tmpfs /var/tmp tmpfs rw,mode=1777 0 0

mount | grep tmp
tmpfs on /tmp (tmpfs, local)
tmpfs on /var/db/portsnap/files (tmpfs, local)
tmpfs on /var/tmp (tmpfs, local)

Wszystko działa.

I tylko to pocieszne ostrzeżenie w logach:

Dec 12 14:47:18 localhost kernel: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD.

Ciekawe, ile jeszcze takich kfiatuszków highly experimental zobaczę w systemie, który jest absolutnym "szczytem profesjonalizmu" i "najlepszy na serwery" jak posłuchać czasem niektórych wyznawców znawców.

Jak mówi stare powiedzenie, to nie system  się nadaje lub nie, ino administrator się albo nadaje, albo nie.

Pod względem bezpieczeństwa - na okoliczność prawdziwych exploitów, nawet *buntu wdrożyło wszystko, co trzeba, 
Debian też się już dorobił w dpkg:  gcc -Wformat -Wformat-security
a FreeBSD osiągnęło dopiero -fstack-protector-all, co też jest owszem, potrzebne, ale ciekawe w kontekście bardziej historycznym niż współczesnym.

W tym punkcie nie brakuje co prawda w Linuxie systemów, które są 5 lat za Vistą, ale wśród ponad 100 aktywnych projektów takie rzeczy są możliwe, zawsze jakaś owca zostanie z tyłu.
Ale jak na "profesjonalny system nr1" a nie owcę,  trochę dziwna sytuacja. :D++

A miałem nadzieję, że o profesjonalnych systemach nie da się takich wątków pisać.

Edyta:

uname -a
FreeBSD localhost 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

freebsd-update ściagnął ponad 12000 łatek, system się zaktualizował do 9.1.
Właśnie się buduje nowe jajo.
Edyta 1.5:

>>> Kernel build for FBSD2 completed on Wed Dec 12 19:47:05 CET 2012

Edyta 2.0:

FreeBSD localhost 9.0-RELEASE-p5 FreeBSD 9.0-RELEASE-p5 #0: Wed Dec 12 19:19:43 CET 2012     root@localhost:/usr/obj/usr/src/sys/FBSD2  amd64

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-12 19:58:32)

A czy ktokolwiek zabrania użycia w *BSD kompilatora na GPL3?
Przecież GPL od zawsze dawała prawo do bezpłatnego użycia i dodawania własnych poprawek do kodu.
[Edyta]
Faktycznie, kompilowane programy mogłyby przypadkowo dziedziczyć licencję.
Choć np taki Skype czy Flashplayer działają na Linuxie, i nigdy nie musiałem ze Skypem instalować osobnego libC6 specjalnie dla Skypa.
[/Edyta]

Natomiast mocno skomplikowała działania RedHata, Novella czy innych cwaniaków, którzy chcieli robić komercyjny soft na bazie GPL i robić na tym kasę.

Moim zdaniem ewidentny błąd jest za to w licencji BSD, kiedy np Apple może sobie wziąść co najlepsze z tego systemu, zrobić na tej bazie zamknięty IOS i trzepać na nim tony kasy, nie odpalając twórcom zastosowanych rozwiązań programistycznych nawet na miskę ryżu.

Gdyby Apple do swoich zamkniętych systemów chciał wziąść kernel Linux, to musiałby uzgodnić z właścicielami praw autorskich cenę za prawo do użycia takiego czy innego kodu.
W przypadku kernela z resztą jest to zupełnie niewykonalne, różne łatki napisało około 10 czy 15 tysięcy Ludzi, próba dogadywania się z taką bandą nie jest zbyt wykonalna.

Krótko pisząc Red Hatowi czy Novellowi GPL3 nie przeszkadza robić komercyjnego Linuxa, ale nie mogą zabronić żadnemu posiadaczowi RHEL czy SLES modyfikować tego systemu wg własnych potrzeb, np kompilowania własnego kernela.
A i przy okazji ani Linus T. ani Ludzie z FSF głodni nie chodzą. :)

Z resztą pod względem optymalnego modelu biznesowego, GPL się wyraźnie sprawdziła, co widać choćby w obecnej popularności Linuxa w porównaniu z *BSD.

Jej bezpośrednim skutkiem jest też to, że jak np w fonie z Andkiem producent wpierdoli jakiś pojeb* system, który ciągnie z netu eksabajty niepotrzebnych danych  za moją kasę  i ma 100 narzędzi do analizowania tego, co ja robię i trzymam w fonie, to mogę zrootować grata, wrzucić np CyanogenMod,
i odetchnąć z ulgą.

A spróbuj to samo zrobić z Iphonem, czy Lumią.

Z resztą polecam ten wątek:
http://forums.gentoo.org/viewtopic-p-6274601.html?#6274601

To samo z routerami, ciekawe dlaczego DDWRT i OpenWRT powstały na Linuxie, podobnie jak np Tomato.
Widział ktoś kiedyś  alternatywny soft np na Linksysa WRT54-GS, który by bazował na jakimkolwiek systemie *BSD?
Bo mnie się nie udało, niestety.


Czy CLANG się sprawdzi, czy będzie miał takie samo wsparcie pod względem bezpieczeństwa na okoliczność różnych exploitow, czy te naście tysięcy programów, które się bez problemu kompilują na GCC, bezproblemowo się skompiluje na FreeBSD?
Clang - to jest nowa droga, komu w drogę, temu świeczka, mam jednak nadzieję że się FBSD nie zamknie w "złotej klatce".

W dodatku GCC ma dwie Licencje, GPL i LGPL, więc zamiast psioczyć na GPL3 - to może można zobaczyć, na co pozwala LGPL?

Może przesadzam, ale moim zdaniem, z tym psioczeniem na GPL jest trochę tak, jakby ktoś miał pretensję do swojej dziewczyny, że wychodząc na miasto,  pod spódnicę ubiera majtki. :D

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-12-13 08:31:09)