MAX
Подпишись
стань автором. присоединяйся к сообществу!
15 ноября 49
174

Фото дня! Первая инженерная партия «Эльбрус-8С» и южного моста «КПИ-2» готовы к тестированию!

8-ядерный микропроцессор «Эльбрус-8С» создан компанией «МЦСТ» по технологическому процессу 28-нм. Он содержит 8 универсальных процессорных ядер с архитектурой «Эльбрус» третьего поколения. Кажде ядро располагает кэш-памятью 2 уровня 512 Кб. Кэш-память 3 уровня 16 Мб является общей для всех ядер. Микропроцессор содержит встроенный 4-канальный контроллер памяти типа DDR3−1600. 3 высокоскоростных дуплексных каналов LVDS с пропускной способностью 8 Гб/сек в каждую сторону для организации 4-процессорных систем на одной материнской плате. Частота микропроцессора 1,3 ГГц. Производительность 249,6 Гфлопс на 32-разрядных числах с плавающей точкой. Микропроцессор совместим с новым южным мостом «КПИ-2»

[читать статью полностью...]

Кстати, а вы знали, что на «Сделано у нас» статьи публикуют посетители, такие же как и вы? И никакой премодерации, согласований и разрешений! Любой может добавить новость. А лучшие попадут в наш Телеграм @sdelanounas_ru. Подробнее о том как работает наш сайт здесь👈

Источник: mcst.ru

Комментарии 0

Для комментирования необходимо войти на сайт

  • -3
    Ruslan Ruslan15.11.14 12:10:58

    Круто, конечно, но тестировать надо, а ещё к Linux-приложениям приучивать народ. Опять же, частый сектор упрётся.

    • 12
      Нет аватара kerosene15.11.14 12:16:59

      В режиме полной динамической трансляции кодов x86, Эльбрус для пользователя неотличим от компьютеров с процессорами Интел и АМД. Просто ставим Windows и софт под нее и работаем.

      • 4
        Ruslan Ruslan15.11.14 12:19:45

        Тогда вообще божественно.

        • 3
          Нет аватара guest15.11.14 13:10:07

          Некоторая потеря производительности, конечно, есть, процентов 30−50 на сравнимых частотах. Которые и так-то не высоки — почему, собственно, все так на линупс щас и упирают: в нативном коде удельная производительность на мегагерц и на потреблённый ватт у Эльбрусов замечательно хороша.

          • 0
            Forester Forester15.11.14 14:38:11

            про частоту говоря о скорости процессора сейчас вообще говорить не стоит. На моем ноутбуке, что брал месяц назад за 9 тысяч, процессор Intel Celeron с частотой 2,16 гигарца, а работает в несколько раз медленней чем core duo 5 летней давности с частотой 1,8 гигагерца

            Отредактировано: Forester~15:40 15.11.14
            • 3
              Нет аватара guest15.11.14 15:11:16

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

            • 0
              Нет аватара IS16.11.14 06:04:25

              Гмм… современные целероны уже года два как слегка обгоняют Сore 2 Duo на тех же частотах (более того тот же Celeron G1820 на своих 2.9Ghz слегка делает Core 2 Duo E8600 с его 3.3Ghz, гляньте тесты в реальных приложениях на том же Tom’s Hardware), другой вопрос, что на производительность системы еще много чего влияет и вероятно в вашем ноуте очень посредственная видеокарта, при его то цене, не самый быстрый винт и т. д. и оно может добавлять тормозов куда больше, чем собственно влияние процессора, особенно, если оперативки маловато да еще и встроенное видео ее под себя дополнительно сжирает.

              PS

              У самого до сих пор есть старый комп на самом навороченном из выпущенных Core 2 Duo E8600, который на данный момент больше используется в качестве медиакомбайна, так что есть с чем сравнивать в живую.; ) Таки целероны используют забракованные кристалы обрезки от старших моделей, а архитектура последних достаточно далеко ушла со времен Core 2 Duo.: )

              Отредактировано: IS~07:13 16.11.14
          • 1
            Нет аватара guest15.11.14 18:05:02

            Тут есть одна маленькая проблемка — VLIW хорош в некотором классе вычислений, но при этом он очень плохо себя показывает в исполнении неоптимизированного под него кода. Банально особенность архитектуры. Поэтому представители оной в основном осели в DSP и всяких там видеокартах (Radenon HD6000 были на нем, например, но потом ушли в сторону своих разработок). Поэтому в повседневных задачах VLIW будет даже без эмуляции хуже чем x86 или ARM в рассчете на 1МГц частоты (и 1 ядро), зато да, в числодробилках будет показывать себя намного лучше (в рассчете на 1МГц частоты и одно ядро конечно). Только такие задачи это редкость.

            • 12
              Нет аватара guest15.11.14 18:23:13

              Там всё несколько сложнее. Фишка в том, что у МЦСТ, судя по всему, таки получилось то, что в своё время не вышло у Интела — разработать нормальный оптимизирующий компилятор, оптимально набивающий инструкциями ШКС. В первых версиях интеловских компиляторов до 80% ШКС составляли тупо НОПы, потому что компилятор не умел в разрешение зависимостей в коде, и именно поэтому Итаниум-1 в нативном режиме работал как в лучшем случае как Пентиум-3, а в режиме эмуляции х86 — и вовсе как 486-й. Только к Итаниуму-2, заглотив персонал Трансметы, у них получилось добиться более-менее нормальной производительности, но поезд уже ушёл.

              Кстати, всё вами сказанное совершенно справедливо и для современных суперскаляров, которые все out-of-order, то есть по факту тоже имеют как бы виртуальное широкое командное слово — просто оно нигде реально не фигурирует, а представляет собой поток внутренних микрокоманд, генерируемых декодером, блоком предсказаний ветвлений, переименовщиком регистров и прочими устройствами, занимающими в современных процессорах до 60−70% площади кристалла. Переложив их функции на компилятор, в МЦСТ просто выкинули всю эту дребедень с кристалла, значительно сократив его энергопотребление и повысив утилизацию такта.

              И именно за счёт этого у Эльбрусов настолько высока энергоэффективность и производительность на такт в нативном коде — по ощущениям от реальной работы, 500-МГц машина пахала на уровне как минимум втрое-четверо раз более быстрого по гольной частоте i3. Так что всё упирается в компилятор — если все реально так хорошо, как нам рассказывают, то можно пить шампанское ;)

              • 0
                Нет аватара guest15.11.14 19:08:58

                Я, понятное дело, живых Эльбрусов не видел, но когда учился в ВУЗе, к нам ребята из МЦСТ приходили, агитировать идти к себе на диплом, ориентируюсь только на то, что они сами говорили.

                Про OoO и прочее — да, это все понятно. Проблема в создании эффективного компилятора, который сможет генерировать код, из-за которого не будет часто сбрасываться конвеер. Для сложной математики или каких-то предсказуемых вещей это очень просто, а вот для софта общего назначения — архисложно. Тем более свой компилятор это тоже мягко говоря не очень то и плюс, если бы все это было в виде порта gcc или порта llvm — это одно, но МЦСТ не очень хочет показывать свое творение и периодически утверждает что они делали компилятор с нуля — значит что понимание стандартов языков там свое, поддержка языков также ограничена небольшим их набором (и небольшим набором версий стандартов) и так далее. Это тоже не пойдет на пользу процессору.

                • 1
                  Нет аватара guest15.11.14 19:40:46

                  Ещё в прошлом году на ЛОРе были люди, которые крутили в руках первые версии чипа и компиляторы к ним. По их словам компиляторы собственной разработки, но 100% совместимы с gcc, правда не самых свежих версий.

                  • 0
                    Нет аватара guest15.11.14 20:06:18

                    Я в «собственной разработки, но совместим с gcc» не верю честно говоря. Т.к. это или backend для gcc или он не совместим на 100%. В ГЦЦ слишком много специфичных расширений, трактовок, багофич и так далее, чтобы это реально было сделать.

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

                    • 0
                      Нет аватара guest16.11.14 05:30:43

                      Если у них пингвин собирается из непиленых исходников (кроме библиотеки реального времени и немножко ядра), то компилятор (да и весь тулчейн, тащемта) таки обязан быть совместим с гцц, нес па? ;) Конечно, можно быть уверенным, что он поддерживает далеко не все возможности, но саморазворот системы он обеспечивает, кросскомпиляция, по слухам, не нужна.

                      • 0
                        Нет аватара guest16.11.14 05:47:18

                        Про «непиленные» исходники я не слышал честно говоря ничего, поэтому не скажу ничего. Пусть исходники покажут, тогда и будет видно насколько они «непиленные». Ядро то точно свое, в апстриме нет поддержки Эльбруса.

                        Чем более тулчейн будет совместим с гцц, тем больше непатченного софта будет собираться и тем меньше новых уникальных косяков встретится. Одно дело, когда поддерживается сборка всех пакетов дебиана (помоему их колличество уже приближается к 100 тысячам штук), другое когда только базовая система и пара программ сверху. К тому же у gcc достаточно неплохой оптимизатор кода, чтобы его повторить или превзойти нужны многие годы разработки.

                        • 1
                          Нет аватара guest16.11.14 07:33:51

                          Проблема только в том, что и кодогенератор, и оптимизатор gcc все эти годы пилились в первую очередь под х86 и олдскульные RISC’и, что такое широкое командное слово и с чем его едят они понятия не имеют. Главное ноу-хау МЦСТ — как раз в разработке технологии выявления и разделения потоков управления и данных в AST, что позволяет вычленять независимые друг от друга сегменты кода и разбрасывать их по разным исполняющим устройствам. Плюс разные аппаратные вкусности, рассчитанные на более эффективное исполнение кода высокого уровня: аппаратная поддержка контекстов исполнения (там есть регистры дескрипторов задач, например), регистровый файл совмещённый со стеком и оборудованный аппаратной защитой контекстов, ассоциативный кэш первого уровня, в который вылезают хвосты регистровых файлов задач, аппаратная подкачка массивов, модуль обработки циклов и прочая. ГЦЦ всего этого просто не понимает, единственное что он умеет — это распознавать кодовые паттерны в AST и ляпать вместо них бинарные патчи из базы. ;)

                          • 0
                            Нет аватара guest16.11.14 11:59:46

                            У GCC есть несколько стадий оптимизации и в целом интересна кодогенерация. Я думаю не надо напоминать, что большая часть оптимизаций является архитектуронезависимой? Они могли бы вполне написать хороший backend для своей архитектуры для gcc и получить все плюшки оптимизации кода. Аппаратным фишкам как раз и можно научить на этапе написания backend’а.

                            Отредактировано: Vladimir Smirnov~13:01 16.11.14
                            • 0
                              Нет аватара guest16.11.14 12:17:59

                              Вы не читали МЦСТшную книжку про их архитектуру? У меня большое сомнение, что банальный бэк-энд справится с тамошними архитектурными различиями, там по-хорошему полноценный новый кодогенератор и оптимизатор нужны. В первую очередь потому, что структура оптимизации нужна совершенно иная — нужно, например, перетасовывать инструкции не так, чтобы на них не спотыкался предсказатель ветвлений (которого в процессоре просто нет), а так, чтобы они не ожидали результата друг друга и их можно было распихать в потоки разных исполняющих устройств. А перед самой инструкцией ветвления нужно воткнуть инструкции преподкачки кода и данных для обеих ветвей — у Эльбруса раздельные кэши 1-го и 2-го уровней для кода и данных, общий — только 3-го уровня: он, строго говоря, вообще гарвардский, а не фон-Неймановский внутри. И так далее…

                              • 0
                                Нет аватара guest16.11.14 18:43:05

                                К сожалению не читал.

                                Опять же, у GCC есть разного типа оптимизации. И довольно значительная часть — не зависит от архитектур, т.к. банально уменьшает колличество результирующего кода.

                                В любом случаи, пока простые люди вроде меня не могут себе приобрести компьютер на базе Эльбруса и пока исходники GPL софта не выложены — можно только догадываться о том, что они сделали с компилятором и как. Просто есть некоторая вероятность, что они могли взять GPLый софт и выдать за свое (военным так вообще в целом безразлично GPL или не GPL).

                                • 0
                                  Нет аватара guest17.11.14 03:01:20

                                  А вы почитайте, она у них на сайте свободно лежит. Это ОЧЕНЬ своеобразное и интересное устройство, к которому готовые рецепты просто неприменимы.

                                  • 0
                                    Нет аватара guest17.11.14 11:52:50

                                    Да, спасибо, почитаю.

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

                                    И я еще раз повторю — что пока нет общедоступных железок за вменяемые деньги и пока МЦСТ не выложит исходники GPL кода, в целом бесполезно гадать использовали ли они ГЦЦ и просто наплевали на GPL или правда сделали свое, а если сделали, то каков его уровень совместимости с GCC.

                                • 0
                                  RadiantConfessor RadiantConfessor20.11.14 00:22:33

                                  Они не могли взять GPL и выдать за свой. Архитектура не позволит.

                                  • 0
                                    Нет аватара guest20.11.14 01:05:47

                                    Почему не позволит? Написать кодогенератор, а frontend взять от gcc.

                                    • 0
                                      RadiantConfessor RadiantConfessor20.11.14 02:59:17

                                      1. VLIW в Эльбрусе позволяет выполнять 21 команду за такт, а это значит можно сразу несколько С++ команд организовать в одной машинной команде. Тут нужно не каждую отдельную команду С++ преобразовывать в машинный код, а целые блоки.

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

                                      • 0
                                        Нет аватара guest20.11.14 03:29:37

                                        Не могу не вмешаться в вашу беседу.

                                        Ого! Не знал. Вообще не думал, что так возможно. Это получается, что если компилятор ошибся, то код получается чуть менее оптимальный и при желании можно сделать красную кнопку «доработать человеком»?

                                        • 0
                                          RadiantConfessor RadiantConfessor20.11.14 03:31:37

                                          По этому его и назвали, Суперкомпилятор.

                                          На самом деле ошибается и аппаратный предсказатель ветвлений. Когда он ошибается приходится заполнять кэш новыми данными из относительно медленной памяти.

                                          • 0
                                            Нет аватара guest20.11.14 07:15:09

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

                                      • 0
                                        Нет аватара guest20.11.14 08:55:40

                                        И еще раз, ну позволяет, и что? Конкретно в gcc (впрочем в clang’е тоже что-то похожее) код на языке высокого уровня преобразуется сначала в промежуточное представление на RTL, а затем уже из rtl генерируется машинный код. Кто мешает, каким бы особенным ни был VLIW, взять уже готовую часть трансляции в RTL + все оптимизации (т.е. взять frontend часть от gcc) и написать свой RTL -> VLIW (т.е. бэкэнд для гцц)? Пока кроме «он не такой как все» не было названо ни одной причины. GCC умеет достаточно большое колличество архитектур, притом с ходу нашлась поддержка 4-х VLIW архитектур, не считая DSPшек. Я еще раз повторю, что не вижу пока в этих двух пунктах никаких причин чтобы не взять примерно 2/3 от gcc и дописать 1/3 самостоятельно. Как бонус автоматически получается использование всех поддерживаемых в gcc языков и большая часть оптимизаций, которые идут на уровнях до RTL включительно.

                                        P. S. Да и как бы сейчас абсолютно все процессоры умеют выполнять куда более одной команды за такт. Конечно не 21, но все же. И более того, под каждый процессор нужно знать особенности его работы (как работает предсказатель ветвлений и т. п., на каждую интеловскую микроархитектуру существуют многостраничные гайдлайны по тому какой код эффективнее будет работать), чтобы генерировать эффективный ассемблерный код.

                                        Отредактировано: Vladimir Smirnov~10:03 20.11.14
                                        • 0
                                          RadiantConfessor RadiantConfessor20.11.14 09:00:42

                                          А графы по вашему кто строит?

                                          • 0
                                            Нет аватара guest20.11.14 09:03:51

                                            А кто мешает это делать backend’у, транслирующему RTL в машинный код?

                                            • 0
                                              RadiantConfessor RadiantConfessor20.11.14 10:41:32

                                              Наверное, вы хотели сказать, должно быть что-то между RTL и backend`ом?

                                              • 0
                                                Нет аватара guest20.11.14 10:46:31

                                                Да не принципиально как это воспринимать. Никто не мешает из RTL’я иметь свой собственный генератор, который бы делал практически любую магию, а на выходе выдавал уже готовый код. Для краткости проще это все назвать backend’ом (что может быть и не совсем корректно с формальной точки зрения).

                                                • 0
                                                  RadiantConfessor RadiantConfessor20.11.14 11:10:11

                                                  Тогда bakend будет составлять самую сложную и большую часть gcc.

                                                  • 0
                                                    Нет аватара guest20.11.14 11:19:23

                                                    А это не такой простой вопрос. Бэкэнд сложный всегда, да. Но это позволяет использовать уже готовую инфраструктуру и автоматом получить поддержку всех языков, которые поддерживает gcc (я только по памяти могу вспомнить порядка 12, не считая разных их стандартов). Согласитесь, что реализовать поддержку хотя бы C (ANSI, 89, 99, 14), C++ (c98, 2011, 2014) и fortran (77, 90, 95, 2003, 2008) это уже не очень простая задача. А потом вспомните, что таких языков не 3 как я перечислил, а не менее 12. И опять же, у гцц есть какой-никакой оптимизатор работающий на уровне RTL и позволяющий хотя бы слегка минимифицировать код. Делая свой компилятор с нуля нужно будет все это реализовывать с нуля, а чтобы собрать ядро линукса, оное надо будет или патчить или в компиляторе реализовывать поддержку GNU-расширений хотя бы для C. Вон Clang пытается протолкнуть патчи для сборки ядра (как в себя, так и в ядро) уже не первый год и пока mainline clang не может собрать mainline ядро целиком даже на x86.

                                                    • 0
                                                      RadiantConfessor RadiantConfessor21.11.14 14:23:49

                                                      Как сказали специалисты МЦСТ у них не gcc. Когда-то у них был купленный gcc, но они от него полностью отказались. Текущий компилятор написан ими полностью с нуля, самостоятельно. Компилятор поддерживает форматы gcc.

                                                      • 0
                                                        Нет аватара guest21.11.14 14:29:43

                                                        Фраза очень клево звучит, учитывая что gcc — GPLv3 софт. Я не нашел, к слову, как купить gcc. Вот совсем. Для ARM есть платные сборки от некоторых компаний (в комплекте с IDE), но не более того.

                                                        Если написан полностью с нуля — это печально по причине поддержки стандартов. То, что умеет gcc в плане языков и стандартов, они своими силами будут пилить очень и очень долго. А это значит, что использование в домашней-корпоративной среде плат на Эльбрусе будет очень затруднено дополнительными несовместимостями компилятора. Если они заявляют что умеют все то же, что и гцц, то скорее всего или врут в этом месте или врут что не использовали код из гцц.

                                                        • 0
                                                          RadiantConfessor RadiantConfessor21.11.14 14:51:04

                                                          Нет там ничего печального. Их компилятор полностью совместим по форматам с gcc. По этому у них есть и С, С++ и Fortran`ы.

                                                          Лучше поговорите сами с КТ вот здесь

                                                           http://forum.ixbt.com/top...c.cgi?id=8:24645−82 

                                                          Отредактировано: Zveruga~15:53 21.11.14
                                                          • 0
                                                            Нет аватара guest21.11.14 15:13:43

                                                            За ветку спасибо. Хотя читать 80 страниц честно говоря сильно влом, а по последним 5-и страницам понять что у них на самом деле реализовано и как — не получилось. Есть фразы про «мы написали компилятор с нуля», потом есть оговорки «кроме фронтэнда», а что как фронтэнд использовалось — не очень понятно, на этот вопрос ничего кроме «почитайте тему с начала, там есть ответ» нету.

                                                            У вас кстати терминология слегка прихрамывает. Не по форматам, а по расширениям (точнее в той же теме сказано про макросы и препроцессор, про остальное тоже ни слова). Вопрос еще в том, как оно понимает стандарты, насколько точно реализует внутренние структуры гцц (есть некоторый высокопроизводительный софт, который позволяет себе подхачивать внутренности libgcc в рантайме, понятное дело не с помощью gcc оно не собирается).

                                                            Так что я все равно скептически отношусь, т.к. раз «свое» значит будут проблемы со стандартами и gcc-специфичными расширениями.

                                                            • 0
                                                              RadiantConfessor RadiantConfessor21.11.14 15:49:09

                                                              Давайте уж лучше там продолжим эти беседы.

                                                              И эта тема не на 80 страниц, эта тема уже переоткрывалась не менее 5 раз.    

                                        • 0
                                          Нет аватара guest20.11.14 09:16:25

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

                                          А разве они не в конвейере одна за другой стоят?

                                          • 0
                                            Нет аватара guest20.11.14 10:56:19

                                            К сожалению, проще послать в обзорные материалы по конкретной микроархитектуре, чем устраивать пересказ. Например по Intel’овским Haswell’ам начиная с Frontend’а и далее ([ссылки отключены] и далее или [ссылки отключены] или искать соответствующего класса обзоры по конкретно интересующим микроархитектурам (к сожалению, по тем же ARM или Power это не всегда просто сделать).

                                            • 0
                                              Нет аватара guest20.11.14 11:06:50

                                              У Вас ссылки ортключены))))

                                              От себя скажу, что когда конвейеры изучал, было всегда только последовательное выполнение команд. При чём код надо было как-то оптимизировать так, что-бы многотактные команды так или иначе совпадали с остальными, что-бы конвейер на долго не тормозился. Да, конвейеров могло быть несколько, но в каждом всё шло по цепочке. Мне казалось, что интеловцы уже не отойдут от этой архитектуры

                • 2
                  RadiantConfessor RadiantConfessor15.11.14 19:46:25

                  Специалисты говорят, что МЦСТ создали суперкомпилятор, в создание которого многие не верили.

    • 6
      shigorin shigorin15.11.14 13:38:48

      Частный сектор с мозгами давно уже помаленьку щупает линукс -- я полтора десятка лет тому перебрался и на винду меня калачом не заманишь, например.

      Про «тестировать надо» мысль вроде бы хорошая, только немножко не сочетается с апологией wintel…

      --

      Michael Shigorin

      • 0
        Ruslan Ruslan15.11.14 13:53:44

        Я в курсе, но там не ALT Linux распространён, а RH или Ubuntu чаще всего. И то вместе с Windows Server. А уж на десктопе Linux только у админа можно встретить и то не всегда.

        • 2
          shigorin shigorin15.11.14 15:34:25

          Крупно ошибаетесь. А на альте выполнено, похоже, самое крупное гос/корпоративное внедрение линукса в Европе.

          --

          Michael Shigorin

          • 1
            Ruslan Ruslan15.11.14 15:38:16

            Да-да, я слышал, как внедряют Linux в Мюнхене.    

            А про ALT наслышан аж от самих врачей и интеграторов. Без обид, но до Ubuntu вам далеко.    

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

            • 1
              shigorin shigorin15.11.14 19:25:48

              Вы слышали, а я своими руками перетаскивал с коллегами одну лавку по всей тогда ещё Украине (чуть позже строили «Ломоносов» в МГУ, но это и не миграция). Возможно, мы что-то понимаем лучше немцев, потому как переезд был стратегически успешен.

              Вы наслышаны? Так расскажите же, без обид :-) Так-то про КРОК вместе с его облаком и одного «сэра» я и сам много чего могу рассказать, да только никому от этого лучше не станет.

              Подрастёте до понимания того, что есть фора и где она какая -- тогда давайте и продолжим.

              Удачи.

              --

              Michael Shigorin

              • 0
                Ruslan Ruslan15.11.14 20:17:04

                Повторюсь, Ваше решение -- всего лишь фора от правительства. И от него, как чёрт от Ладана, шарахаются все. Что в школах, что поликлиниках устали уже от «вечно неработающих» нововведений.    

                А на Украине и своих энтузиастов хватает. Одно время активно переписывался с Игорем Новиковым, который собрал команду, создающую совместимый с CorelDraw редактор векторной графики sk1. Долго тянули, релиз не выкатили, и программа была в статусе вечной альфы.

                «Ломоносов», вроде как, «Т-Платформы» делали, а не ALT Linux, не?

                Про КРОК весёлого и я могу рассказать.     Правда, про «облако» ничего не скажу, так как ушёл оттуда раньше его запуска.

                • 1
                  shigorin shigorin15.11.14 22:52:48

                  Повторюсь, Вы полностью некомпетентны в вопросе, если берётесь рассуждать в терминах «форы» по этим внедрениям.

                  Школьная история с рейдерством Реймана-Комиссарова особенно показательна -- там в итоге выкатывала свежесляпанная левая лавка (pingwinsoft), разумеется, опозорились по полной программе, подставили всех, кого могли, и угробили кучу нервов учителям.

                  Игоря давно знаю живьём, он на наши конференции приезжал.

                  «Ломоносов» делали ТП (железо) и Massive Solutions (софт), ОС была основана на ALT Linux и основательно доработана под задачу (благо дистрибутив инструментальный и хорошо этому поддаётся).

                  Не знаете -- сойдите за умного.

                  --

                  Michael Shigorin

                  • 1
                    Ruslan Ruslan16.11.14 00:30:27

                    Ну, раз Вы претендуете на компетентность, то ссылочка есть у меня:

                     http://www.osp.ru/os/2012/07/13017641/ 

                    Знаете, я вот сам помню, что говорили, за основу взята CentOS (она же -- форк RHEL). На счёт железа рад, что наги делали, но там есть и то, против чего Демидович борется.     Вам надо не на компетентность претендовать, а на правдивость.    

                    Со школьным Linux вообще весело всем получается. Все хотят присосаться к выделенному бюджету. Рейман тоже прикупил себе часть акций Mandriva и тоже что-то пилил для школ. В результате всего -- ужас везде и у всех. Работайте дальше, может, что и выйдет.    

                    А Linfan как там, чем занимается?    

                    • 1
                      shigorin shigorin16.11.14 20:20:07

                      Я претендую на непосредственное участие в проекте -- собственно, остался фотоархив и в т. ч. непубличный инсайд.

                      На CentOS («на коленке») было изначально поднято железо, далее параллельным взлётом (отдельная песня) был поднят Clustrx, который мы в Massive Solutions разрабатывали на базе альта (к сожалению, не наладив с альтом нормального взаимодействия -- в основном по своей вине).

                      Фраза «Clustrx включает в себя: ОС на базе Linux (CentOS 6.1)» по состоянию на 2012 год может характеризовать или желание перепереть наработки на центос, или предпринятые меры к тому -- здесь не знаю, т.к. после того, как в ТП побили горшки с Massive Solutions по жадности и неуёмному желанию контролировать всё и вся -- это был далеко не единственный конфликт с их участием в те годы, увы -- старался не набирать лишней информации.

                      Что там сейчас -- самому интересно, маркерами будут отношения с Абрамовым и компанией (там как раз неподеленный «царь горы», хотя казалось бы -- одни тащат вперёд прикладную часть проекта, другие -- научную, о финансировании при наличии головы на плечах лучше договариваться, чем рвать одеяло на мусор) и со сторонними поставщиками ПО (если продолжат костылить на центосе и коленке, значит, так и не научились).

                      Про Демидовича не в курсе или забыл, расшифруйте.

                      За неправдивость морды бил с детства.

                      Реймана с мандривой красиво кинули -- 4 млн евро за пустое место (были сведения с той стороны через знакомого). Там главная беда и была в том, что вместо работы на результат погнались за деньгами, причём люди без принципов и совести вроде Комиссарова в роли шестёрок умудрились ещё и горшков набить с перевыполнением плана.

                      «Linfan» тоже не припоминаю.

                      PS: прошу Вашего прощения, погорячился. Очень близко к сердцу эта тема (предупреждения пятилетней давности сбылись). Равно как и утопленная НПП. И очень она показательна -- потому что пилотное внедрение было весьма успешным, я от альта такого качества продукта тогда не ожидал (сам приложил руку к выпуску Альт Линукс Терминал тогда -- за него приходили благодарности, а нареканий не было вообще).

                      --

                      Michael Shigorin

                      • 0
                        Ruslan Ruslan16.11.14 20:42:29

                        Ну, тогда и Вы меня за резкость простите. Просто тоже устал бодаться то с заказчиками, то с другими интеграторами. У нас в стране пока что ещё одна проблема -- не умеем договариваться между собой.

                        Демидович -- это пользователь в этой ветке. Linfan -- ник Игоря Новикова на ЛОРе. Об Игоре давно новостей н читал, как и о его проекте.