Kategorie:
18

Rząd Federalny USA a Open Source

Federal Open Source Alliance opublikowało wyniki ankiety przeprowadzonej we współpracy z Rządem Federalnym USA na temat zastosowania Open Source w administracji Stanów Zjednoczonych.

Oto co się okazało:

  • 71% respondentów uważa, że ich agencja może skorzystać na wdrożeniu Open Source.
  • 55% jest zaangażowanych we wdrożenie związane z Open Source, z czego 90% jest zadowolonych z wyników.
  • Z zalet Open Source wymieniane są najczęściej zwiększenie bezpieczeństwa (30%), konsolidacja centrów danych (17%), możliwość dostosowania aplikacji (17%), interoperacyjność (12%) i niższy koszt (co ciekawe tylko 9%).
  • Przeciwnicy wdrażania OSS za główne przeszkody uważają problemy z bezpieczeństwem (40%, sic!) i brak dobrego wsparcia technicznego (26%).

Co ciekawe, jak wynika z przedstawionych danych, bezpieczeństwo jest bardzo ważne zarówno dla wdrażających Open Source jak i dla reszty. Wdrażający uważają, że dzięki OSS zwiększyli bezpieczeństwo IT, a nie wdrażający uważają, że kwestia bezpieczeństwa byłaby trudna do implementacji w przypadku oparciu infrastruktury o OSS.

Wszystkie procenty dotyczą tych z ankietowanych, którzy odpowiedzieli na zadane im pytania (w sumie 218 wydziałów z departamentów: obrony, spraw wewnętrznych i wywiadu).

Federal Open Source Alliance to wspólna inicjatywa firm Intel, HP i Red Hat.

Więcej informacji: http://www.tectonic.co.za/view.php?src=r...ss&id=1856

«
»

Znalazłeś literówkę? Zgłoś ją używając formularza!


Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.

Niusy na podobny temat:

Komentarze (RSS)

Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.

16 komentarzy

zwiń wątek inftykeler  6 listopada 2007 o godz. 1:59 #
Gravatar

za główne przeszkody uważają problemy z bezpieczeństwem (40%, sic!)

Przypomniała mi się petycja do MSWiA (o ile dobrze pamiętam)

Chyba nie tylko u nas ludzie nie rozróżniają freeware od Open Source. :(

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek wojtek79  6 listopada 2007 o godz. 9:29 #
Gravatar

Po prostu dużo ludzi rozumuje na zasadzie: "jawność kodu programu ułatwia atak i pisanie wirusów" – co jest kompletną bzdurą. Tak naprawdę jawność kodu upewnia nas że program nie ma "ukrytych drzwi".

zwiń wątek trasz  6 listopada 2007 o godz. 10:22 #
Gravatar

Po pierwsze, owszem, "security by obscurity" nie dziala, ale "security aided by obscurity" jak najbardziej tak. Po drugie, dla duzych instytucji jawnosc kodu nie ma znaczenia, bo jesli potrzebuja kodu, to sobie kupia wglad w niego.

zwiń wątek munk  6 listopada 2007 o godz. 22:08 #
Gravatar

Coś twoje obscurity się nie sprawdza. W żadnym wydaniu.

Jeżeli producent troszczy się o bezpieczeństwo, to nie ma znaczenia czy kod będzie otwarty czy zamknięty. Zamknięcie kodu powoduje jedynie, że możesz pisać szmelc, a nikt ci tego nie wytknie. Co najwyżej ludzie się przekonają jak (źle) działa w praktyce. Ale jakoś nikt nie wyciąga wniosków.

> jesli potrzebuja kodu, to sobie kupia wglad w niego

To w ramach obniżania kosztów? A potem powiedzą jeszcze, że otwarte rozwiązania są drogie?

Właściwie to co ty robisz na tym portalu? :)

Krytykujesz każdy pojawiający się news, i nie jest to nawet krytyka konstruktywna. To takie twoje hobby?

Może kwestią trolli powinni zająć się psychologowie. Wyniki takich badań mogłyby być bardzo ciekawe.

 
 
 
 
zwiń wątek Aleksander Sanetra  6 listopada 2007 o godz. 10:58 #
Gravatar

brak dobrego wsparcia technicznego

Zauważyłem (przy najmniej na rodzimym poletku), że pretensje do braku jakiegokolwiek wsparcia dla OSS mają (o zgrozo) informatycy z wyższym wykształceniem posiadający kilka certyfikatów.

Takiego problemu praktycznie nie widzą przeciętni (biorąc pod uwagę wykształcenie) informatycy.

Ciekawe (przynajmniej dla mnie) było to, że jak zaproponowano zastosowanie jakiegoś skryptu (w tym wypadku opartego PHP+Ruby) to z ust – rzekomo – przeciętnych informatyków padło "najpierw sprawdźmy czy stoi przy tym w miarę silna społeczność" (cytat niedosłowny). Wyższa półka uznała, że nie warto, bo co będzie jak autorzy porzucą skrypty i nie będą ich dalej rozwijać.

Może w tym trzeba upatrywać problemy. Niektórzy z nas zrobili się po prostu leniwi i wolą kazać przełożonym wybulić kasę a samemu nic nie robić?

Przecież wielu moich znajomych, którzy ładują często po kilka tysięcy złotych rocznie na wszelkiej maści szkolenia (na koszt firmy oczywiście) była by wstanie większość potrzebnych rzeczy napisać samemu a nie specjalnie chce udzielać się w społecznościach zgromadzonych woku jakiegoś projektu. Co innego informatycy niżsi rangą.

Takie przynajmniej odniosłem wrażenie w kontaktach z małymi i średnimi firmami, które wyraziły zainteresowanie linuksem.

Chciałbym się mylić, gdyż należę do niższej "kasty" i moja wiedza nie zawsze może pomóc, natomiast ludzie z TOPu wnieśli by wiele dobrego (mam nadzieję).

A może miałem pecha i spotykam "tych niewłaściwych"?

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek trasz  6 listopada 2007 o godz. 17:06 #
Gravatar

"Przecietni informatycy" zwykle nie adminuja systemami, gdzie brak supportu moze miec powazne (kosztowne) skutki.

zwiń wątek dimri0  7 listopada 2007 o godz. 15:35 #
Gravatar

doswiadczenie pokazuje, ze firma lepiej toleruje male, ale przewidywalne wydatki. OSS jest nieprzewidywalne pod tym wzgledem, a to, ze spolecznosc nie bierze na siebie konkretnej odpowiedzialnosci (chociaz kasy tez nie) wcale nie pomaga. IMHO wielu ludzi mogloby zbic majatek na prowadzeniu firm consultingowych ds. OSS.

 
 
 
zwiń wątek mario  6 listopada 2007 o godz. 11:22 #
Gravatar

"niższy koszt (co ciekawe tylko 9%)"

Tylko 9% bo w takich projektach zazwyczaj koszta są mniej ważne, te 9% to projekty w których koszta rzeczywiście mają znaczenie. Cena Windows przy większości projektów dla dużych firm to opłata symboliczna, cena serwera to opłata malutka, a cena systemu który kupują wraz z tym sprzętem i OSem to prawdziwa cena projektu. W takich przypadkach Linux może wygrać tylko niezawodnością, bezpieczeństwem i wydajnością. Niestety wchodzi w to pranie mózgu przez MS :-( , czyli tzw. kampania reklamowa.

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek jellonek  6 listopada 2007 o godz. 12:20 #
Gravatar

te 9% to respondenci ankiety, a nie projekty…

zwiń wątek mario  6 listopada 2007 o godz. 16:29 #
Gravatar

Ilość procentowa respondentów ankiety przekłada się na ilość projektów w których cena ma znaczenie.

 
 
 
zwiń wątek ljarochowski  6 listopada 2007 o godz. 12:32 #
Gravatar

nie chodzi o problemy z bezpieczeństwem jako problem z jawnością kodu, tylko chodzi o to, że projekt rozwijany przez społeczność bez ośrodka centralnego (jakim np. w Linuksie jest Torvalds między innymi) może mieć dużo kodu komitowanego przez ludzi nie mających pojęcia o bezpieczeństwie. To oznacza, że przed każdym wydaniem konieczny jest audyt kodu, a na to zwykle nie ma czasu i środków. Tu jest problem, a nie w jawności kodu.

Wystarczy spojrzeć na OS aplikacje internetowe – niektóre z nich są dziurawe jak sito i wciąż są łatane ad-hoc. Oczywiście czas wykrywania dziur jest znacznie szybszy, ale też wiedza o dziurach szybko się propaguje a co za tym idzie dużo czasu (i kosztów) trzeba poświęcić na monitorowanie różnych portali security.

Proszę, pamiętajmy że OS to znacznie więcej niż OpenOffice.org i Linux.

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek stronger  6 listopada 2007 o godz. 13:41 #
Gravatar

chodzi o to, że projekt rozwijany przez społeczność bez ośrodka centralnego (…) może mieć dużo kodu komitowanego przez ludzi nie mających pojęcia o bezpieczeństwie.

Czyli zupełnie tak samo jak w przypadku zwyczajnych firm informatycznych.

Nie czarujmy się, że ci, którym się płaci produkują bezpieczne oprogramowanie, a ci nieopłacanie robią błędy. Dziury są i będą zawsze i w każdym modelu rozwoju oprogramowania, a jeżeli miałbym ryzykować jakieś stwierdzenie to takie, że w projektach open source biorą udział ludzie wyjątkowo oddani, traktujący swe zajęcie poważnie, zaś w projektach/produktach komercyjnych programistów przydziela się niezależnie czy lubią dany kod/problem/projekt, dodatkowo częsta rotacja zatrudnionych nie ułatwia utrzymywania odpowiedniego poziomu bezpieczeństwa.

zwiń wątek Aleksander Sanetra  6 listopada 2007 o godz. 13:50 #
Gravatar

Po za tym w projektach społecznościowych łatwiej jest powiedzieć "poczekajcie z publikacją bo…." a w projektach zamkniętych często górę bierze "wypuścić i ciągnąć kasę a poprawki zrobi się później".

 
zwiń wątek trasz  6 listopada 2007 o godz. 17:05 #
Gravatar

Ale w projekcie wlasnosciowym odpowiedzialnosc mozna w jakis sposob ustalic.

 
zwiń wątek ljarochowski  7 listopada 2007 o godz. 11:32 #
Gravatar

bardziej chodzi o to, że jeśli kupuje się oprogramowanie od firm trzecich, to zwykle jest jakiś support, ktoś ponosi za nie odpowiedzialność. W momencie kiedy w firmie zaczyna stosować się OS to z problemami musi sobie firma radzić sama, a to bardzo często jest problematyczne.

przykład: firma X chce stosować OS CRMa, z uwagi na rozproszoną działalność (handlowcy ciągle w ruchu) istnieje konieczność zrobienia CRMa w sieci (jako aplikacja sieciowa). Jeśli teraz w firmie jest jeden informatyk, którego głównym zadaniem jest administracja systemami i dbanie o laptopy handlowców, to istnieje wielkie ryzyko tego, że dziurawa aplikacja spowoduje duże straty w firmie. W przypadku oprogramowania z supportem można wykonać kilka telefonów i zrzucić odpowiedzialność poza firmę.

Jeśli chodzi o samo tworzenie aplikacji to w świecie oprogramowania jest kilka modeli tworzenia aplikacji. Jednym z nich jest model płaski – wszyscy robią co chcą i puszczają commity a problemy bezpieczeństwa rozwijane są ad-hoc. Przykładem czegoś takiego jest np. Joomla!, która ma główny zespół programistów i społeczność piszącą komponenty, za które również w pewien pośredni sposób, ten zespół bierze odpowiedzialność. Inny model to model zcentralizowany – każdy programista ma sztywno określony kawałek kodu do napisania, jest zespół główny, który zarządza tym kto co pisze. Jest szansa, że nie powstaną wtedy błędy projektowe (które są przyczyną najgroźniejszych błędów bezpieczeństwa imho). Jeszcze inny model to model pośredni – grupa główna kieruje rozwojem całego projektu, ale programiści mają pewną swobodę. Przykładem czegoś takiego jest np. Linux.

Dlatego moim zdaniem twierdzenie że to, czy aplikacja jest OS czy nie jest, wpływa na bezpieczeństwo jest twierdzeniem błędnym. Oczywiście w przypadku jawnego kodu źródłowego szybciej można wydawać poprawki, ale tak na prawdę wpływ na bezpieczeństwo przede wszystkim ma sposób rozwijania aplikacji i decyzje polityczne.

W decyzje polityczne zwykle wglądu nie mamy, ale temu jak rozwijana jest aplikacja moim zdaniem przyjrzeć się trzeba.

 
 
 
zwiń wątek Sławek  6 listopada 2007 o godz. 17:48 #
Gravatar

"# Przeciwnicy wdrażania OSS za główne przeszkody uważają problemy z bezpieczeństwem (40%, sic!) i brak dobrego wsparcia technicznego (26%)."

Czyli mniej, niż 12% ankietowanych? No nieźle. Myślałem, że FUD (wiadomo jaki) daje lepsze wyniki.

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
 

Uwaga! Niektóre komentarze, m.in. te dodane przez niezalogowanych i nowych użytkowników, są ręcznie moderowane. Jeśli Twój komentarz nie ukaże się od razu, nie dodawaj go ponownie, tylko cierpliwie poczekaj na akceptację.

W komentarzach możesz używać prostych znaczników HTML. Przykłady:
  • Link: <a href="http://osnews.pl">OSnews: niusy IT</a>,
  • Wytłuszczenie: <strong>tekst pogrubiony</strong>,
  • Kursywa: <em>tekst pochylony</em>,
  • Przekreślenie: <strike>tekst przekreślony</strike>,
  • Kod: <code>printf("blok kodu");</code>,
  • Cytat: <blockquote>cytat</blockquote>
Uwaga: jeśli dodasz nieznany znacznik, będzie on niewidoczny, gdyż system filtruje takie znaczniki.

Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.

Twoja sugestia