Чтоб было еще понятнее — вы смотрите на инфраструктуру со стороны убунту, а это — далеко не большая часть линуксов в мире. Я может и преувеличиваю, но не сильно. Поясню, почему:
— андроид. Не могу сказать, касается ли эта уязвимость его, но что тут с патчами для ОС все фигово — вы думаю и без меня знаете.
— у меня лично есть такая железка, как WD TV Live, внутри у которой тоже какой-то линукс.
— и еще одна железка, WD MyBookLive, и снова внутри линукс.
— итого сотни и тысячи моделей разных роутеров, веб-камер, плееров…
… и прочего барахла, которые либо заброшены производителем изначально, либо по причине устаревания. Причем в большинстве случаев пользователя не спросили, чего он изволит, это вам не ноутбук, нечего вам туда лазать.
Ну и вот как со всем этим жить? Это тоже все называется линукс, разве нет? Самба в плеерах и роутерах — на каждом шагу, где только есть USB — туда можно воткнуть диск, и расшарить, догадайтесь по какому протоколу. И кто их знает, есть там уязвимости, или нет, и кто их будет фиксить, и когда…
Я не говорю что это одна уязвимость. Я говорю о том, что а) были неоднократно опубликованы уязвимости для самбы под win. б) код этот весь старый, в какой-то степени и в линукс переписанный с той же Win, просто потому, что это средство совместимости. Следовало ожидать, что там есть дыры.
Т.е совсем нормальным подходом было бы после публикации викиликс провести ревизию всего этого барахла, в том числе на предмет поиска похожих уязвимостей.
>А новая уязвимость CVE-2017-7494 — была в убунте исправлена 19 мая, например. При том что sambacry активизировался только вчера.
А уязвимость в Win была закрыта в марте, т.е. за пару месяцев до атаки. Ну так что вы хотите этим продемонстрировать? Оперативно закрыли, молодцы, но пока петух не клюнет — всем пофиг. Вот как-то так я это вижу. Нет в этой (разумеется другой) инфраструктуре такого человека или компании, который бы не только искал, но и затыкал уязвимости заранее, до эксплуатации.
Где вы тут видите «другой подход»? Дыру опубликовал кажется викиликс, еще зимой, нет? Про потенциальные дыры в протоколе и реализациях вообще писали тут многократно и давно. Мысль что протокол потенциально дырявый — напрашивается уже много лет.
MS свой патч выпустила в марте (лично мне прилетел в районе 17-18 числа).
Вы считаете, что еще два месяца на то, чтобы проанализировать наличие дыр в софте, переписанном когда-то с Win, и их заделывание — это нормально? По-моему если бы не эпидемия на win, производители дистрибутивов линукс вообще не почесались бы.
Насчет бэкдора — не очевидно (ну какой такой в самом деле, когда про дыры в протоколе писали много и давно?), а вот что это могло быть прикрытием для другой цели — это очень похоже на правду.
>например, в МИДе не пострадал вообще ни один компьютер.
Ну, файрвол с закрытыми портами, админ параноик? Что тут странного само по себе? Тем более что уязвимость закрыта в марте.
Знаете, все вменяемые обновляются быстро и легко. А те кто сидит на Java 6… ну я знаю одну такую контору. Как почитаешь их требования — сразу хочется забыть, что видел эти вакансии. И Java 6 тут самое меньшее из зол обычно.
А можете подтвердить слова про быстродействие? Я вот ни разу пожалуй не сталкивался с серьезными проблемами. Ну т.е. оно ниже, чем у просто Java, да и то — JIT с этим борется более-менее успешно.
Какую такую другую? Груви — вполне рабочий язык для бизнеса, не требующего реал-тайм или квази-рт. Это широчайшая аудитория, по большому счету. Если честно сравнивать, что разве что javascript как целевая платформа не покрывается. Совместимость с Java на высоком уровне — если случайно груви классы в API не выставить, проблем почти не бывает.
>(опустим compileStatic и core.typed
Почему опустим-то? Практической разницы — почти никакой.
Собственно, я и не говорю, что это критичная проблема. Я ее просто как пример привел — неудачные характеристики можно найти у любого языка. Этакий небольшой но лишний геморрой на пустом месте.
>Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Ну скажем так — работая на java, я вам таких покажу сотни. То есть тут этой проблемы нет вообще, исключения редчайшие.
Хм. Посмотрел минут пять. Знаете, я такое уже много лет пишу на груви. И можно привести почти такой же список, почему груви лучше Java (с версии 8 этот список чуть сократился). Почти 1 в 1 будет. А ведь кложу еще не начали вспоминать :)
Это все правда, про акку и пр, но объективности ради, у скалы далеко не все хорошо, например с бинарной совместимостью. И мне вот лично пока не ясно, что будет например после внедрения dotty — очередная ломка? Или наконец наоборот, некоторая стабильность?
Так что понять авторов котлина вполне можно — они пытаются создать очередной компромисс.
P.S. Я вовсе не хочу сказать, что у котлина все хорошо. Тут еще посмотреть надо будет.
>CI-сервер накладывает Vendor-lock и зачастую требует «программирования мышкой», следовательно и отвязывает версию процесса сборки от версии кода в репозитории, хотя некоторые CI системы и позволяют хранить файлы с описанием процесса сборки вместе с кодом.
А что, есть такие, которые не позволяют?
>Использование CI не позволяет собирать код локально так же, как и на CI-сервере
Не могу себе представить CI сервер, не позволяющий собрать тем же инструментом, которым собирают без него.
В общем случае — да. Но в конкретном это за уши притянуто, прямо скажем.
Да и с версиями вы тоже скорее всего перебарщиваете — чтобы иметь разные версии java, вам нужно будет иметь разные докер-контейнеры. И если они у вас нестандартные хоть чуть-чуть — у вас будут сложности, чтобы их собрать. Докеровский путь для этого далеко не такой гибкий и удобный, как хотелось бы. Я бы сказал, что это окупится в лучшем случае, если нужны несколько сервисов. Типа базы данных, веб сервиса и т.п.
Чтоб было понятнее — автор этой статьи считает, что возможность построить модель проекта динамически, используя для этого groovy — это хорошо. На мой же взгляд — это ужасно.
Чтобы так делать, нужно чтобы у вас был gradle в наличии. Причем желательно — той же версии, с теми же плагинами. И надо сборку фактически выполнить, чтобы модель получить. Мало того, что это делает импорт скажем gradle проектов в IDEA просто на порядки медленнее — это еще и не позволяет работать с проектами из других языков. При этом с pom я успешно работал любым инструментом — потому что это xml.
Ну и кто тут привязан к одному языку?
Понятно, что у него другие use cases, но совершенно очевидно, что он обобщает без оснований.
Сложности? Не большие, чем у любого другого средства сборки. Попробуйте для примера, использовать какой-нибудь современный менеджер зависимостей, типа bower, на машине в интранете, с доступом вовне через прокси, которая генерирует на лету SSL сертификаты. Проникнитесь с ходу.
А соглашения кстати соблюдать не обязательно. Я писал плагины, работающие вообще без наличия POM, это вполне возможно. Пишете на груви, внутри делаете вообще что хотите.
Статья кстати дурацкая. Не, не вся, разумные мысли там есть — только вот решений проблем автор все равно не предложил. А местами просто ржака:
The POM as used in repositories is too verbose for its intended use, and could be vastly improved. Slimming it down would be possible, but enhancing it by making it no longer immutable would break everyone. Unfixable.
Ха (три раза). POM в репозитории — это единственная вменяемая форма модели, с которой вообще можно работать. Я бы сказал, что все другие модели значительно хуже, но опыт применения скажем npm маловать для столь категоричного высказывания.
Вот я и спрашиваю, где вы это вычитали? Мало того, что уже много лет существуют скажем плагины для сборки .Net проектов (потому что эта сборка в общем-то ничем не отличается от сборки java проектов), или скажем Flexmojo, мало того, что сами плагины пишутся на Groovy, кложе, и еще на некоторых разных языках.
В мавене нет никакой привязки к языку, кроме той, что он сам на java написан. Мавен — это лишь формат POM (который в целом language agnostic, да еще и сам давно уже может быть переписан например в виде yaml). Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок — которые тоже ни к какому языку не привязаны отродясь.
Одни и теже настройки? Для этого нужно, чтобы они строились автоматически. И если это условие выполнено — докер тут совершенно лишний. Правильно написанный спринговый веб сервис и так не зависит почти ни от чего.
Все хорошо, но именно так в java тоже уже не пишут. Есть ломбок, есть другие способы.
Кроме того, fluent API (в виде builder скажем) далеко не всегда такой простой и очевидный, как у вас в примере. И не заменяется просто именованными параметрами.
— андроид. Не могу сказать, касается ли эта уязвимость его, но что тут с патчами для ОС все фигово — вы думаю и без меня знаете.
— у меня лично есть такая железка, как WD TV Live, внутри у которой тоже какой-то линукс.
— и еще одна железка, WD MyBookLive, и снова внутри линукс.
— итого сотни и тысячи моделей разных роутеров, веб-камер, плееров…
… и прочего барахла, которые либо заброшены производителем изначально, либо по причине устаревания. Причем в большинстве случаев пользователя не спросили, чего он изволит, это вам не ноутбук, нечего вам туда лазать.
Ну и вот как со всем этим жить? Это тоже все называется линукс, разве нет? Самба в плеерах и роутерах — на каждом шагу, где только есть USB — туда можно воткнуть диск, и расшарить, догадайтесь по какому протоколу. И кто их знает, есть там уязвимости, или нет, и кто их будет фиксить, и когда…
Т.е совсем нормальным подходом было бы после публикации викиликс провести ревизию всего этого барахла, в том числе на предмет поиска похожих уязвимостей.
>А новая уязвимость CVE-2017-7494 — была в убунте исправлена 19 мая, например. При том что sambacry активизировался только вчера.
А уязвимость в Win была закрыта в марте, т.е. за пару месяцев до атаки. Ну так что вы хотите этим продемонстрировать? Оперативно закрыли, молодцы, но пока петух не клюнет — всем пофиг. Вот как-то так я это вижу. Нет в этой (разумеется другой) инфраструктуре такого человека или компании, который бы не только искал, но и затыкал уязвимости заранее, до эксплуатации.
MS свой патч выпустила в марте (лично мне прилетел в районе 17-18 числа).
Вы считаете, что еще два месяца на то, чтобы проанализировать наличие дыр в софте, переписанном когда-то с Win, и их заделывание — это нормально? По-моему если бы не эпидемия на win, производители дистрибутивов линукс вообще не почесались бы.
>например, в МИДе не пострадал вообще ни один компьютер.
Ну, файрвол с закрытыми портами, админ параноик? Что тут странного само по себе? Тем более что уязвимость закрыта в марте.
>только благодаря jetbrains
да что вы говорите? А я думал благодаря gradle…
>(опустим compileStatic и core.typed
Почему опустим-то? Практической разницы — почти никакой.
>Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Ну скажем так — работая на java, я вам таких покажу сотни. То есть тут этой проблемы нет вообще, исключения редчайшие.
Так что понять авторов котлина вполне можно — они пытаются создать очередной компромисс.
P.S. Я вовсе не хочу сказать, что у котлина все хорошо. Тут еще посмотреть надо будет.
А что, есть такие, которые не позволяют?
>Использование CI не позволяет собирать код локально так же, как и на CI-сервере
Не могу себе представить CI сервер, не позволяющий собрать тем же инструментом, которым собирают без него.
В общем случае — да. Но в конкретном это за уши притянуто, прямо скажем.
Да и с версиями вы тоже скорее всего перебарщиваете — чтобы иметь разные версии java, вам нужно будет иметь разные докер-контейнеры. И если они у вас нестандартные хоть чуть-чуть — у вас будут сложности, чтобы их собрать. Докеровский путь для этого далеко не такой гибкий и удобный, как хотелось бы. Я бы сказал, что это окупится в лучшем случае, если нужны несколько сервисов. Типа базы данных, веб сервиса и т.п.
Чтоб было понятнее — автор этой статьи считает, что возможность построить модель проекта динамически, используя для этого groovy — это хорошо. На мой же взгляд — это ужасно.
Чтобы так делать, нужно чтобы у вас был gradle в наличии. Причем желательно — той же версии, с теми же плагинами. И надо сборку фактически выполнить, чтобы модель получить. Мало того, что это делает импорт скажем gradle проектов в IDEA просто на порядки медленнее — это еще и не позволяет работать с проектами из других языков. При этом с pom я успешно работал любым инструментом — потому что это xml.
Ну и кто тут привязан к одному языку?
Понятно, что у него другие use cases, но совершенно очевидно, что он обобщает без оснований.
Сложности? Не большие, чем у любого другого средства сборки. Попробуйте для примера, использовать какой-нибудь современный менеджер зависимостей, типа bower, на машине в интранете, с доступом вовне через прокси, которая генерирует на лету SSL сертификаты. Проникнитесь с ходу.
А соглашения кстати соблюдать не обязательно. Я писал плагины, работающие вообще без наличия POM, это вполне возможно. Пишете на груви, внутри делаете вообще что хотите.
Статья кстати дурацкая. Не, не вся, разумные мысли там есть — только вот решений проблем автор все равно не предложил. А местами просто ржака:
The POM as used in repositories is too verbose for its intended use, and could be vastly improved. Slimming it down would be possible, but enhancing it by making it no longer immutable would break everyone. Unfixable.
Ха (три раза). POM в репозитории — это единственная вменяемая форма модели, с которой вообще можно работать. Я бы сказал, что все другие модели значительно хуже, но опыт применения скажем npm маловать для столь категоричного высказывания.
Вот я и спрашиваю, где вы это вычитали? Мало того, что уже много лет существуют скажем плагины для сборки .Net проектов (потому что эта сборка в общем-то ничем не отличается от сборки java проектов), или скажем Flexmojo, мало того, что сами плагины пишутся на Groovy, кложе, и еще на некоторых разных языках.
В мавене нет никакой привязки к языку, кроме той, что он сам на java написан. Мавен — это лишь формат POM (который в целом language agnostic, да еще и сам давно уже может быть переписан например в виде yaml). Ну и соглашения некоторые, типа жизненного цикла сборки или структуры папок — которые тоже ни к какому языку не привязаны отродясь.
В каком месте у мавен жестко определеный язык?
Одни и теже настройки? Для этого нужно, чтобы они строились автоматически. И если это условие выполнено — докер тут совершенно лишний. Правильно написанный спринговый веб сервис и так не зависит почти ни от чего.
А вам про что в посте написали? Не верите? Ну вот оно… теже яйца, только в профиль
Все хорошо, но именно так в java тоже уже не пишут. Есть ломбок, есть другие способы.
Кроме того, fluent API (в виде builder скажем) далеко не всегда такой простой и очевидный, как у вас в примере. И не заменяется просто именованными параметрами.