SLES 11 Service Pack 1 – wielka niespodzianka?

Novell poinformował o wydaniu SP1 dla swojej enterpriseowej dystrybucji. Pojawiło się wiele ciekawych rzeczy na polu wirtualizacji – na przykład aktualizacja Xen do najnowszej wersji 4.0, wsparcie dla KVM (warto przypomnieć, że główny konkurent Novella wycofał się ze wsparcia Xen właśnie na rzecz KVM – RHEL6 będzie mógł działać tylko jako gość Xen) oraz integracja z Hyper-V.

Również na polu HA pojawiło się kilka nowości – proste przywracanie węzłów przy pomocy ReaR. Pojawiły się nowe narzędzia administracyjne oraz symulator klastra.

W części desktopowej również pojawiły się aktualizacje – najnowsze wersje Firefoksa, OpenOffice, Evolution (wsparcie dla integracji z rozwiązaniami Microsoft).
Jednak najciekawszą zmianą jest zmiana polityki odnośnie jądra systemu. W service pack 1 jądro jest aktualizowane do wersji 2.6.32 :) .

SLES 11 został wydany z jądrem 2.6.27 – ta wersja została objęta przez Grega KH programem Long Term Support i regularnie pojawiają się do niej aktualizacje. Jednak utrzymywanie enterpriseowego jądra wiąże się również z utrzymywaniem dużej ilości backportów rozwiązań z nowszych wersji. Greg już trzy lata temu zauważył http://www.kroah.com/log/linux/enterprise_kernel_future.html , że jest to duży problem i zaproponował, żeby większe aktualizacje systemów enterpriseowych wprowadzały nowsze wersje jądra. Dave Jones z kolei uważa http://kernelslacker.livejournal.com/82610.html  że aktualny model utrzymania jądra w enterpriseowych dystrybucjach jest ok – w końcu ludzie za to chcą płacić.

W SLES 11 zmieniono jądro LTS na nowszą wersje również objętą programem LTS, która została zaakceptowana jako podstawa najnowszej wersji RHEL6. Wsparcie dla wersji 2.6.32 jest utrzymywane od ponad pół roku i będzie jeszcze utrzymywane minimum dwa lata (prawdopodobnie dłużej) – jest to wersja w której po wydaniu usunięto wiele błędów – bez wątpienia jest dopracowana. Jednak czy użytkownicy systemu SLES zaakceptują taką zmianę? Czy zostanie złamany zwyczaj panujący w systemach enterpriseowych? Czy Red Hat pójdzie w ślady Novella jeśli eksperyment się powiedzie?

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar koński_pytong
    koński_pytong

    Świetne distro, szkoda, ze takie brzydkie i przymulone.

    1. Awatar spy000yps
      spy000yps

      Świetny komentarz, szkoda, że taki… 😉

      1. Awatar vitek
        vitek

        …brzydki i przymulony.

    2. Awatar oO
      oO

      Świetne, to było S.u.S.E. puki Novel się nie dotknął. Od 10.x to totalna klapa i żenada.

      1. Awatar spy000yps
        spy000yps

        Tak, tak – pamiętam jak widziałem SuSE 5.x w sklepie – rok 1999 i cena 400 czy 500 PLN. Było super… Ten system miał wtedy podobną jakość do darmowego RH.

  2. Awatar Kazik
    Kazik

    Zawsze możesz sobie zmienić wygląd:D motywów na necie jest mnóstwo:D;P

    1. Awatar koński_pytong
      koński_pytong

      Równie moge zainstalować MacOSX lub Windows 7. Mój czas, bardziej cenie niż to ile musze wyłożyć na kompleksowe rozwiązanie.

      1. Awatar Plichu
        Plichu

        W takim razie kup siódemke kto ci broni 🙂
        Co kto lubi 🙂

        1. Awatar koński_pytong
          koński_pytong

          Takim rozumowaniem – zrob se, raczej nigdy linux nie wybije sie ponad 1%

        2. Awatar ciekawy
          ciekawy

          a niby po co się ma wybijać na więcej niż 1%?

        3. Awatar koński_pytong
          koński_pytong

          aby producenci go nie marginalizowali?

  3. Awatar spy000yps
    spy000yps

    Widzę, że jak zwykle komentarze na temat. Ale czego mogłem się spodziewać – nikt tu nie używa SLES'a czy RHEL'a 🙂

    1. Awatar egosc2341
      egosc2341

      Ja używam w pracy RHEL'a. I szczerze powiedziawszy, jezeli chodzi o kernel to mi pasuje jak jest. Ale jak klienci beda chcieli zmian to tak bedzie. Raczej tym sie bedzie Red Hat sugerowal.

      1. Awatar spy000yps
        spy000yps

        No właśnie to mnie bardzo ciekawi.

        1 reakcja klientów – jednym może się podobać innym nie. Według mnie rozwiązanie dobre jako opcja – upgrade jądra na serwerze do którego nie ma się fizycznego dostępu mógłby być ryzykowny. Ale na desktopach mogłoby się sprawdzić.

        2 jak RH na to zareaguje jeśli Novellowi się powiedzie. RH podchodzi do sprawy dość konserwatywnie – jeśli takie rozwiązanie zostanie zaakceptowane przez rynek to RH może zmięknąć – ale to może się przestać podobać niektórym klientom…

        1. Awatar egosc2341
          egosc2341

          jest też 3 możliwość teoretycznie można dostarczyć dwie linie kernela dla RHEL. Podobnie jak robi to obecnie z mniej ważnymi aplikacjami (samba, postgresql, …).

          To rozwiązanie byłoby pewnie pewnym kompromistem między tymi co chcą zmian, a tymi co wolą pozostać przy obecnym systemie.

          Jednak to rozwiązanie ma pewna wade, i myśle, że Ci co maja do czynienia z systemami Enterprise, będą wiedzeć o co chodzi.

        2. Awatar spy000yps
          spy000yps

          W zasadzie, to RH już teraz dostarcza dwa jądra do wersji 5 – standardowe 2.6.18 – dobrze utrzymane i 2.6.24 do wersji MRG – które nie otrzymuje regularnych poprawek. Nie wiem – może z tego zrezygnowali i zakończyli support?

        3. Awatar egosc2341
          egosc2341

          Szczerze nie mam pojęcia o MRG, gdyz sie tym nie zajmuje. Mowiac o 3 mozliwosci mialem na mysli to, ze mozna w chocby najtanszym "Desktop", zainstalowac samba lub samba3x. Jedna jest nowsza od drugiej i mozna ta zamiane zrobic normalnie, a nawet jak ktos sie uprze to moze codziennie reinstalowac na poprzednia/nastepna wersje, lub uzywac jednej z nich ze standardowym wsparciem.

        4. Awatar spy000yps
          spy000yps

          Ja jednak myślę, że to jednak nie ma raczej dużego znaczenia.

          Jednak jeśli chodzi o jądro, to trzeba wziąć pod uwagę też sterowniki dostarczane przez firmy trzecie. Dochodzi do sytuacji w której dla jednej wersji systemu trzeba by dostarczyć dwie wersje sterownika pod różne jądra. Jeśli jeszcze przez wszystkich jest zrozumiałe dostarczanie dla różnych architektur, tak dla różnych service packów może nie zostać dobrze przyjęte.

          Ciekawe jak to Novell sobie przekalkulował?

        5. Awatar egosc2341
          egosc2341

          Właśnie, o to mi chodziło pisząc o wadzie.

          Zarówno rozwiązanie Novella jak i przykład podany przezemnie ma tą wade, że trzeba będzie prawdopodobnie (zmian między kernelami dokładnie nie znam wiec nie wiem na ile), ale przygotowywać dwie wersje sterowników urządzeń dla jednej serii systemu.

          Jednak mi pasuje mimo wszystko takie rozwiązanie jak jest teraz. Jest prawdopodobne mimo wszystko, że Red Hat nie ugnie sie i nie da nowszych kernelów. Przypomiam sytuacje między innymi z umowami patentami i może np. mono w RHEL.

    2. Awatar makakaa
      makakaa

      Same "dzieci Ubuntu":P

      1. Awatar spy000yps
        spy000yps

        Chyba tak 😉

        BTW. Ubuntu zapewnia jakiś support, który przy odrobinie dobrej woli dałoby się porównać do tego dla SLES czy RHEL?

        Bo biorąc pod uwagę stopień ich wpływu na dajmy na to rozwój jądra systemu, to można przypuszczać, że są to tylko przebrandowane pakiety z Debiana.

        1. Awatar D3X
          D3X

          nie tylko przebrandowane, ale jeszcze zepsute 😉 [patrz: OOo i jego niedziałanie w trybie headless chociażby]

        2. Awatar spy000yps
          spy000yps

          No po Ubuntu to raczej nie spodziewałbym się, żeby coś naprawili…

          Nawet z własnymi rozwiązaniami im kiepsko wychodzi. Od paru lat próbują zrobić Upstarta i coś SJR to nie wychodzi. W wersji 0.3 w ogóle nie działały zależności pomiędzy skryptami, w wersji 0.5 już coś tam działało, ale mieli poprawić w 0.6. Wersja 0.6 jest w stanie w którym sam autor uważa, że to niewłaściwa ścieżka i dopiero w wersji 1.0 ma być zrobione wszystko jak trzeba… Pożyjemy to zobaczymy… Cudów bym się nie spodziewał.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *