Ну, то что было популярно давно - это отдельная история. Среди однопользовательских СУБД работающих на PC, да, было некоторое число (включая и две эти) очень популярных СУБД. Clarion еще например была. Сегодня они почти не актуальны, хотя вот я не знаю, есть же Access, я почти уверен, что она все еще мегапопулярна среди определенной категории пользователей. Вполне возможно - популярнее mySQL, если в штуках посчитать.
В нем просто некомфортно находиться, не то что жить.
Все индивидуально. Вполне верю, что вам так и есть. А мне комфортно. Я люблю такой ритм жизни. Хотя если честно, иногда хочется от него и отдохнуть - т.е. отпуск провести в маленьком городке. И Питер кстати да, другой - но там тоже есть свои особенности, из-за которых я бы туда жить не поехал (впрочем, мне пару раз только предлагали, и предложения по зарплате были смешные - с учетом переезда так вообще смешные).
Ну есть еще ленивый вариант для "простого пользователя". Раз уж ты сам себе выбрал более редкую ОС (ну и то условно, потому что ее рыночная доля где-то от 15 процентов и наверное даже выше), то сайт озона был бы последним местом, где я бы стал искать информацию. А на сайте производителя автор той статьи уже сам нашел все что нужно - что драйвера там нет, AirPrint не поддерживается (ну в смысле, я вам верю, что он на самом деле работает, но у производителя так написано, правда). Т.е. описание принтера как минимум противоречиво, потому что поддержка MacOS все же декларирована.
На этом месте будучи пользователем я бы принял простейшее решение - поискать другой принтер, наплевав на все преимущества этого (в виде дешевых чернил, по сути - других-то особо и нет).
Вы же описали подход грамотного админа или программиста, знакомого немного с потрохами ОС, и с тем как устроен дистрибутив драйвера. И при этом не ленящегося погуглить, почитать, и провести несложное исследование.
А в той статье что? Нашел на озон указание о поддержке, поверил на слово, на сайт производителя сразу не сходил, купил, не заработало, дальше вы все знаете...
Ну да, я согласен - это другие кейсы, тут я пожалуй тоже не скажу, что оверпасс был бы удобен. Тэги надо либо знать априори, либо хотя бы понимать, где у нас правильно размеченные объекты на карте - и тогда зайти с их стороны. Если ни то ни другое нам не известно - то наверное инструмент для работы с текстовым представлением (либо xml, либо может быть - база) будет лучше.
Для меня оверпасс - это инструмент для задач типа "открыть карту, найти объект какого-то известного типа (станцию метро), изучить, как она размечена, какими тэгами отмечены выходы, и т.п. А потом уже идем в базу, или запускаем осмозис. И выгружаем все станции и все выходы к себе, и мучаем по всякому.
Потому что на базе, при условии что она правильно построена, можно себе позволить запросы вида "а какие у нас вообще тэги бывают при таких-то условиях".
Ну, мне показалось, что вы все же говорите об исследовании разметки, в том числе. Осмозис - это уже когда вы скорее знаете, что вам нужно.
Возможно я не умею его готовить...
Легко верю. Он сложный. Но ведь и разметка достаточно сложная, и тут интерактивный режим работы решает. Я подумывал про него написать, но ушел с того проекта, где я его активно применял на ежедневной основе. По-моему тут была про него статья, поищу.
MySQL – это надежный дедушка баз данных – он существует с древних времен и каким-то образом продолжает становиться все лучше.
Чрезвычайно субъективный и односторонний взгляд на вещи. Скажем, для меня дедушка СУБД - это DB2, потому что это первая коммерческая и практически применимая SQL СУБД, которая появилась в 1981 году (под названием SQL/DS), и все еще широко применяется сегодня. А mysql появился только в 1995, на целых 14 лет позже. Да и упомянутый тут Oracle тоже, между прочим, 1979 году появился. Ну и кто тут чей дедушка?
Тоже самое и с экосистемой Hadoop - такое впечатление, что автор оригинала ее нихрена не знает, потому что упомянуть HBase и Cassandra, и забыть при этом Hive - это надо постараться было. Да в общем и с другими такая же фигня - упомянуты какие-то непонятные форки непонятных СУБД, и при этом нет Greenplum.
Зато рекламу свою впихнуть не забыли...в самое начало.
Не уловил, как можно при описании исследования данных в OSM вообще не упомянуть https://overpass-turbo.eu/? Как по мне, сначала идем туда, изучаем разметку, пишем запросы. И потом уже осмозис (или другая утилита, например паркетизер).
Нет, не готов. Но если бы за меня кто-то это сделал - я бы с удовольствием почитал написанную им выжимку :) Ну потому что так или иначе, а скажем раз в три месяца ко мне приходит поддержка, и спрашивает - ну чо, будем linux и JDK обновлять? И не только меня, а еще сотню коллег вокруг. И было бы неплохо, если бы кто-то один в такой ситуации таки прочитал release notes, и сказал бы нам - ребята, там сплошная фигня, нас нас это никак не повлияет, обновляемся. Или может повлиять, так-то и так-то.
Но я подозреваю, что он один все равно не сможет это сделать квалифицированно. Ну просто для примера - было у нас как-то обновление, которое принудительно включило протокол TLSv1.2. И мы только через месяц заметили, что к одной из наших СУБД MS SQL нельзя подключиться, если у тебя стоит это обновление, потому что там в MS SQL только TLSv1.0, и чтобы включить 1.2 нужно поставить другое обновление, а обновление это платное, потому что MS SQL у нас был 2008 R2, ну и так далее.
Я это все к чему - можно этого и не делать, но выстрелить может совершенно неожиданно.
если бы я настраивал серверную архитектуру в каком‑нибудь K8S кластере, я был бы обязан проверить всё до последнего системного файла и убедиться, что ни один контейнер не использует и килобайта лишних слоёв.
Зачем? Разве к вам приходил заказчик и сказал, что вы тратите слишком много денег на кластер? Или кластер перегружен? Если ни то ни другое - ваше время возможно более эффективно (с точки зрения заказчика) использовать на разработку нового функционала.
Его таки не стало заметно больше (на настольных машинах конечно - сервера совсем другая история). Недавно свежие данные тут пробегали, там упоминалось что-то типа 3% пользователей. Вы конечно можете называть это как угодно, но это мизерные показатели, по большому счету.
вот ты завязан на библиотеке от вендора/государства/легаси - а она осталась жить на старой версии зависимости - всё, ты блокирован в обновлении.
Вы не представляете, насколько это реальный и типичный случай. Зачастую все даже еще хуже - потому что например, новая версия библиотеки, с одной стороны, не содержит уязвимостей, а с другой - требует более новой версии JVM. Ну или еще типовой неприятный случай - есть у вас скажем spring web, в которой в наличии кучка уязвимостей. Но - эти уязвимости - они в реализации серверной части, а вы используете например только RestTemplate, т.е. у вас клиент. Но при этом авторы оного spring web не подумали о таком сценарии, и разделили код так как разделили - то есть никак. И в одном компоненте лежит и серверная часть, и клиентская. И вот сидишь ты такой, и думаешь, как же мне доказать безопасникам (или сканеру типа SAST), что у тебя-то в приложении никаких уязвимостей нет, потому что кроме RestTemplate ничего не используется.
Ну и кстати, никакой BOM тут не помогает от слова совсем.
Ну, сделать префикс к классу (или еще лучше - поменять пакет) может разработчик библиотеки. И это означает сломать API, вообще говоря. У такого подхода есть свои недостатки.
А пользователь библиотеки ограничен средствами системы сборки. Он может например использовать maven shade плагин, который сделает ровно то, что вы предлагаете (ну если я вас верно понял). А еще есть OSGI, где можно иметь несколько версий библиотек. достаточно несложно.
Ну то есть, я не хочу сказать что атаки на механизм поставки зависимостей глупость или ерунда, я хочу сказать что в таком виде это не более чем забавно.
По статистике NPM пакет был загружен около 250 раз, но никто не мешает добавить его в зависимости к другому пакету после взлома учётной записи разработчика для совершения диверсии.
Ну как бы, это совсем несерьезно. 250 каких-то странных людей загрузили, и чо? Вот меня-то как разработчика что может заставить включить в список своих зависимостей некую непонятную хрень под названием everything? Причем заметьте - в случае мавен централа у вас не выйдет опубликовать зависимость от имени условной Apache Groop, только под своей учеткой (вопросы взлома - опять же за рамками эксплуатации именно этой уязвимости). Так вот если непонятная хрень еще и опубликована непонятно кем - шансы что я ее подключу к проекту реально нулевые (еще на минутку, мне для начала нужно узнать о ее существовании).
Не говоря уже о том, что после "взлома учетной записи" можно сделать любые другие гадости на выбор.
Атака-то на кого? Этож надо чтобы кто-то это хотя бы скачать попробовал. Не могу сходу себе представить, чтобы кто-то с какой-то целью пытался скачать такую зависимость.
А что вам может помешать такое сделать, ну разве что кроме размеров файла pom.xml (учитывая, что число артефактов в централе кажется уже давно перевалило за 10 миллионов, не считая разных версий). Другой вопрос - как это может сломать тот же централ? Для него это просто огромный артефакт, на зависимости репозиторию наплевать по большому счету. Хотя нет, UI централа нынче показывает зависимости (и даже уязвимости в них), вот его запросто сможет сломать.
Так я с вашим комментом и не спорил - я ровно такие же впечатления от текста имею - длинное описание технологий, процесса разработки, и при этом нифига не понятно, что за проект, зачем он вообще, в чем отличия от похожих, ну и т.д.
Автор в принципе уже высказался на эту тему, что именно об этом он и хотел написать, но в итоге все равно получилось, что подробно описано решение непоставленной задачи.
Ну, то что было популярно давно - это отдельная история. Среди однопользовательских СУБД работающих на PC, да, было некоторое число (включая и две эти) очень популярных СУБД. Clarion еще например была. Сегодня они почти не актуальны, хотя вот я не знаю, есть же Access, я почти уверен, что она все еще мегапопулярна среди определенной категории пользователей. Вполне возможно - популярнее mySQL, если в штуках посчитать.
Все индивидуально. Вполне верю, что вам так и есть. А мне комфортно. Я люблю такой ритм жизни. Хотя если честно, иногда хочется от него и отдохнуть - т.е. отпуск провести в маленьком городке. И Питер кстати да, другой - но там тоже есть свои особенности, из-за которых я бы туда жить не поехал (впрочем, мне пару раз только предлагали, и предложения по зарплате были смешные - с учетом переезда так вообще смешные).
Ну есть еще ленивый вариант для "простого пользователя". Раз уж ты сам себе выбрал более редкую ОС (ну и то условно, потому что ее рыночная доля где-то от 15 процентов и наверное даже выше), то сайт озона был бы последним местом, где я бы стал искать информацию. А на сайте производителя автор той статьи уже сам нашел все что нужно - что драйвера там нет, AirPrint не поддерживается (ну в смысле, я вам верю, что он на самом деле работает, но у производителя так написано, правда). Т.е. описание принтера как минимум противоречиво, потому что поддержка MacOS все же декларирована.
На этом месте будучи пользователем я бы принял простейшее решение - поискать другой принтер, наплевав на все преимущества этого (в виде дешевых чернил, по сути - других-то особо и нет).
Вы же описали подход грамотного админа или программиста, знакомого немного с потрохами ОС, и с тем как устроен дистрибутив драйвера. И при этом не ленящегося погуглить, почитать, и провести несложное исследование.
А в той статье что? Нашел на озон указание о поддержке, поверил на слово, на сайт производителя сразу не сходил, купил, не заработало, дальше вы все знаете...
Ну да, я согласен - это другие кейсы, тут я пожалуй тоже не скажу, что оверпасс был бы удобен. Тэги надо либо знать априори, либо хотя бы понимать, где у нас правильно размеченные объекты на карте - и тогда зайти с их стороны. Если ни то ни другое нам не известно - то наверное инструмент для работы с текстовым представлением (либо xml, либо может быть - база) будет лучше.
Для меня оверпасс - это инструмент для задач типа "открыть карту, найти объект какого-то известного типа (станцию метро), изучить, как она размечена, какими тэгами отмечены выходы, и т.п. А потом уже идем в базу, или запускаем осмозис. И выгружаем все станции и все выходы к себе, и мучаем по всякому.
Потому что на базе, при условии что она правильно построена, можно себе позволить запросы вида "а какие у нас вообще тэги бывают при таких-то условиях".
Ну, мне показалось, что вы все же говорите об исследовании разметки, в том числе. Осмозис - это уже когда вы скорее знаете, что вам нужно.
Легко верю. Он сложный. Но ведь и разметка достаточно сложная, и тут интерактивный режим работы решает. Я подумывал про него написать, но ушел с того проекта, где я его активно применял на ежедневной основе. По-моему тут была про него статья, поищу.
https://habr.com/ru/articles/520524/ ну вот скажем статья в том числе и про него.
Да остальные-то тоже... так себе. Flyweight тупо описан неверно, ну или скажем неполно, что лишает его основного смысла.
Ну зато мы четко понимаем, какова ценность данного материала.
Ради объективности, тут в оригинале ошибка. Там в заголовке 20, а сразу же в тексте - 25.
Чрезвычайно субъективный и односторонний взгляд на вещи. Скажем, для меня дедушка СУБД - это DB2, потому что это первая коммерческая и практически применимая SQL СУБД, которая появилась в 1981 году (под названием SQL/DS), и все еще широко применяется сегодня. А mysql появился только в 1995, на целых 14 лет позже. Да и упомянутый тут Oracle тоже, между прочим, 1979 году появился. Ну и кто тут чей дедушка?
Тоже самое и с экосистемой Hadoop - такое впечатление, что автор оригинала ее нихрена не знает, потому что упомянуть HBase и Cassandra, и забыть при этом Hive - это надо постараться было. Да в общем и с другими такая же фигня - упомянуты какие-то непонятные форки непонятных СУБД, и при этом нет Greenplum.
Зато рекламу свою впихнуть не забыли...в самое начало.
Не уловил, как можно при описании исследования данных в OSM вообще не упомянуть https://overpass-turbo.eu/? Как по мне, сначала идем туда, изучаем разметку, пишем запросы. И потом уже осмозис (или другая утилита, например паркетизер).
Нет, не готов. Но если бы за меня кто-то это сделал - я бы с удовольствием почитал написанную им выжимку :) Ну потому что так или иначе, а скажем раз в три месяца ко мне приходит поддержка, и спрашивает - ну чо, будем linux и JDK обновлять? И не только меня, а еще сотню коллег вокруг. И было бы неплохо, если бы кто-то один в такой ситуации таки прочитал release notes, и сказал бы нам - ребята, там сплошная фигня, нас нас это никак не повлияет, обновляемся. Или может повлиять, так-то и так-то.
Но я подозреваю, что он один все равно не сможет это сделать квалифицированно. Ну просто для примера - было у нас как-то обновление, которое принудительно включило протокол TLSv1.2. И мы только через месяц заметили, что к одной из наших СУБД MS SQL нельзя подключиться, если у тебя стоит это обновление, потому что там в MS SQL только TLSv1.0, и чтобы включить 1.2 нужно поставить другое обновление, а обновление это платное, потому что MS SQL у нас был 2008 R2, ну и так далее.
Я это все к чему - можно этого и не делать, но выстрелить может совершенно неожиданно.
Зачем? Разве к вам приходил заказчик и сказал, что вы тратите слишком много денег на кластер? Или кластер перегружен? Если ни то ни другое - ваше время возможно более эффективно (с точки зрения заказчика) использовать на разработку нового функционала.
Его таки не стало заметно больше (на настольных машинах конечно - сервера совсем другая история). Недавно свежие данные тут пробегали, там упоминалось что-то типа 3% пользователей. Вы конечно можете называть это как угодно, но это мизерные показатели, по большому счету.
Вы не представляете, насколько это реальный и типичный случай. Зачастую все даже еще хуже - потому что например, новая версия библиотеки, с одной стороны, не содержит уязвимостей, а с другой - требует более новой версии JVM. Ну или еще типовой неприятный случай - есть у вас скажем spring web, в которой в наличии кучка уязвимостей. Но - эти уязвимости - они в реализации серверной части, а вы используете например только RestTemplate, т.е. у вас клиент. Но при этом авторы оного spring web не подумали о таком сценарии, и разделили код так как разделили - то есть никак. И в одном компоненте лежит и серверная часть, и клиентская. И вот сидишь ты такой, и думаешь, как же мне доказать безопасникам (или сканеру типа SAST), что у тебя-то в приложении никаких уязвимостей нет, потому что кроме RestTemplate ничего не используется.
Ну и кстати, никакой BOM тут не помогает от слова совсем.
Ну, сделать префикс к классу (или еще лучше - поменять пакет) может разработчик библиотеки. И это означает сломать API, вообще говоря. У такого подхода есть свои недостатки.
А пользователь библиотеки ограничен средствами системы сборки. Он может например использовать maven shade плагин, который сделает ровно то, что вы предлагаете (ну если я вас верно понял). А еще есть OSGI, где можно иметь несколько версий библиотек. достаточно несложно.
Если взломают скажем тот же Apache Groop, то это вероятно будет опасно, но это будет совсем другой сценарий, нежели тот, который описан тут в статье.
Ну то есть, я не хочу сказать что атаки на механизм поставки зависимостей глупость или ерунда, я хочу сказать что в таком виде это не более чем забавно.
Смотрим описание из текущей статьи:
Ну как бы, это совсем несерьезно. 250 каких-то странных людей загрузили, и чо? Вот меня-то как разработчика что может заставить включить в список своих зависимостей некую непонятную хрень под названием everything? Причем заметьте - в случае мавен централа у вас не выйдет опубликовать зависимость от имени условной Apache Groop, только под своей учеткой (вопросы взлома - опять же за рамками эксплуатации именно этой уязвимости). Так вот если непонятная хрень еще и опубликована непонятно кем - шансы что я ее подключу к проекту реально нулевые (еще на минутку, мне для начала нужно узнать о ее существовании).
Не говоря уже о том, что после "взлома учетной записи" можно сделать любые другие гадости на выбор.
Атака-то на кого? Этож надо чтобы кто-то это хотя бы скачать попробовал. Не могу сходу себе представить, чтобы кто-то с какой-то целью пытался скачать такую зависимость.
А что вам может помешать такое сделать, ну разве что кроме размеров файла pom.xml (учитывая, что число артефактов в централе кажется уже давно перевалило за 10 миллионов, не считая разных версий). Другой вопрос - как это может сломать тот же централ? Для него это просто огромный артефакт, на зависимости репозиторию наплевать по большому счету. Хотя нет, UI централа нынче показывает зависимости (и даже уязвимости в них), вот его запросто сможет сломать.
Так я с вашим комментом и не спорил - я ровно такие же впечатления от текста имею - длинное описание технологий, процесса разработки, и при этом нифига не понятно, что за проект, зачем он вообще, в чем отличия от похожих, ну и т.д.
Автор в принципе уже высказался на эту тему, что именно об этом он и хотел написать, но в итоге все равно получилось, что подробно описано решение непоставленной задачи.