Comments 74
У всех все работает, у него не работает, и ктот-то в этом виноват.
Нет я абсолютно согласен что надо развивать абсолютно новые
системы сборки, пакетов и графические сервера, оконные системы и все тому подобное.
Но в тоже время есть хороший так бородоатый анекдот:
Нет я абсолютно согласен что надо развивать абсолютно новые
системы сборки, пакетов и графические сервера, оконные системы и все тому подобное.
Но в тоже время есть хороший так бородоатый анекдот:
Сын подходит к папе-программисту и спрашивает, а почему солнце всходит на востоке, а заходит на западе?
Папа, не отрываясь от компьютера,
— Что, действительно восходит на востоке?
— Да.
— А заходит на западе?
— Да.
— И что, каждый день?
— Да.
— Тогда ради бога ничего не трогай.
Статья как раз о том, что «работоспособность» — не единственный критерий оценки.
Согласен на все 100%! Например есть программа, и программист «сэкономил» полдня своей работы на оптимизации. Теперь пользователи тратят на несколько минут в день больше времени. Каждый день. Каждый пользователь (а их тысячи).
«Не ну а чо? РАБОТАЕТ ЖЕ!»
«Не ну а чо? РАБОТАЕТ ЖЕ!»
Видимо в ТЗ не оговорили скорость работы приложения, соотвественно программист и не стал заниматься оптимизацией.
UFO just landed and posted this here
Программисты все ленивые в той или иной степени, по себе знаю, надо точнее задачи указывать, тогда не надо будет планки памяти докупать и смотреть на тормозящее приложение. Зачем оптимизировать и тратить время/деньги, если в ТЗ не указано что приложение должно летать на первом пентиуме. Но в крайности тоже впадать не стоит и если hello world томозит на современной машине и тратить пару гигов памяти, то у меня плохие новости о ваших программистах.
Я в первый раз когда услышал этот анекдот, решил что буду рассказывать это про сисадминов. Ибо программисты как раз скажут «А давайте зарефакторим!».
угу, у сисадминов даж поговорка такая есть — «работает — не ремонтируй!»
про прогеров не знаю но м.б.
про прогеров не знаю но м.б.
Программист программисту рознь… Года 4-5 назад я бы сказал про рефакторинг, а нынче — работает и лучше не трогать, но обновлять/дополнять по мере необходимости надо. Рефакториг — это трата кучи времени. Удобнее разбивать крупные проекты на логические не связанные особо между собой блоки и потихоньку улучшать их, не влияя на всю систему в целом.
Один мой коллега всегда говорил — «не чини, оно само сломается» =)
«Шанс всё исправить» ©
Внезапно, autoconf с проверками stdlib.h и т.д. не раз помогал мне разобраться с проблемами при работе с mingw. Вот вам и 20 лет «все юниксы умеют». Все юниксы умеют — а windows — нет.
Тогда, соответственно, можно выкидывать тесты, когда более-менее очевиден результат их исполнения, типа
if [ $(uname) = 'Linux' ]; then
…
elif [ $(uname -o) = 'Cygwin' ]; then
…
else
…
fi
if [ $(uname) = 'Linux' ]; then
…
elif [ $(uname -o) = 'Cygwin' ]; then
…
else
…
fi
У автора ещё есть заметка, более ранняя и более грубая (бомбануло).
www.varnish-cache.org/docs/2.1/phk/autocrap.html — «Did you call them autocrap tools ?»
Он как раз и говорит, что когда-нибудь выпилит этиавтотулзы автох*цы, оставив лишь достаточное
www.varnish-cache.org/docs/2.1/phk/autocrap.html — «Did you call them autocrap tools ?»
Он как раз и говорит, что когда-нибудь выпилит эти
uname -s
Одного uname недостаточно, к сожалению. С другой стороны, configure-файлы постоянно мешают переносу программ с одной платформы на другую.
ЕМНИП, configure сами генерируются обычно. из configure.ac.
Только в случае использования autoconf.
Для подавляющего количества более-менее популярных программ это так. Стандартное ./configure; make; make install
Кстати, в последнее время это все чаще cmake. && make && make install.
Хорошо если так, а то ещё
aclocal --install --force когда с макросами проблемки.Во, в 2011 писал один незамысловатый мануал, идеальный пример анархии.
~$ git clone git://gitorious.org/vala-toys/vala-toys.git
~$ cd vala-toys
# Начинается уличная магия, потому что автор VTG -- редиска.
# Без ChangeLog не будет работать automake
~$ touch ChangeLog
# Ручками создадим правильный 'po/Makefile.am'
~$ echo -e "# INTLTOOL_MAKEFILE" > po/Makefile.am
# И поправим путь в 'configure.ac'
~$ sed -i -e "s|po/Makefile.in|po/Makefile|" configure.ac
# Генерируем конфиг
~$ aclocal && autoconf
# Чиним & генерируем Makeфайлы
~$ automake --add-missing
# Дальше всё пучком
~$ PKG_CONFIG_PATH=/Users/xlab/gtk/inst/lib/pkgconfig/:/usr/local/lib/pkgconfig/ CFLAGS="-arch i386 -I /Users/xlab/gtk/inst/include" ./configure --disable-vtg-plugin
~$ make -j4
~$ sudo make install
По-моему, мы вот-вот изобретём макроязык для генерации макросов для autoconf.
Внезапно, это mingw, а не cygwin.
Вот не знаю что я делаю неправильно, но у меня под виндой mingw вообще без проблем работает.
Автор цитаты в начале статьи все-таки Фредерик Филлипс Брукс, правильней будет Фредерик Ф. Брукс
Причем здесь вообще autotools? Разве не поколение этого самого «собора» их написало?
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.
Причем здесь вообще autotools? Разве не поколение этого самого «собора» их написало?
Проблема не в том, кто написал. Проблема в том, что использование этого костыля превратилось в норму. Т.е. все признают, что это бред, но до сих пор никто не решился исправить, потому что «работает и ладно». Даже Netscape, к примеру, прежде чем стать Mozilla, был переписан с нуля.
Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью?
Отвечу цитатой от автора:
Если бы подобное игнорирование методологии повторного использования воплотилось бы в виде механизма самодостаточных и независимых пакетов с ПО, тогда был бы компромисс между дубликацией кода и лёгкостью управления пакетами. Но это явно не наш случай — пакеты образуют запутанную паутину из бессистемных зависимостей, что приводит к ещё большей дубликации кода и бесполезной трате ресурсов.
Так автор ратует за базар или собор? :)
За базар ратовал Рэймонд. Этот явно против базара, но
у соборов свой букет проблем. Короче говоря, автор недоволен тем, что некоторые вообще не знают ничего о соборах.
Matt, My point is not that there are no cathedrals today, but that people don't recognize them as such or see any value in them.
philip andrew, Mark and others: I'm not arguing that cathedrals is a better solution, they are certainly not without their own kind of problems. What I'm pointing out that is people like @iain don't even know what they are in the first place.
у соборов свой букет проблем. Короче говоря, автор недоволен тем, что некоторые вообще не знают ничего о соборах.
Любая система — в той или иной мере костыль. Autotools — не самый ужасный костыль из существующих, если разобраться, и не такой уж и «бред». И почему вы говорите, что никто не решится исправить? Существуют альтернативные системы сборки (cmake и прочие), и вполне хорошо себя чувствуют.
Не понимаю, где здесь игнорирование методологии повторного использования?
Если бы подобное игнорирование методологии повторного использования...
Не понимаю, где здесь игнорирование методологии повторного использования?
Autotools — не самый ужасный костыль из существующихАууууумммм… спорно. Во всяком случае, я конечно не хочу страдать из-за солидарности с автором оригинального опуса, но моё личное мнение частично совпадает, потому что вдоволь наигрался со всем этим сам.
CMake генерирует Makefile. С общепризнанными проблемами make можно ознакомиться по ссылкам в начале этой статьи: habrahabr.ru/post/144127/ (статья про QBS).
Не понимаю, где здесь игнорирование методологии повторного использования?Игнорирование было про 1 342 копипасты криптографических алгоритмов, а цитату я привёл в тему изолированных пакетов. Раз нам пофиг на место на диске, то можно было бы сделать как в OS X — изолированные пакеты со своими копиями библиотек. Это бы избавило нас от кучи проблем с совместимостью и упростило бы процесс управления пакетами.
CMake генерирует Makefile. С общепризнанными проблемами make можно ознакомиться по ссылкам в начале этой статьи: habrahabr.ru/post/144127/ (статья про QBS).
Я в курсе проблем make, спасибо. У любой системы сборки есть проблемы, и идеальной системы никогда не будет. Или вы думаете, что переписав все с нуля, у вас таковая получится? Максимализм в сфере разработки ПО обычно не приводит к положительным результатам.
Игнорирование было про 1 342 копипасты криптографических алгоритмов, а цитату я привёл в тему изолированных пакетов. Раз нам пофиг на место на диске, то можно было бы сделать как в OS X — изолированные пакеты со своими копиями библиотек.
Вот только не надо бросаться из крайности в крайность.
Про 1342 копипасты криптоалгоритмов: наверняка речь про какие-нибудь простые хеш-функции. Реализация MD5 или SHA256 занимает около сотни строк, и линковаться с отдельной динамической библиотекой только ради того, чтобы уметь вычислять хеш, не очень целесообразно. И вряд ли вам когда-либо понадобится обновить версию такой библиотеки — MD5 он и есть MD5, нечего там обновлять.
Согласитесь, есть разница между копированием себе в проект 100-строчной функции, вычисляющей MD5-хеш, и включением в пакет своей версии библиотеки Gtk3. Никто не предлагает делать последнее.
А можно Вам возразить? :)
CMake генерирует не только Makefile:
% cmake --help | grep -A15 Generators
Generators
The following generators are available on this platform:
Ninja = Generates build.ninja files (experimental).
Unix Makefiles = Generates standard UNIX makefiles.
CodeBlocks — Ninja = Generates CodeBlocks project files.
CodeBlocks — Unix Makefiles = Generates CodeBlocks project files.
Eclipse CDT4 — Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 — Unix Makefiles
= Generates Eclipse CDT 4.0 project files.
KDevelop3 = Generates KDevelop 3 project files.
KDevelop3 — Unix Makefiles = Generates KDevelop 3 project files.
Например, Ninja обещает быть идеальной билдсистемой, но на данный момент — не то, чтобы очень популярен.
CMake генерирует не только Makefile:
% cmake --help | grep -A15 Generators
Generators
The following generators are available on this platform:
Ninja = Generates build.ninja files (experimental).
Unix Makefiles = Generates standard UNIX makefiles.
CodeBlocks — Ninja = Generates CodeBlocks project files.
CodeBlocks — Unix Makefiles = Generates CodeBlocks project files.
Eclipse CDT4 — Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 — Unix Makefiles
= Generates Eclipse CDT 4.0 project files.
KDevelop3 = Generates KDevelop 3 project files.
KDevelop3 — Unix Makefiles = Generates KDevelop 3 project files.
Например, Ninja обещает быть идеальной билдсистемой, но на данный момент — не то, чтобы очень популярен.
Проблема в том, что никто не может решить, что теперь все должно собираться с помощью X. В разное время было множество систем сборок: make, imake, cmake, qmake. Наверняка я еще много чего не вспомнил.
Проблема в том, что некоторые утилиты требует других компонентов, которые им совершенно не надо.
И в результате монстр типа Firefox обрастает сотнями зависимостей, из которых треть НЕ используется.
И в результате монстр типа Firefox обрастает сотнями зависимостей, из которых треть НЕ используется.
Треть — не такие уж и большие накладные расходы. Веб-браузер — действительно очень сложная система, и на мой взгляд, такой длинный список зависимостей вполне оправдан.
В Gentoo для этого есть USE-флаги, чтобы отсеивать ненужные зависимости или наоборот включать отключенные по умолчанию. Однако ж и там частенько бывают проблемы с конфликтами версий и циркулярными зависимостями.
UFO just landed and posted this here
Не нравится autoconf — перепиши её.
Только потом про поддержку своей программы не забывай.
Только потом про поддержку своей программы не забывай.
Мир вообще не идеален, и многие стандарты являются стандартами просто потому что — помните же про космос и ширину лошадиной задницы?
А еще можно вспомнить про архитектуру x86, которая вообще костыль на костыле. Ну и что? Нас поработили ARMы?
А еще можно вспомнить про архитектуру x86, которая вообще костыль на костыле. Ну и что? Нас поработили ARMы?
Деннис Ритчи поразил своим ответом, ответ батьки. Двумя библейскими цитатами, из Нового и Старого заветов, не в бровь а в глаз.
Здорово же написано. :) Хочется читать Брукса и думать.
p.s. как-то мне надо было собрать утилиты для работы с osm данными. Выглядело это следующим образом:
p.s. как-то мне надо было собрать утилиты для работы с osm данными. Выглядело это следующим образом:
wget -O - http://m.m.i24.cc/osmfilter.c | cc -x c - -O3 -o osmfilter
wget -O - http://m.m.i24.cc/osmconvert.c | cc -x c - -lz -O3 -o osmconvert
wget -O - http://m.m.i24.cc/osmupdate.c | cc -x c - -o osmupdate
В начале статьи — цитата про
Дальше идет текст автора про установленную у него dev-версию FreeBSD. У меня одного диссонанс?
Linux — удивительная система. Бла-бла-бла Linux.
Дальше идет текст автора про установленную у него dev-версию FreeBSD. У меня одного диссонанс?
У вас одного, потому что перед цитатой про Linux указано следующее:
В своей заметке автор использует метафору собора и базара, описанную в эссе Эрика Рэймонда «Собор и базар», я нахожу уместным привести отрывок из текста признанного перевода эссе:Короче говоря, я вставил отрывок другой книги другого чувака, на которого ссылался автор неоднократно.
Это главный недостаток OpenSource — его крайне сложно стандартизировать. Потому что разработчиков масса, каждый тянет одеяло на себя, а исходники открыты, и нет никакой возможности навязать всем единое мнение (в случае чего несогласные могут состряпать форк).
Именно поэтому кривая, корявая технология, но с единым хозяином, достаточно сильным, чтобы продавить своё технологическое видение, многократно лучше архитектурно красивой технологии, но с кучей быстро меняющихся владельцев или вообще бесхозной.
Именно поэтому кривая, корявая технология, но с единым хозяином, достаточно сильным, чтобы продавить своё технологическое видение, многократно лучше архитектурно красивой технологии, но с кучей быстро меняющихся владельцев или вообще бесхозной.
Проблема появилась еще до становления движения за открытое обеспечение.
POSIX — то что должно бы стандартизировать на самом деле узаконило 1000 костылей и несовместимостей реализаций Unix между собой, а Linux чтобы иметь возможность переисспользовать уже существующие наработки, должен был большую часть этого стандарта и сообтветственно костылей переисспользовать.
POSIX — то что должно бы стандартизировать на самом деле узаконило 1000 костылей и несовместимостей реализаций Unix между собой, а Linux чтобы иметь возможность переисспользовать уже существующие наработки, должен был большую часть этого стандарта и сообтветственно костылей переисспользовать.
Основной тезис статьи можно сформулировать коротко: «надо отвечать за базар!»
С точки зрения «здравой, критической, логики» статья — просто эпическое нечто!
Во-первых, господин Брукс занимается уж слишком неприкрытой софистикой. И порой эта софистика настолько «топорна», что просто бросается в глаза. Вот скажите, как?! Как простите, это понимать сие утверждение:
> Мы не можем отрицать, что вся эра доткомов явилась настоящим бедствием для IT/CS индустрии в целом и для UNIX в частности. Под удар попало качество программных продуктов.
Даже школьнику, если у него «в порядке с логикой» известно: «После чего-то – не значит вследствие чего-то». И неужели «умный дядька» считает читателей настолько тупыми?
Если Брукс действительно хотел бы обсудить падение качества, то, ему как минимум, надо было бы сказать, что у «падения качества программных продуктов», может быть огромная масса причин. Которые бы, всем интересно было обсудить, но Брукс об этом как-то неудосуживается.
Вот, например, армия всяких «менеджеров» и «маркетологов», пытающаяся управлять технологическим процессом software-developmentа, в котором они нифига не понимают? Чем не причина падения качества?
А модные технологии так называемого «экстремального программирования» разве не причина? Да, в теории мы красиво и громко декларируем «готовность подстраиваться под любые изменения требований заказчика», а на практике мы умышленно погружаем проект в состояние «бесконечных доделок», служащих только для одного — высасывания по-максимуму бюджета из заказчика. И скажите мне, положа руку на сердце, уважаемые «экстремальные программисты», разве это не так ;)
А незнание поговорки «скупой платит дважды» (aka привет «индусскому говнокоду») — не причина?
Я могу привести еще пару десятков причин… Но Брукс говорит, что качество падает потому что… потому что… оно начало падать еще в дотком-эру! И вообще, обратите внимание, сначала громко упоминает «базар», а потом плавно «соскакивает с темы» (!)
Далее, Брукс пытается пытается читателя «водить за нос», но делает это слишком неуклюже, подкидывая кучу логически слабо-связанных фактов, расчитанных только для того, чтобы произвести у читателя «эмоциональный отклик». (А у параноика в голове сразу же звенит звоночек: налицо психологическое манипулирование, причем грубое и неумелое).
Но, если попытаться прочитать статью не «эмоционально», а логически, то видно, что автор порой сам себе противоречит. Сначала он жалуется на «ад зависимостей» (типа, ай-яй-яй, такой-сякой firefox тянет за собой аж целых 122 пакета во FreeBSD), а потом тут же яростно критикует «копипасту». И кстати, что за «однобокая подача фактов» — приводит пример из FreeBSD, но почему-то стесняется сказать о том, что есть и успешные примеры решений подобных вещей, например в Gentoo.
Затем автор и вообще занимается косплеем Капитана Очевидности: типа, дорогие мои детки, autoconf, оказывается «костыль». А то, мы-то без него-то и не знали, что autoconf костыль (кстати, костыль служащий для решения вполне определенных задач, и имеющий свои плюсы и минусы).
А вообще, СТОП, кто-нибудь обьяснит, какая вообще _логическая_ _связь_ между «застрявшим на базаре поколением», с которого Брукс начал свой рассказ, и в которое он записал все программерское-айтишное население от 50 до 20 лет и особенности работы autoconf-а? Кстати, а что с темой «качества ПО» — то же самое — сначала «громкий вброс», а затем мутный уход от темы?
Не знаю как у вас, у меня с первых строк возник вопрос: а «на чью мельницу воду льет» автор? Читая статью, я просто ждал, когда же он наконец начнет «впаривать», когда же наконец, прозвучит «покупайте наших слонов»;)
И вот, подконец, (прочитав всю охинею в которой терятся логическая нить) [торжественно звучат фанфары] и оказывается, по мнению Брукса, «Шанс ВСЁ Исправить» — это ВНЕЗАПНО новый формат пакетов Ubuntu а еще QT! Получается прямо таки «серебрянная пуля» способная Исправить ВСЕ.
Не знаю как Вам, дорогие хабраюзеры, но мне очень хочется спросить у господина Брукса: Если новый формат пакетов Ubuntu, настолько «чудотворный», что способен даже исправить все-все последствия«шальных девяностых» «эры темного доткома», то может быть он и от хронического гайморита помогает (если «новый формат Ubuntu-пакетов вместе с QT принимать три раза в день до еды»)?
Во-первых, господин Брукс занимается уж слишком неприкрытой софистикой. И порой эта софистика настолько «топорна», что просто бросается в глаза. Вот скажите, как?! Как простите, это понимать сие утверждение:
> Мы не можем отрицать, что вся эра доткомов явилась настоящим бедствием для IT/CS индустрии в целом и для UNIX в частности. Под удар попало качество программных продуктов.
Даже школьнику, если у него «в порядке с логикой» известно: «После чего-то – не значит вследствие чего-то». И неужели «умный дядька» считает читателей настолько тупыми?
Если Брукс действительно хотел бы обсудить падение качества, то, ему как минимум, надо было бы сказать, что у «падения качества программных продуктов», может быть огромная масса причин. Которые бы, всем интересно было обсудить, но Брукс об этом как-то неудосуживается.
Вот, например, армия всяких «менеджеров» и «маркетологов», пытающаяся управлять технологическим процессом software-developmentа, в котором они нифига не понимают? Чем не причина падения качества?
А модные технологии так называемого «экстремального программирования» разве не причина? Да, в теории мы красиво и громко декларируем «готовность подстраиваться под любые изменения требований заказчика», а на практике мы умышленно погружаем проект в состояние «бесконечных доделок», служащих только для одного — высасывания по-максимуму бюджета из заказчика. И скажите мне, положа руку на сердце, уважаемые «экстремальные программисты», разве это не так ;)
А незнание поговорки «скупой платит дважды» (aka привет «индусскому говнокоду») — не причина?
Я могу привести еще пару десятков причин… Но Брукс говорит, что качество падает потому что… потому что… оно начало падать еще в дотком-эру! И вообще, обратите внимание, сначала громко упоминает «базар», а потом плавно «соскакивает с темы» (!)
Далее, Брукс пытается пытается читателя «водить за нос», но делает это слишком неуклюже, подкидывая кучу логически слабо-связанных фактов, расчитанных только для того, чтобы произвести у читателя «эмоциональный отклик». (А у параноика в голове сразу же звенит звоночек: налицо психологическое манипулирование, причем грубое и неумелое).
Но, если попытаться прочитать статью не «эмоционально», а логически, то видно, что автор порой сам себе противоречит. Сначала он жалуется на «ад зависимостей» (типа, ай-яй-яй, такой-сякой firefox тянет за собой аж целых 122 пакета во FreeBSD), а потом тут же яростно критикует «копипасту». И кстати, что за «однобокая подача фактов» — приводит пример из FreeBSD, но почему-то стесняется сказать о том, что есть и успешные примеры решений подобных вещей, например в Gentoo.
Затем автор и вообще занимается косплеем Капитана Очевидности: типа, дорогие мои детки, autoconf, оказывается «костыль». А то, мы-то без него-то и не знали, что autoconf костыль (кстати, костыль служащий для решения вполне определенных задач, и имеющий свои плюсы и минусы).
А вообще, СТОП, кто-нибудь обьяснит, какая вообще _логическая_ _связь_ между «застрявшим на базаре поколением», с которого Брукс начал свой рассказ, и в которое он записал все программерское-айтишное население от 50 до 20 лет и особенности работы autoconf-а? Кстати, а что с темой «качества ПО» — то же самое — сначала «громкий вброс», а затем мутный уход от темы?
Не знаю как у вас, у меня с первых строк возник вопрос: а «на чью мельницу воду льет» автор? Читая статью, я просто ждал, когда же он наконец начнет «впаривать», когда же наконец, прозвучит «покупайте наших слонов»;)
И вот, подконец, (прочитав всю охинею в которой терятся логическая нить) [торжественно звучат фанфары] и оказывается, по мнению Брукса, «Шанс ВСЁ Исправить» — это ВНЕЗАПНО новый формат пакетов Ubuntu а еще QT! Получается прямо таки «серебрянная пуля» способная Исправить ВСЕ.
Не знаю как Вам, дорогие хабраюзеры, но мне очень хочется спросить у господина Брукса: Если новый формат пакетов Ubuntu, настолько «чудотворный», что способен даже исправить все-все последствия
Брукс здесь не при чём, автор сего опуса — Poul-Henning Kamp.
(это я на всякий случай пояснил)
А вообще да, с темы на тему скачет, я специально заголовки сам придумал, чтобы читатели не упоролись от полёта мысли.
(это я на всякий случай пояснил)
А вообще да, с темы на тему скачет, я специально заголовки сам придумал, чтобы читатели не упоролись от полёта мысли.
и оказывается, по мнению Брукса, «Шанс ВСЁ Исправить» — это ВНЕЗАПНО новый формат пакетов Ubuntu а еще QT!Чуть чуть внимательнее посмотрите концовку — там Пол говорит, что с точки зрения Брукса у нас не всё потеряно. Затем перевод заканчивается и я дописал от себя абзац с двумя ссылками, которые появились в интернете совсем недавно. На мой взгляд, это отличная иллюстарция того самого шанса исправить ад сборок и ад зависимостей.
Новый формат пакетов не более чем еще один формат пакетов, а на qt разве пишут без зависимостей?
Новый формат пакетов не более чем еще один формат пакетовЭто невежество. Если статья на OpenNet не очень чётко объясняет суть, то вот на хабре писали про это в более простой форме и разница налицо. habrahabr.ru/post/179751/
а на qt разве пишут без зависимостей?Речь не о самих зависимостях, а о способе подготовки к линковке с ними.
А кто-нибудь кроме меня читал Мифический человеко-месяц (Брукса)? Прекрасная книга! (простите за оффтоп)
Эх, батенька, не понимаете вы смысла фразы «UNIX-way»… Вот из-за такого непонимания и получается всякий ужас вроде systemd и бубунто-пакетных менеджеров, что мало-помалу приближает так называемый «линуксокапец» и делает единственным светом в окошке BSD (которую некоторые уже давно для себя закопали).
Кстати, autotools — действительно тормозное и устаревшее поделие, cmake намного удобней!
Кстати, autotools — действительно тормозное и устаревшее поделие, cmake намного удобней!
Sign up to leave a comment.
Поколение, затерянное на базаре