По мотивам одной весьма тенденциозной (и тем самым прямо провоцирующей применение научного метода оценки свидетельств) публикации «Привет всем любителям открытого кода» полагаю полезным обратить внимание на систематическую погрешность публикатора, рукопожатно «теряющего» вопросы о перспективах аналогичных… сюрпризов от *поставщиков* проприетарных решений (до материальной ответственности включительно).
Можно было бы ограничиться участием в *том* обсуждении. Но автор из ряда тех, кто склонен компенсировать слабость аргументов «единственно правильной» точки зрения банхаммером.
Для начала процитирую несколько адекватных комментариев:
klk:
Гы, можно подумать в закрытый код тебе какашек не напихают
Проприетарщина лучше свободных программ тем, что...
...попрыгав на коленях и заплатив много-много можно надеяться получить то, что в свободном ПО получаешь всегда и бесплатно.
Классическое натягивание на глобус...
Какой-то горе-программист испохабил nodejs-скрипт, а выводы делаются о ядре Linux!
То, что джаваскрипт-киддисы не умеют в программирование и им обязательно надо весь NPM к себе затащить чтобы сайт на одну страничку заработал - давно известный факт. То, что у NPM проблемы с обновлениями в результате злонамеренных действий разработчиков - тоже не новость. И это логично: чем ниже порог вхождения, тем больше неадекватов в сообществе.
А вообще весь код включая зависимости надо держать у себя и при обновлении до апстрима хотя бы просматривать описания изменений - да-да, каждого изменения. Код с изменениями под заголовком "chore: Give Peace a Chance" ("призыв: дайте миру шанс") определённо должен рассматриваться как подозрительный и изучаться. То, что для NPM невозможно изучать изменения всех библиотек даже в заголовках - проблемы технологии. Все, кто не имеет возможности отслеживать изменения в используемом коде, должны молиться на совесть разработчиков этого кода (и ментально примерять к себе вазелин).
И естественно, все версии библиотек должны быть забиты гвоздями в манифесте, как это уже было указано не раз выше.
Ну а теперь к предмету статьи: дефективно-минетжимент очень любит простую (одномерную) оптимизацию по стоимости владения.
Тут ТМО однозначно диктует решение в виде концентрации нагрузки и аренды внешних вычислительных мощностей.
Это — присказка. Сказка — о цене такого подхода в *реальном* (многомерном) мире. наглядная иллюстраций исторической притчи о противостоянии удобства и безопасности.
К сожалению, позиции минет.жимента, склонного к освоению бюджетов на закупки товарных решений у разработчиков, управляемых враждебными рептилоидами, всё ещё слишком сильны.
В результате получаются интересные оповещения. Типа полученного вчера, что оповещение уважаемого бизнес-партнёра о блокировке учётных записей — шутка-нанайка. И что наиболее важные (а потому всё же размещённые на площадке Предприятия) сервисы X и Y сохраняют свойство работоспособности.
Комментарии
Как мне кажется, ecmascript (javascript) достаточно неплохой язык программирования, но у ведущей платформы разработки – node.js – экосистема и впрямь гигантская и от этого местами помоечная. Есть альтернативные среды выполнения, к примеру, deno или just-js, там проблем с этим намного меньше. Но у того же just-js с библиотеками очень туго.
Дальше мои мысли:
1. Дешевой разработку на node.js (серверном джаваскрипте) делает обилие библиотек.
2. Если забыть об обилии библиотек, та же цена и скорость разработки у серверного js внезапно возрастает до уровня любого другого языка программирования.
А дальше начинается оптимизация стоимости владения, как верно подметил И-23. Плюс с учётом того, что js интерпретируемый, получаем проблему node_modules.
P.S. Кто-нибудь, возьмите меня на работу node.js-макакой.
А там ещё маячит главное правило.
Которое в силу описанной тенденции мещает очень много кому и потому существует по бОльшей части в форме устного предания.
Это да. Лично сталкивался с фактом, что про то, что npm install --global можно настроить на установку в пользовательскую директорию ($HOME) вместо системной (требующей root прав), знает три с половиной человека.
Это не говоря уже о более сложной задаче "инкапсулировать среду разработки от внесения изменений в систему", которая досейчас решается докер образами.
Тот самый npm — уже ересь!!!
И костыли недо-виртуалок в лице докера — это именно *костыли*.
Почему же. Является ли chroot костылём? Контейнеры – это такой chroot на максималках.
А так я исхожу из того, что контейнеры апприори небезопасны. В Гентувики, где описана установка Libreoffice через flatpak:
Предупреждение написал я (как и об остальном методе установки через flatpak).
Контейнеры разные бывают.
Левые комбайны — это одно.
Собранное же самостоятельно — совсем другое.
ЗЫ: А ты обратил внимание на то, как старательно пихают portable (тот же AppImage) на платформу GNU/Linux?.. ☹
Старая мечта Торвальдса, что протягивает уже лет 15. Надоело ему видите ли интерфейсы тянуть в ядре с 90 годов.
Можете развернуть мысль?
ЗЫ: Я исправил одно слово. Речь конечно о portable-формате ПО (вместо устанавливаемого)?
Ну проблема юзерспейса давно назрела. На конференция с Линусом Торвальдсом еще в 10-14 году это обсуждалось. Мейнтейнеры не хотят собирать пакеты на каждой системе отдельно, разработчики ядра(дистрибутивов) не могут договорится о стандартизации юзерспейса и поддерживать старые интерфейсы. Из-за этого вся эта хрень с AppImage и т д. Усложнение всего и вся рождает дополнительные уровни абстракции и чем дальше тем больше.
Я бы сказал, что дополнительные уровни абстракции порождаются невозможностью решения проблем (или задач) нижнего уровня.
Ну и самое печальное в отсутствии основополагающих вопросов: как (и почему) должна работать система?
ЗЫ: Интересно: сам Линус знаком с историей буржуазной лженауки?
Или ему стоит заслать книжку (для начала по-хорошему — томик с *оригиналом* курса лекций князя Кропоткина)? ☺
Почему ? Если уровни открыты, а не в виде черного ящика. Решать проблемы можно. Число шаманов, что умеют смотреть вглубь просто уменьшается )
Однако и Вы [примите пилюлю от антропоморфизьма [категории причинно-следственных связей]] ☺
Открытость — важная, вероятно даже необходимая, но далеко не единственная предпосылка.
Есть ещё *вектор* физических ограничений (начиная с Времени).
Вы помните подвиг Паскаля?
И, наглядной иллюстрацией, руководство господина Фокса?..
А что такое собранные самостоятельно ? ) 99,9% самостоятельно собранных контейнеров в верхней точке имеют пакет с докерхаба )
Докер я глубоко не ковырял, но имеется в виду, естественно, использование локального stage4.
Ну для себя я постановил: локальный реп, источники пакетов только официальные разработчики, а не дикие сборки.
Это нормально. Это проблемма многообразия дистрибутивов Linux.
Идея AppImage простая - собираемся с известным тебе набором версий библиотек и имеем стабильный код. Естественно при этом все библиотеки приходится таскать с собой.
Более того, могу сказать, что дистрибутивы приложений под Windows так-же таскают все библиотеки с собой, так что в каком-то смысле это те-же AppImage.
Минус - требуется много места, поэтому каждую мелкую утилиту в AppImage не запакуешь.
Это *не*нормально.
Хотя и является закономерным следствием упадка культуры разработки.
Ну это данность. Мы работаем на виртуальной машине, что живет на openBSD (intel). Ставим на этот процессор kvm. На kvm разворачиваем докер. А в докере запускаем программу написанную на erlang где считаем if 1==1 .... )
Настолько глубоко докер не щупал.
Но без детализации задачи всё равно гадания будут…
Хотя… видел я как-то сочинение в корпоративной сети на предмет сборки rpm-пакета…
Это больше не про докер это больше, что мы живем на такой огромной стопке абстракций, что appimage скромная вишенка на торте.
Однако я не про абстракциях, а о принципах и методах.
Начиная с Главного Правила и далее в направлении PMS.
Уже практически 20 лет значительная часть программ берет из системы .Net, Visual C++ Redistributable, библиотеки directx... и таких программ последнее время все больше и больше.
Самодостаточное прикладное ПО сейчас мало кто пишет.
В смысле: культура разделяемых библиотек, не смотря на все препоны, успешно вторгается в земли империи Билла Гейтца.
> настроить на установку в пользовательскую директорию ($HOME) вместо системной (требующей root прав)
вы прям щаз критикуете Ынтепрайзные решения! большая их часть органически не способна поставиться не из-под админа что под юниксами что под вендой. хотя в чуть менее чем 100% случаев она нафиг не надо для работы.
ну вот зачем админские права проге которая получает ввод по заранее заданным формочкам и потом просто выводит документ?
DRM, в простонародье -- DeRbMoCорян, остапа понесло.
«…главный прицып интырпрайза — просрать миллиарды и бояться чихнуть рядом, потомушо никто не знает, как это потом чинить» © #15518
ЗЫ: И это (по результатам наблюдения аудита что *сертифицированного* товарного решения в области СКЗИ, что адаптера СМЭВ) ни фига не смешно ☹
> вот зачем админские права проге которая получает ввод по заранее заданным формочкам и потом просто выводит документ?
ммммм....
1) поставить необходимые библиотеки (обновление Common Controls, обновления Windows, движок БД...)
2) поставить драйвера защиты от копирования
3) поставить ярлычки в меню пуск и на рабочий стол ВСЕМ пользователям
4) переписать (обновить) файлы, которые уже были установлены "под админом"
Наверное и другие есть возможные причины.
Кстати, лично меня дома наоборот раздражает тенденция всех программ ставиться в пользовательский профиль и плодиться под каждым пользователем независимо
Ересь!
Врагов Веры идентифицировать и *публично* (!) судить судом Святой Инквизиции!
1) прикладное ПО не должно обновлять систему... ни через систему обновления, ни через прямую замену системных библиотек... особо забавно, когда разное ПО требует разные версии одной системной библиотеки, несовместимые/слабосовместимые между собой.
2) установка драйвера должна быть отдельной программой. Вообще прикладное ПО и защитное ПО не должно идти в одном инсталяторе.
3) бывает
4) Спорное решение.
4) ничего не поделаешь, если люди платят за обновление, они ожидают совместимость... Да, было сделано плохо когда-то, так не даром энтерпрайз называют кровавым
1,2) т.е. вместо инсталлятора надо класть талмуд, как проинсталлировать систему вручную. При этом на одного админая у которого есть способности+время+желание разобраться в кишках (n+1)-й ему выданной на сопровождение программы будет 10 (если не 100) таких, кому это на хрен не надо (в лучшеи случае) + студентов за еду + сыночков главбуха. А всё что может быть понято неправильно - так и будет понято.
А продолжая эту дорогу, так и программы вообще не нужны, ведь они всего лишь делают то, что без них делали бы вручную. Разница между инсталлятором и вычислением орбиты Плутона - количественная.
Для нелюбителей же sudo apt-get install x давно есть виртуалки, докеры и флатпаки
Наглядная ситуация отрицания главного правила :)
Оно же (гл. правило) по экстремальному программированию -- инверсия контроля.
Редкий пользователь в своей жизни пользуется инверсией контроля.... :-(
А в целом IoC не уменьшает сложность, а размазывает её. При расширении и углублении IoC программа частично переползает в файлы настройки, перестаёт статически проверяться...
(тут любая статья про кромешный helloworld на паттернах и про иерархию тестов).
Да… Руководство господина Фокса к настоящему времени помнят не только лишь все… ☹
Если что, одной компании в России нужен JS-разработчик классический. В исходной вакансии - ведущий спец (от 200, наверное, белая) по Реакту, но, на мой взгляд, сойдёт и хороший миддл по Реакту, с опытом, с хуками. Меньше - просьба не предлагать. Удалёнка возможна и без проблем. Локация - в России, но компания международная из России.
Тогда удачи вам в поисках. Всем нужны мидлы и сеньёры, а вы попробуйте взять не просто джуна, а команду из джунов :)
Я бывш. DevOps инженер, сейчас всерьёз рассматриваю возможность пойти в джуны-бекендеры. На зарплату уже пофиг, главное, не скучать.
Вообще я тут вспоминаю эффект Даннинга-Крюгера.
Потому что мечтать о понимании авторами требований проблем из руководства господина Брукса было бы верхом наивности.
Кстати да, надо будет перечитать Брукса...
И Фокса. За компанию.
ЗЫ: Давеча в размышлениях на тему «что бы почитать» сунул нос в «Психбольницу в руках пациентов».
Бр-р-р…
Особой пикантности добавляет тот момент, что стирающий файлы у русских баг найден в бандле vue-cli, это при том что vue - полностью клиентская библиотека, ей на сервере в принципе делать нечего и к файлам он отношение не имеет - она просто помогает размещать куски текста и графики на веб-страницах. "Сами виноваты".
Это не баг, это — фича!
☺
и что делать-то? autoexec.bat удалять уже поздно? :))))))))
PMS в помощь!
С разворачиванием до общезначимости.
поздно! уже лет 20 как поздно!
как что делать? форк-бомбу делать, на исчерпание GDI-хэндлов!
Идеальна связка опенсорс-коммерческая поддержка.
Опенсорс - гарантия того, что разработчик не закроет тебе доступ по щелчку пальцев, да и локальные доработки реально возможны.
Коммерческая поддержка снимет головную боль по контролю за проблемами. Понятно, что он должна быть адекватной, в нашем случае - российской (полу)государственной.
Однако было бы наивно полагать, что проприетарщина обходится без экологической ниши интеграторов (которые тоже любят мазать на хлебушек маслице, не забывая об икорочке).
Цифровая звуковая рабочая станция Ardour продаётся за деньги, хотя она опенсорсная и в той же генте ставится из пакетного менеджера.
Поздно.
man 8 lmf
Встроенные в программы бэкдоры , трояны и вирусы - это угроза универсальная.
От нее надо защищаться независимо от источника кода.
Т.е. должно существовать какое-то гос-предприятие (под крышей ФСБ) которое этим и занимается - анализом всего кода используемого в стране.
На коммерческой основе или в обязательном порядке, с выдачей лицензий и сертификатов безопасности - это уже вопрос обсуждения.
Но оно нужно также как пожарные службы, сан.эпид.станции, полиция и прочие конторы отвечающие за всевозможную безопасность.
Вспомните руководство господина Фокса («Программное обеспечение и его разработка»).
Страницы