11.09.2017 15:31
temujin 81 25300 Источник

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


Похоже, что в 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.


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


Комментарии (81)


  1. hippoage
    11.09.2017 18:50
    #10410990
    +15

    Как-то желто. Java остается, MySQL остается, VirtualBox остается, может еще что-то, особо не разбирался что входило в Sun на момент покупки. Только Solaris и Co перестают развивать, давно к этому шло, мало кто делает новые решения на базе Solaris.


    1. izzholtik
      11.09.2017 19:15
      #10411060
      -1

      А что Оракл делает для развития Java?


      1. Regis
        11.09.2017 20:51
        #10411196
        +20

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


        1. intet
          12.09.2017 09:29
          #10411712
          +1

          Сравните то, что есть/будет в java 9 и то, что уже есть в C#. Java как язык замер в развитии, и постепенно сдает позиции.


          1. zirix
            12.09.2017 12:31
            #10412032
            +6

            Одно из главных приемуществ java (для интерпрайза и для большой массы прогеров) — в язык не мусорят синтаксическим сахаром.

            Это фича, а не сдача позиций…


            1. intet
              12.09.2017 13:19
              #10412134
              +8

              В чем примущество отсуствия сахара? Зачем жертвовать удобством написания и читания кода?
              Ни в одном современном языке не приходиться писать:

              balance.setSaldoOut(balance.getSaldoIn().add(balance.getNach()).subtract(balance.getPayment()));

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


              1. zirix
                12.09.2017 14:10
                #10412220

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

                Чтобы убрать эту лапшу надо добавить operator overloading (тот самый синтаксический сахар) или добавить обработку этого типа в JVM…


                1. zirix
                  12.09.2017 14:18
                  #10412226

                  забыл про property.
                  Это одна из тех неоднозначных штук, которые не стоит тащит в java… это не только мое мнение.


                  1. DieSlogan
                    12.09.2017 17:44
                    #10412648
                    +1

                    Ну да, еще про оператор var из C# забыли. Очень удобно писать SomeBigNameOfClass result = new SomeBigNameOfClass();

                    По факту тогда, в чем смысл криков про лямбды и больше новых фич в новых версиях? Все же можно через сторонние либы сделать или, как вы сказали, добавить обработку типа в JVM.


                1. intet
                  12.09.2017 14:20
                  #10412228
                  +1

                  Только вот ни того ни другого в Java нет, а во всех современных языках есть.
                  Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set


                  1. zirix
                    12.09.2017 17:48
                    #10412660
                    -2

                    Только вот ни того ни другого в Java нет, а во всех современных языках есть.

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

                    Сахар почти всегда имеет недостатки. Он может ухудшать поддерживаемость кода или может поломать совместимость.
                    Ниже Delphinum описал одну из проблем сахара.


                    1. intet
                      12.09.2017 18:07
                      #10412694
                      +2

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

                      Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.


                      1. zirix
                        12.09.2017 18:38
                        #10412758

                        Писать код вида #define true (Math.random()>0.5) все равно не запретишь.

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

                        У меня такое было на одном проекте.


                        1. intet
                          12.09.2017 19:18
                          #10412818

                          Я понимаю, что изменить поведение "==" уже не получиться, но можно хотя бы ввести "===" на сравнение по значению. Это не ломает совместимость. В js уже так поступили.


                          1. Delphinum
                            12.09.2017 19:21
                            #10412824
                            +1

                            Не дай бог. Не нужно в Java этого костыля, пусть остается в JS.


                            1. intet
                              12.09.2017 19:26
                              #10412834

                              Костыль это Object.equals(a,b) не удобный в использованию и не работающий к тому же для чисел.


                              1. Delphinum
                                12.09.2017 19:34
                                #10412846

                                Метод в объектно-ориентированном языке не может быть костылем по определению ) Вот === вполне. И ради чего, чтоб Java был больше похож на JS? Да сами JS разработчики не в восторге от ==/===, а вы предлагаете его еще и перенести в язык без этого костыля. Не нужно.


                                1. intet
                                  12.09.2017 20:25
                                  #10412916

                                  В js используется == в java же он очень редкий зверь годный только для примитивов. Единообразие в синтаксисе сильно повысит читаемость. А предупреждения при компиляции помогут избегать ошибок. Можно же попросить явно аннотировать места где используется именно сравнение по ссылке.


                                  1. speller
                                    14.09.2017 03:42
                                    #10415354

                                    Мне лично кажется, что при соревнованиях между скоростью разработки и православностью синтаксиса в долгосрочной перспективе при прочих равных всегда выигрывает скорость разработки. Поэтому лично мне кажется, что упарываться чистотой белой расы синтаксиса — это путь в никуда.


              1. Delphinum
                12.09.2017 15:24
                #10412346
                +1

                Почему вы пытаетесь использовать объектно-ориентурованную Java как процедурный ЯП? По хорошему, ваш пример на Java должен выглядеть так:

                balance.recountSaldoOut();

                и реализовываться так:
                public recountSaldoOut(){
  saldoOut = saldoIn + nach - payment;
}


                1. intet
                  12.09.2017 16:00
                  #10412422

                  Так писать на Java не получиться. Максимум выйдет следующее

                  public recountSaldoOut(){
	saldoOut = saldoIn.add(nach).subtract(payment);
}

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


                  1. Delphinum
                    12.09.2017 16:13
                    #10412468

                    Так писать на Java не получиться

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

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

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


                  1. Crandel
                    12.09.2017 16:17
                    #10412474
                    -2

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


                    class Balance {
  private double saldoOut;
  private double saldoIn;
  private double nach;
  private double payment;

  public void recountSaldoOut(){
    saldoOut = saldoIn + nach - payment;
  }
}


                    1. intet
                      12.09.2017 16:55
                      #10412544
                      +1

                      double для финасовых приложений не пригоден. Везде надо использовать BigDecimal, чтобы хотя бы сложение/вычитание работало с абсолютной точностью. Класс же BigDecimal использовать для арифметики не удобно. Простое сравнение с нулем выглядит так

                      public boolean isZero(BigDecimal val) {
        return BigDecimal.ZERO.compareTo(val) == 0;
}


                      1. Crandel
                        12.09.2017 18:10
                        #10412700

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


                        1. intet
                          12.09.2017 18:15
                          #10412718

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


                          1. Crandel
                            12.09.2017 18:17
                            #10412724

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


                            1. intet
                              12.09.2017 18:29
                              #10412738

                              Ксчастью вам не приходилось постоянно ковыряться в многостраничных текстах арифмитических операций, которые трудно читаемых в любых случаях чуть более отличных от тривиальных.


                      1. Menesty
                        15.09.2017 07:46
                        #10416952

                        На самом деле, можна записать ваш код короче, использовав метод signum()
                        return val.signum() ==0;


                1. Kaiser
                  12.09.2017 16:11
                  #10412460

                  Соглашусь на 80%

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

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


                  1. Delphinum
                    12.09.2017 16:19
                    #10412482
                    -1

                    Но syntax sugar все же удобен

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

                    Это особенно заметно в проектах, без стандартизации формата кода и с большим числом разработчиков. Кодовая база быстро делится на блоки, с которыми работают только те разработчики, которые знакомы с используемым в этом блоке «сахаром». На практике это выглядит примерно так: «в проект пришел джун, запилил реализацию на каком нибудь модном сахаре, после чего покинул проект, и реализацию либо переписали, либо все бояться ее трогать».


                    1. intet
                      12.09.2017 17:04
                      #10412552
                      +5

                      На изучение возможностей сахара требуется ничтожное количество времени. Вот чтобы изучить, сконфигурировать и настроить простейший сервер, требуется на порядки больше времени и усилий, чем на изучения скажем множественного возврата.


                      1. Delphinum
                        12.09.2017 17:11
                        #10412576
                        -1

                        Это от человека зависит, сколько ему времени требуется для изучения сахара, а если это группа человек, то времени требуется еще больше, и все для того, чтобы джуниор мог попробовать в проекте новый «сахар». Такая себе плата за «сахар», заменяющий add() на +


                        1. intet
                          12.09.2017 17:18
                          #10412594
                          +2

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

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


                          1. Delphinum
                            12.09.2017 17:25
                            #10412604
                            -1

                            На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени

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

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

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


                            1. intet
                              12.09.2017 17:29
                              #10412610
                              +1

                              Вся боль, что так как Java это в первую очередь финансовые системы, а все расчеты для них ведутся через стандартный BigDecimal. Работать с остальными примитивами нельзя.
                              А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.


                              1. Delphinum
                                12.09.2017 17:35
                                #10412636
                                +1

                                Потому я вам сразу и сказал: работая с объектно-ориентированным языком, придерживайтесь объектно-ориентированной нотации. Математические операторы это не объектно-ориентированная нотация, потому ее и нет в Java.


                                1. DieSlogan
                                  12.09.2017 17:49
                                  #10412664

                                  А аттрибуты?


                                  1. Delphinum
                                    12.09.2017 18:07
                                    #10412696

                                    Что «аттрибуты»?


                                    1. DieSlogan
                                      12.09.2017 18:30
                                      #10412740

                                      Аттрибуты вписываются в концепцию объектно-ориентированная нотации?


                                      1. Delphinum
                                        12.09.2017 18:46
                                        #10412770

                                        Если они инкапсулированы. По сути, атрибуты (я предпочитаю термин — свойства) не видны снаружи, потому их семантически не существует, вы оперируете объектами и методами, а не переменными, данными и операциями над ними. В этом и отличие объектной нотации от процедурной.


                                        1. DieSlogan
                                          12.09.2017 21:22
                                          #10412960

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


                                          1. Delphinum
                                            13.09.2017 02:22
                                            #10413198

                                            Вы под атрибутом понимаете «аннотацию» или «метаданные»? Если так, то это уже не объектно-ориентированная нотация, а декларативная.


                                1. intet
                                  12.09.2017 18:10
                                  #10412704

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


                                  1. Delphinum
                                    12.09.2017 18:53
                                    #10412782

                                    Почему вы решили, что если у другого ЯПа непривычный для вас дизайн, то это плохой дизайн? Вы давно занимаетесь разработкой? Вы знакомы более чем с 1 ЯПом?

                                    Если вы привыкли к математическим операторам и процедурному подходу, возможно вам стоит использовать язык, который под это лучше заточен, а не Java, которая является объектно-ориентированным языком.


                                    1. intet
                                      12.09.2017 19:24
                                      #10412828

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


                                      1. Delphinum
                                        12.09.2017 19:27
                                        #10412836

                                        К сожалению просто поменять язык сервера нельзя.

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

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

                                        Тоже задаюсь этим вопросом.


                          1. Ndochp
                            12.09.2017 18:59
                            #10412784

                            Для стринга же определили ;)


            1. poxvuibr
              13.09.2017 13:52
              #10414066

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


        1. izzholtik
          12.09.2017 09:46
          #10411728

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


          1. Crandel
            12.09.2017 10:17
            #10411780

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


            1. izzholtik
              12.09.2017 12:41
              #10412052
              +2

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

              А вообще складывается такое чувство что Oracle уже устал от java и хочет потихоньку вытолкнуть его полностью на плечи сообщества, нагнуть гугл на отчисления не вышло вот наверное и думают как аккуратно сбагрить все это добро.


          1. Skerrigan
            12.09.2017 10:17
            #10411782
            +1

            Того же JPA несчастного

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


            1. izzholtik
              12.09.2017 10:44
              #10411842

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


              1. Skerrigan
                12.09.2017 11:42
                #10411908

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

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

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

                P.S. Я в своих суждениях отталкиваюсь именно от интересов бизнеса, а не от академических «а что, если...». Ибо постановка ситуации мне видится притянутой за уши.


                1. izzholtik
                  12.09.2017 12:27
                  #10412022
                  +2

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

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


                  1. Skerrigan
                    13.09.2017 05:55
                    #10413276

                    Так что кейс вполне реальный D:

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

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

                    UPD: Про дилдо — если за эти безобразия клиент все же платит адекватно и понимает о сдвиге сроков, то сей агрегат будет уже излишним ;)


        1. ninJo
          12.09.2017 11:59
          #10411934
          -7

          Android перешел на Kotlin, это большой камень в огород Java


          1. siziyman
            12.09.2017 12:08
            #10411966
            +9

            Android не «перешёл на Котлин», а теперь поддерживает ещё и Котлин.


            1. ninJo
              12.09.2017 16:21
              #10412490
              +1

              Извиняюсь за неточную формулировку. Добавил поддержку, камушек в огород Java :)


          1. x67
            12.09.2017 17:47
            #10412656
            +1

            в огород Java, которая является основой для Котлин?


      1. september669
        12.09.2017 15:25
        #10412354

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


    1. YuriPanchul
      11.09.2017 19:27
      #10411088
      +9

      А архитектура SPARC? Это же большой кусок истории (да и сейчас например Fujitsu делает спарки)


      1. hippoage
        11.09.2017 22:27
        #10411312

        Это в Co, т.к. Solaris на x86 был, но все-таки больше для SPARC. Большой кусок истории — да, но сам Оракл не видит как это сейчас можно продавать.


  1. alexyr
    11.09.2017 18:52
    #10410998
    +1

    ZFS всё?


    1. blind_oracle
      11.09.2017 18:56
      #10411018
      +1

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


    1. temujin Автор
      11.09.2017 18:59
      #10411030

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


    1. Akon32
      11.09.2017 19:08
      #10411046

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


      1. ProFfeSsoRr
        11.09.2017 19:44
        #10411102
        +2

        ZFS — старая проверенная ФС (в целом, линукс-реализация молода и не всё поддерживает, насколько я помню), а вот BTRFS пока еще очень молодая, все её тестируют только, а воз и ныне там.


        1. johnnymmc
          12.09.2017 02:46
          #10411546
          +2

          Ввиду недавнего решения Red Hat будущее BTRFS уже слегка как бы под вопросом. Посмотрим. Надеюсь выживет и будет развиваться, альтернативы и здоровая конкуренция — это классно.


          1. mrobespierre
            12.09.2017 03:53
            #10411564
            +2

            Нет. SUSE и далее продолжит развивать и поддерживать BTRFS, а решения RH ничего не решают.
            image


  1. KorP
    11.09.2017 19:59
    #10411132
    +1

    Zones

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


    1. temujin Автор
      11.09.2017 20:01
      #10411144

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


      1. KorP
        11.09.2017 20:03
        #10411148

        Никак не смог нагуглить год появления BSD Jails. Зоны в соляре появились в 2005 для Solaris 10, если верить вики.


        1. NoRegrets
          11.09.2017 23:38
          #10411402
          +5

          В 4.0 бзде, 2000 год. ЕМНИП кто-то тогда говорил, что для добавления jail в ядро понадобилось добавить всего пару сотен строк.


          1. KorP
            12.09.2017 07:05
            #10411600

            Спасибо


          1. BasilioCat
            12.09.2017 13:24
            #10412142

            Jail во FreeBSD был в то время небольшим патчем сетевой подсистемы для функционала chroot, а chroot существовал с незапамятным времен. В то время в соляре уже был менеджер ресурсов (память, CPU) для приложений, чего в джейлах нет до сих пор. Конечно, какие-то идеи они позаимствовали из джейла, какие-то — из эмулятора (сисколлов) линукса


  1. Fragster
    12.09.2017 16:41
    #10412524
    +1

    Я не пойму, Netbeans 9 выйдет, или нет?


  1. oYASo
    12.09.2017 16:49
    #10412530
    +4

    Как-то так сложилось, что лично для меня Oracle — непонятная компания. Для обычного рынка у нее вообще никаких решений нет. Для крупного бизнеса у нее есть БД с заоблачными ценами, от которой все по мере возможности пытаются убежать (хоть взять Яндекс, который недавно писал, как они с Oracle переехали на PostgeSQL) и всякие большие системы управлением бизнесом, все известные мне пользователи которой плюются и матерятся. Java, SPARC, Solaris и прочее — это все-таки наследие Sun, которое Oracle успешно продолбала.

    Поэтому от этого Oracle лично у меня ни в голове, ни в жопе. Развались он хоть завтра, даже поностальгировать будет не о чем.


    1. Skerrigan
      13.09.2017 06:21
      #10413284
      +2

      У меня от них бубен клевый, орокляный!

      Картинка
      image


    1. Cubus
      13.09.2017 11:02
      #10413568

      У Oracle, на мой взгляд, только один нормальный продукт — это собственно их СУБД и кластерное ПО для неё (Solaris не считаю, т.к. это их продукт, пришедший извне). Всё остальное, что доводилось администрировать, требует недюжинной выдержки и постоянного копания в десятках разрозненных конфигов и мутных мануалах.
      Зато сама СУБД — космос, полностью компенсирует недостатки остального Оракловского софта. :)