Oracle фактически ликвидирует Sun

    Избегайте этой ловушки, не следует придавать антропоморфные черты Ларри Эллисону.
    Брайэн Кантрилл


    Похоже, что в Oracle приняли решение окончательно избавиться от трудовых ресурсов, составляющих костяк Sun Microsystems. Массовые увольнения затронули около 2500 сотрудников, работающих над операционной системой Solaris, платформой SPARC и системами хранения данных ZFS Storage Appliance.





    Это не рядовая трансформация — оптимизация, а настоящая бойня. По мнению создателя системы динамической отладки Dtrace Брайэна Кантрилла (Bryan Cantrill) на сей раз нанесен непоправимый ущерб, в результате потери 90% производственных кадров подразделения Solaris, включая все руководство.


    От Solaris до illumos


    В 2009 г. Oracle приобрел испытывающую серьезнейшие трудности на рынке Sun Microsystems за 5.6 млрд. долларов США. Компания теряла позиции на рынке вследствие лавинообразного распространения Linux в качестве серверной ОС, успеха платформы amd64 и невнятной стратегии по взаимоотношениям с сообществом открытого ПО. Solaris стал открытым слишком поздно — лишь в 2005 г., причем открытым не полностью, отдельные элементы ОС, такие как локализация и некоторые драйвера, оставались проприетарными. Затем появился OpenSolaris, однако точкой сбора сообщества он не сумел стать. То ли дело была в лицензии CDDL, то ли проблема была в том, что Sun пыталась манипулировать проектом. Трудно сказать почему именно, но не взлетел.


    Kicked butt, had fun, didn't cheat, loved our customers, changed computing forever. Scott McNealy

    Эпитафия Скота МакНили как нельзя лучше отражает жизненный путь компании — отлично развлекались, не дурили головы своим заказчикам и навсегда изменили ИТ. Довольно быстро стало очевидно, что Solaris Ораклу попросту не нужен, и развивать его он не намерен. Затем 13 августе 2010 г. случилось одно из самых позорных событий в истории открытого ПО — компания втихую закрыла исходный код OS Solaris. Никаких официальных заявлений на сей счет не последовало.


    We will distribute updates to approved CDDL or other open source-licensed code following full releases of our enterprise Solaris operating system. In this manner, new technology innovations will show up in our releases before anywhere else. We will no longer distribute source code for the entirety of the Solaris operating system in real-time while it is developed, on a nightly basis.

    Это всего лишь отрывок из внутреннего циркуляра для сотрудников компании, который естественно сразу же просочился в прессу. Тут речь идет о том, что исходный код будут выкладывать только во время релиза новой версии ОС, а обновления будут только бинарными. Но это оказалось неправдой, после выхода Solaris 11 исходный код не выложили.


    Для тех, кто владеет английским очень рекомендую посмотреть выступление Брайэна Кантрилла на конференции Usenix. Эпиграф к статье — одна из его цитат, вот еще несколько.





    О принципах руководства компании. Оставшись без мудрого руководства манагеров инженеры выдали гору инноваций: ZFS, DTrace, Zones и много других.


    Sun управлялась со стороны враждующих группировок во главе с атаманами, как Сомали.

    О закрытии исходного кода OpenSolaris.


    Это ОТВРАТИТЕЛЬНАЯ выходка со стороны корпорации. Вот из-за такого поведения мы становимся циничными и подозрительными.

    О последствиях закрытия исходников OpenSolaris для нового проекта ОС illumos — полностью открытого форка OpenSolaris.


    Мы готовимся к моменту Судного Дня в лицензиях открытого исходного кода, у нас есть такие сценарии, они работают и это здорово.

    Вскоре после этого из Oracle ушли все разработчики DTrace, создатели ZFS, команда zones и сетевики. Вся разработка и инновация на этих направлениях далее происходила операционной системе illumos, где осела диаспора программистов из Sun Solaris. Благодаря особенностям открытых лицензий, в том числе CDDL, в рамках которой шла разработка OpenSolaris, Oracle не может претендовать на все последующие улучшения в коде illumos. То есть может, но только в рамках своего же проекта с открытым кодом. Сценарии Судного Дня работают как надо.


    Для полноты картины стоит добавить, что Oracle активно участвует в разработке ядра Linux, где традиционно входит в десятку наиболее активных компаний.


    Факты россыпью


    • Главная цель: выдоить патентные отчисления и штрафы у Google за использование Java в ОС Андроид, ставки были крупные — $8 млрд. Не срослось.
    • В целом монетизация Java не удалась, Oracle передает NetBeans Apache Foundation, верное решение.
    • Также решено не запускать платформу Sun Cloud.
    • Из-за бюрократических проволочек вокруг заплаток безопасности для MySQL, появился форк MariaDB, куда перешло значительное число разработчиков и часть сообщества. Их оказалось достаточно для новой компании.

    Выводы


    Sun Microsystems еще недавно — живая легенда и лучшее, что когда-либо было в Unix. Вот лишь небольшая часть их наследия.


    • NFS
    • RPC
    • ZFS
    • DTrace
    • Zones
    • Fault Management Architecture
    • Service Management Facility

    Компания Oracle имела все возможности для того, чтобы развивать и поддерживать OpenSolaris, но вместо этого закрыла исходники и с тех пор Solaris уже не имел будущего. Когда тяжба с компанией Google за использования Java в мобильной ОС Андроид закончилась пшиком в Oracle потеряли к активам Sun Microsystems всякий интерес. Вместо этого компания будет продавать ПО на основе собственной операционной системы — Unbreakable Linux.


    Материалы по теме


    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 82
    • +15
      Как-то желто. Java остается, MySQL остается, VirtualBox остается, может еще что-то, особо не разбирался что входило в Sun на момент покупки. Только Solaris и Co перестают развивать, давно к этому шло, мало кто делает новые решения на базе Solaris.
      • –1
        А что Оракл делает для развития Java?
        • +20

          Т.е. то, что будет в Java 9 и делается для Java 10 — не считается? Или, быть может, вы считаете, что в OpenJDK Оракл почти не контрибьютит?

          • +1
            Сравните то, что есть/будет в java 9 и то, что уже есть в C#. Java как язык замер в развитии, и постепенно сдает позиции.
            • +6
              Одно из главных приемуществ java (для интерпрайза и для большой массы прогеров) — в язык не мусорят синтаксическим сахаром.

              Это фича, а не сдача позиций…
              • +8
                В чем примущество отсуствия сахара? Зачем жертвовать удобством написания и читания кода?
                Ни в одном современном языке не приходиться писать:
                balance.setSaldoOut(balance.getSaldoIn().add(balance.getNach()).subtract(balance.getPayment()));

                вместо простого и понятного:
                balance.saldoOut = balance.saldoIn + balance.nach - balance.payment;

                • 0
                  В вашем коде BigDecimal это софтварный тип, его реализация написана на java (обычный класс).

                  Чтобы убрать эту лапшу надо добавить operator overloading (тот самый синтаксический сахар) или добавить обработку этого типа в JVM…
                  • 0
                    забыл про property.
                    Это одна из тех неоднозначных штук, которые не стоит тащит в java… это не только мое мнение.
                    • +1
                      Ну да, еще про оператор var из C# забыли. Очень удобно писать SomeBigNameOfClass result = new SomeBigNameOfClass();

                      По факту тогда, в чем смысл криков про лямбды и больше новых фич в новых версиях? Все же можно через сторонние либы сделать или, как вы сказали, добавить обработку типа в JVM.
                    • +1
                      Только вот ни того ни другого в Java нет, а во всех современных языках есть.
                      Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
                      • –2
                        Только вот ни того ни другого в Java нет, а во всех современных языках есть.

                        Представьте что в java ввели operator overloading. Многие обрадуются тому что .equals() больше не нужен и переопределят оператор "==".
                        В результате получим сюрпризы в стиле #define true (Math.random()>0.5) и кучу поломанных вещей типа IdentityHashMap.

                        Сахар почти всегда имеет недостатки. Он может ухудшать поддерживаемость кода или может поломать совместимость.
                        Ниже Delphinum описал одну из проблем сахара.
                        • +2
                          Писать код вида #define true (Math.random()>0.5) все равно не запретишь. Сейчас это можно размешать внутри equals и радоваться странным результатам. Это не та проблема с которой нужно бороться.

                          Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
                          • 0
                            Писать код вида #define true (Math.random()>0.5) все равно не запретишь.

                            Неправильно выразился. При сравнении через == ожидаешь, что будет сравнение по ссылке, а не по значению.
                            Кто-то может (не специально) переопределить == в каком-то классе, В результате может появиться очень хитрый баг и странное/рандомное поведение программы.

                            У меня такое было на одном проекте.
                            • 0
                              Я понимаю, что изменить поведение "==" уже не получиться, но можно хотя бы ввести "===" на сравнение по значению. Это не ломает совместимость. В js уже так поступили.
                              • +1
                                Не дай бог. Не нужно в Java этого костыля, пусть остается в JS.
                                • 0
                                  Костыль это Object.equals(a,b) не удобный в использованию и не работающий к тому же для чисел.
                                  • 0
                                    Метод в объектно-ориентированном языке не может быть костылем по определению ) Вот === вполне. И ради чего, чтоб Java был больше похож на JS? Да сами JS разработчики не в восторге от ==/===, а вы предлагаете его еще и перенести в язык без этого костыля. Не нужно.
                                    • 0
                                      В js используется == в java же он очень редкий зверь годный только для примитивов. Единообразие в синтаксисе сильно повысит читаемость. А предупреждения при компиляции помогут избегать ошибок. Можно же попросить явно аннотировать места где используется именно сравнение по ссылке.
                                      • 0
                                        Мне лично кажется, что при соревнованиях между скоростью разработки и православностью синтаксиса в долгосрочной перспективе при прочих равных всегда выигрывает скорость разработки. Поэтому лично мне кажется, что упарываться чистотой белой расы синтаксиса — это путь в никуда.
                    • +1
                      Почему вы пытаетесь использовать объектно-ориентурованную Java как процедурный ЯП? По хорошему, ваш пример на Java должен выглядеть так:
                      balance.recountSaldoOut();
                      

                      и реализовываться так:
                      public recountSaldoOut(){
                        saldoOut = saldoIn + nach - payment;
                      }
                      
                      • 0
                        Так писать на Java не получиться. Максимум выйдет следующее
                        public recountSaldoOut(){
                        	saldoOut = saldoIn.add(nach).subtract(payment);
                        }

                        Плюс подобное работает только если работаем с одним объектом. Если входных объектов несколько и есть еще выходной, то данный подход не сработает.
                        • 0
                          Так писать на Java не получиться

                          Ну это зависит от типа saldoIn, nach и payment.

                          Если входных объектов несколько и есть еще выходной, то данный подход не сработает

                          Почему? Можно ведь всегда указать зависимости, в том числе функциональные, на пример так:
                          public getSaldoOut(nach, payment){
                            return saldoIn.add(nach.getValue() - payment.getPaid());
                          }
                          
                          • –2

                            Если у вас все данные находятся внутри класса, то что мешает вам сделать так?


                            class Balance {
                              private double saldoOut;
                              private double saldoIn;
                              private double nach;
                              private double payment;
                            
                              public void recountSaldoOut(){
                                saldoOut = saldoIn + nach - payment;
                              }
                            }
                            • +1
                              double для финасовых приложений не пригоден. Везде надо использовать BigDecimal, чтобы хотя бы сложение/вычитание работало с абсолютной точностью. Класс же BigDecimal использовать для арифметики не удобно. Простое сравнение с нулем выглядит так
                              public boolean isZero(BigDecimal val) {
                                      return BigDecimal.ZERO.compareTo(val) == 0;
                              }
                              • 0

                                Ну требований использовать BigDecimal нигде не было, поэтому я и предложил такой вариант. Как по мне, то так даже лучше, потому что явно видно разделение на быстрые примитивные типы и более затратные классы. А вот в scala, например, на простых задачах идет больший расход памяти. За все надо платить и java тут отлично сбалансирована.

                                • 0
                                  Название balance уже само собой подразумевает финансы) Где альтернатив просто нет.
                                  • 0

                                    Никогда не работал в java с финансами, поэтому для меня это не очевидно совсем

                                    • 0
                                      Ксчастью вам не приходилось постоянно ковыряться в многостраничных текстах арифмитических операций, которые трудно читаемых в любых случаях чуть более отличных от тривиальных.
                                • 0
                                  На самом деле, можна записать ваш код короче, использовав метод signum()
                                  return val.signum() ==0;
                            • 0
                              Соглашусь на 80%

                              Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.

                              Но syntax sugar все же удобен.
                              • –1
                                Но syntax sugar все же удобен

                                Проблема syntax sugar в том, что он делает кривую обучения более крутой. Для понимания работы кода, необходимо понимать не только базовые операторы языка, но и особенности реализации «сахара».

                                Это особенно заметно в проектах, без стандартизации формата кода и с большим числом разработчиков. Кодовая база быстро делится на блоки, с которыми работают только те разработчики, которые знакомы с используемым в этом блоке «сахаром». На практике это выглядит примерно так: «в проект пришел джун, запилил реализацию на каком нибудь модном сахаре, после чего покинул проект, и реализацию либо переписали, либо все бояться ее трогать».
                                • +5
                                  На изучение возможностей сахара требуется ничтожное количество времени. Вот чтобы изучить, сконфигурировать и настроить простейший сервер, требуется на порядки больше времени и усилий, чем на изучения скажем множественного возврата.
                                  • –1
                                    Это от человека зависит, сколько ему времени требуется для изучения сахара, а если это группа человек, то времени требуется еще больше, и все для того, чтобы джуниор мог попробовать в проекте новый «сахар». Такая себе плата за «сахар», заменяющий add() на +
                                    • +2
                                      На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени.

                                      В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
                                      • –1
                                        На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени

                                        Повторюсь: это зависит от типа. Если вы работаете с примитивами, они прекрасно поддаются сложению с использованием математических операторов, но если вы пишете свой тип (класс), то придерживайтесь объектной нотации — операции над объектами это методы. Любой разработчик на java это понимает сразу. На понимание смеси процедурного и объектно-ориентированного кода уходит больше времени просто потому, что это два подхода, а не один, что, априори, требует больше знаний.

                                        В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.

                                        Возможность перегрузки математических операторов спорна, так как применима далеко не к любому типу чисто семантически, а методы, в свою очередь, позволяют отразить операцию максимально приближенно семантически к домену.
                                        • +1
                                          Вся боль, что так как Java это в первую очередь финансовые системы, а все расчеты для них ведутся через стандартный BigDecimal. Работать с остальными примитивами нельзя.
                                          А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
                                          • +1
                                            Потому я вам сразу и сказал: работая с объектно-ориентированным языком, придерживайтесь объектно-ориентированной нотации. Математические операторы это не объектно-ориентированная нотация, потому ее и нет в Java.
                                            • 0
                                              А аттрибуты?
                                              • 0
                                                Что «аттрибуты»?
                                                • 0
                                                  Аттрибуты вписываются в концепцию объектно-ориентированная нотации?
                                                  • 0
                                                    Если они инкапсулированы. По сути, атрибуты (я предпочитаю термин — свойства) не видны снаружи, потому их семантически не существует, вы оперируете объектами и методами, а не переменными, данными и операциями над ними. В этом и отличие объектной нотации от процедурной.
                                                    • 0

                                                      Т.е. я прописываю классу атрибут Controller, кардинально меняю его поведение, считай, наследуюсь от другого класса и это все вписывается в объектно-ориентированную нотацию?

                                                      • 0
                                                        Вы под атрибутом понимаете «аннотацию» или «метаданные»? Если так, то это уже не объектно-ориентированная нотация, а декларативная.
                                              • 0
                                                Вместо того, чтобы решить проблему, вы предлогаете постоянно бороться с плохим дизайном языка, не предусмотревшем арифметических операций.
                                                • 0
                                                  Почему вы решили, что если у другого ЯПа непривычный для вас дизайн, то это плохой дизайн? Вы давно занимаетесь разработкой? Вы знакомы более чем с 1 ЯПом?

                                                  Если вы привыкли к математическим операторам и процедурному подходу, возможно вам стоит использовать язык, который под это лучше заточен, а не Java, которая является объектно-ориентированным языком.
                                                  • 0
                                                    Я из хожу из простого наблюдения, что один и тот же код написаный на js и на java. Читаем на стороне фронта, а вот на стороне сервера вызывает затруднения. К сожалению просто поменять язык сервера нельзя.
                                                    К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
                                                    • 0
                                                      К сожалению просто поменять язык сервера нельзя.

                                                      Ну согласитесь, что если вам тяжело читать Java и нельзя заменить его на беке, то это ваши проблемы, а не проблемы языка.

                                                      К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение

                                                      Тоже задаюсь этим вопросом.
                                          • 0
                                            Для стринга же определили ;)
                              • 0

                                Кроме непосредственно Джавы есть ещё jvm, на которой работает ещё куча языков с кучей фич. Код на этих языках можно положить прямо в тот же проект, что и код на джаве. Так что те, кто желает сахара — без проблем могут его получить.

                            • 0

                              Посмотрите на состояние стандартов. Того же JPA несчастного. Они же лет 5 не обновляются, все новые фичи вендоры делают в виде несовместимых расширений.

                              • 0

                                Все же я думаю некоторый прогресс присутствует

                                • +2
                                  Вообще, да, будет интересно посмотреть. Но пока что это только обещания.
                                  Кстати, первый же комментарий озвучивает мою точку зрения
                                  А вообще складывается такое чувство что Oracle уже устал от java и хочет потихоньку вытолкнуть его полностью на плечи сообщества, нагнуть гугл на отчисления не вышло вот наверное и думают как аккуратно сбагрить все это добро.
                                • +1
                                  Того же JPA несчастного

                                  А что там не так то? Цепляем обычный драйвер, поверх накатываем ORM by Hibernate. Все, не паримся, «оно работает».
                                  • 0

                                    Покажите мне, как последней версии спецификации JPA задокументирована поддержка UNION.
                                    Я понимаю, что Hibernate, EclipseLink и прочие это давно и даже более-менее совместимо умеют. Меня интересует наличие стандарта, гарантирующего, что мой запрос не нужно будет полностью переделывать в случае перехода на другую ORM.
                                    Да, такое бывает.

                                    • 0
                                      что мой запрос не нужно будет полностью переделывать в случае перехода на другую ORM.

                                      Не, если у вас это не сфероконные вопросы/ситуации, а вот прям реально на горизонте указанно, что «скоро будем менять подсистему ORM с X на Y», тогда да, возможно этим вопросом надо так же озадачиться.

                                      Однако, на моей памяти не было такого, что по непонятным причинам меняется сама ORM. Во-вторых, сама ORM нужна для чего? Чтобы можно было безболезненно менять саму type-of-database (скажем типично с MySQL на PostgreSQL). То, что вам при этом можно без любых правок менять саму ORM — никто и нигде не обещает (ибо в требования к ORM вообще ни разу не входит).

                                      P.S. Я в своих суждениях отталкиваюсь именно от интересов бизнеса, а не от академических «а что, если...». Ибо постановка ситуации мне видится притянутой за уши.
                                      • +2
                                        Да это только пример. Даже такая банальная вещь, как union, отсутствует в спецификации, и потому реализована через пень-колоду. И такая фигня везде.
                                        Ещё один пример: до сих пор в JEE нельзя универсальным способом сделать два разных метода авторизации. В одном приложении мне нужно было реализовать подключение к серверу как веб-клиентов, так и клиента 1С. 1С из коробки нормально умеет работать только с basic authentification, а вебу нужна авторизация по форме. И всё, начинается прибивание гвоздями к конкретному серверу приложений. Собственно, потому и существуют проекты вроде Спринга, создающие ещё один слой абстракции поверх/вместо существующего функционала.

                                        Что касчается притягивания за уши. Однажды при вводе небольшой системы в эксплуатацию выяснилось, что данных в одной из таблиц уже на старте будет примерно в 500 раз больше, чем планировали при постановке ТЗ. EclipseLink, на котором она была постороена, захлёбывался ещё на импорте.
                                        К счастью, поиграв с vendor-specific ключами и настройкой кэша (тоже нифига в JPA не задокументированной), удалось добиться удовлетворительной производительности, но волос с головы в предвкушении авральной миграции на Hibernate или куда-то ещё я тогда подёргал знатно. Так что кейс вполне реальный D:
                                        • 0
                                          Так что кейс вполне реальный D:

                                          чем планировали при постановке ТЗ.

                                          В моем мире это означает «раз заказчик ТЗ нарушил, то вот ему штраф, и, что еще приятней — я могу забить на сроки» — волос не теряем. К тому же, ну как-то странно, на мой взгляд гибер будет де-факто-стандарт.
                                          Впрочем то, что вы смогли решить задачу, это делает вам честь безусловно. С этим я согласен. Но бить дилдо по голове таких фруктов, что так ломают ТЗ.
                                          Что касается авторизации — а в чем проблема то сделать стандартными средствами? Ок, поясню — у нас два варианта входа (авторизации). Пишем один код для веба, другой для 1С. Далее, делаем простейшую единую и универсальную точку входа, уже внутри которой мы сможем определить каким маршрутом делать авторизацию. Это все справедливо, если тащить спринги нет желания (читаем как делаю свой детский велик).

                                          UPD: Про дилдо — если за эти безобразия клиент все же платит адекватно и понимает о сдвиге сроков, то сей агрегат будет уже излишним ;)
                                • –7
                                  Android перешел на Kotlin, это большой камень в огород Java
                                  • +9
                                    Android не «перешёл на Котлин», а теперь поддерживает ещё и Котлин.
                                    • +1
                                      Извиняюсь за неточную формулировку. Добавил поддержку, камушек в огород Java :)
                                    • +1
                                      в огород Java, которая является основой для Котлин?
                                  • 0

                                    Пытается нагнуть гуголь с его j--

                                  • +9
                                    А архитектура SPARC? Это же большой кусок истории (да и сейчас например Fujitsu делает спарки)
                                    • 0
                                      Это в Co, т.к. Solaris на x86 был, но все-таки больше для SPARC. Большой кусок истории — да, но сам Оракл не видит как это сейчас можно продавать.
                                  • +1
                                    ZFS всё?
                                    • +1

                                      Он давно развивается в рамках OpenZFS под разные популярные ОС (линукс, фряха, иллюмос)

                                      • 0

                                        Разработчики ZFS ушли в опенсорсный illumos очень скоро после закрытия OpenSolaris. Там же и развивали, а дальше код уже остальные растащили, в том числе Linux.

                                        • 0

                                          А она разве использовалась достаточно широко?
                                          С некоторых пор есть более свободная BTRFS, которая повторяет многие фичи из ZFS. Полагаю, ZFS сегодня не слишком-то нужна. Хотя году в 2009 она казалась интересной.

                                          • +2
                                            ZFS — старая проверенная ФС (в целом, линукс-реализация молода и не всё поддерживает, насколько я помню), а вот BTRFS пока еще очень молодая, все её тестируют только, а воз и ныне там.
                                            • +2
                                              Ввиду недавнего решения Red Hat будущее BTRFS уже слегка как бы под вопросом. Посмотрим. Надеюсь выживет и будет развиваться, альтернативы и здоровая конкуренция — это классно.
                                              • +2
                                                Нет. SUSE и далее продолжит развивать и поддерживать BTRFS, а решения RH ничего не решают.
                                                image
                                        • +1
                                          Zones

                                          А напомните мне пожалуйста, Sun первыми их придумали, потом оно уже перетекло в FreeBSD Jail? Гугл что то не помог
                                          • 0

                                            Скорее всего наоборот. Они развили идею BSD Jails, довели ее до завершения.

                                            • 0
                                              Никак не смог нагуглить год появления BSD Jails. Зоны в соляре появились в 2005 для Solaris 10, если верить вики.
                                              • +5
                                                В 4.0 бзде, 2000 год. ЕМНИП кто-то тогда говорил, что для добавления jail в ядро понадобилось добавить всего пару сотен строк.
                                                • 0
                                                  Спасибо
                                                  • 0
                                                    Jail во FreeBSD был в то время небольшим патчем сетевой подсистемы для функционала chroot, а chroot существовал с незапамятным времен. В то время в соляре уже был менеджер ресурсов (память, CPU) для приложений, чего в джейлах нет до сих пор. Конечно, какие-то идеи они позаимствовали из джейла, какие-то — из эмулятора (сисколлов) линукса
                                            • +1
                                              Я не пойму, Netbeans 9 выйдет, или нет?
                                              • +4
                                                Как-то так сложилось, что лично для меня Oracle — непонятная компания. Для обычного рынка у нее вообще никаких решений нет. Для крупного бизнеса у нее есть БД с заоблачными ценами, от которой все по мере возможности пытаются убежать (хоть взять Яндекс, который недавно писал, как они с Oracle переехали на PostgeSQL) и всякие большие системы управлением бизнесом, все известные мне пользователи которой плюются и матерятся. Java, SPARC, Solaris и прочее — это все-таки наследие Sun, которое Oracle успешно продолбала.

                                                Поэтому от этого Oracle лично у меня ни в голове, ни в жопе. Развались он хоть завтра, даже поностальгировать будет не о чем.
                                                • +2
                                                  У меня от них бубен клевый, орокляный!
                                                  Картинка
                                                  image
                                                  • 0
                                                    У Oracle, на мой взгляд, только один нормальный продукт — это собственно их СУБД и кластерное ПО для неё (Solaris не считаю, т.к. это их продукт, пришедший извне). Всё остальное, что доводилось администрировать, требует недюжинной выдержки и постоянного копания в десятках разрозненных конфигов и мутных мануалах.
                                                    Зато сама СУБД — космос, полностью компенсирует недостатки остального Оракловского софта. :)
                                                  • 0
                                                    Эх, поднажать бы ещё на Postgre. И забудут все про Oracle.

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.