Comments 74
У всех все работает, у него не работает, и ктот-то в этом виноват.
Нет я абсолютно согласен что надо развивать абсолютно новые
системы сборки, пакетов и графические сервера, оконные системы и все тому подобное.
Но в тоже время есть хороший так бородоатый анекдот:
Нет я абсолютно согласен что надо развивать абсолютно новые
системы сборки, пакетов и графические сервера, оконные системы и все тому подобное.
Но в тоже время есть хороший так бородоатый анекдот:
Сын подходит к папе-программисту и спрашивает, а почему солнце всходит на востоке, а заходит на западе?
Папа, не отрываясь от компьютера,
— Что, действительно восходит на востоке?
— Да.
— А заходит на западе?
— Да.
— И что, каждый день?
— Да.
— Тогда ради бога ничего не трогай.
+13
Статья как раз о том, что «работоспособность» — не единственный критерий оценки.
+31
Согласен на все 100%! Например есть программа, и программист «сэкономил» полдня своей работы на оптимизации. Теперь пользователи тратят на несколько минут в день больше времени. Каждый день. Каждый пользователь (а их тысячи).
«Не ну а чо? РАБОТАЕТ ЖЕ!»
«Не ну а чо? РАБОТАЕТ ЖЕ!»
+1
Видимо в ТЗ не оговорили скорость работы приложения, соотвественно программист и не стал заниматься оптимизацией.
+1
UFO just landed and posted this here
Программисты все ленивые в той или иной степени, по себе знаю, надо точнее задачи указывать, тогда не надо будет планки памяти докупать и смотреть на тормозящее приложение. Зачем оптимизировать и тратить время/деньги, если в ТЗ не указано что приложение должно летать на первом пентиуме. Но в крайности тоже впадать не стоит и если hello world томозит на современной машине и тратить пару гигов памяти, то у меня плохие новости о ваших программистах.
0
Я в первый раз когда услышал этот анекдот, решил что буду рассказывать это про сисадминов. Ибо программисты как раз скажут «А давайте зарефакторим!».
+15
угу, у сисадминов даж поговорка такая есть — «работает — не ремонтируй!»
про прогеров не знаю но м.б.
про прогеров не знаю но м.б.
0
Программист программисту рознь… Года 4-5 назад я бы сказал про рефакторинг, а нынче — работает и лучше не трогать, но обновлять/дополнять по мере необходимости надо. Рефакториг — это трата кучи времени. Удобнее разбивать крупные проекты на логические не связанные особо между собой блоки и потихоньку улучшать их, не влияя на всю систему в целом.
0
Один мой коллега всегда говорил — «не чини, оно само сломается» =)
0
«Шанс всё исправить» ©
+38
Внезапно, autoconf с проверками stdlib.h и т.д. не раз помогал мне разобраться с проблемами при работе с mingw. Вот вам и 20 лет «все юниксы умеют». Все юниксы умеют — а windows — нет.
+23
Тогда, соответственно, можно выкидывать тесты, когда более-менее очевиден результат их исполнения, типа
if [ $(uname) = 'Linux' ]; then
…
elif [ $(uname -o) = 'Cygwin' ]; then
…
else
…
fi
if [ $(uname) = 'Linux' ]; then
…
elif [ $(uname -o) = 'Cygwin' ]; then
…
else
…
fi
-1
У автора ещё есть заметка, более ранняя и более грубая (бомбануло).
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
+5
Одного uname недостаточно, к сожалению. С другой стороны, configure-файлы постоянно мешают переносу программ с одной платформы на другую.
+1
ЕМНИП, configure сами генерируются обычно. из configure.ac.
+1
Только в случае использования autoconf.
0
Для подавляющего количества более-менее популярных программ это так. Стандартное ./configure; make; make install
0
Кстати, в последнее время это все чаще cmake. && make && make install.
0
Хорошо если так, а то ещё
aclocal --install --force
когда с макросами проблемки.0
Во, в 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
+3
По-моему, мы вот-вот изобретём макроязык для генерации макросов для autoconf.
+3
Внезапно, это mingw, а не cygwin.
+1
Вот не знаю что я делаю неправильно, но у меня под виндой mingw вообще без проблем работает.
0
Автор цитаты в начале статьи все-таки Фредерик Филлипс Брукс, правильней будет Фредерик Ф. Брукс
+2
Причем здесь вообще autotools? Разве не поколение этого самого «собора» их написало?
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.
И что плохого в том, что firefox требует libtiff? Он же не напрямую требует, а через цепочку типа firefox -> gtk -> libtiff. Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью? То, что автор собирает всю систему из исходников вместо бинарных пакетов, — его личные проблемы.
+6
Причем здесь вообще autotools? Разве не поколение этого самого «собора» их написало?
Проблема не в том, кто написал. Проблема в том, что использование этого костыля превратилось в норму. Т.е. все признают, что это бред, но до сих пор никто не решился исправить, потому что «работает и ладно». Даже Netscape, к примеру, прежде чем стать Mozilla, был переписан с нуля.
Места на жестком диске нынче всем хватает, так почему бы не установить все пакеты с максимальной функциональностью?
Отвечу цитатой от автора:
Если бы подобное игнорирование методологии повторного использования воплотилось бы в виде механизма самодостаточных и независимых пакетов с ПО, тогда был бы компромисс между дубликацией кода и лёгкостью управления пакетами. Но это явно не наш случай — пакеты образуют запутанную паутину из бессистемных зависимостей, что приводит к ещё большей дубликации кода и бесполезной трате ресурсов.
+4
Так автор ратует за базар или собор? :)
-1
За базар ратовал Рэймонд. Этот явно против базара, но
у соборов свой букет проблем. Короче говоря, автор недоволен тем, что некоторые вообще не знают ничего о соборах.
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.
у соборов свой букет проблем. Короче говоря, автор недоволен тем, что некоторые вообще не знают ничего о соборах.
+3
Любая система — в той или иной мере костыль. Autotools — не самый ужасный костыль из существующих, если разобраться, и не такой уж и «бред». И почему вы говорите, что никто не решится исправить? Существуют альтернативные системы сборки (cmake и прочие), и вполне хорошо себя чувствуют.
Не понимаю, где здесь игнорирование методологии повторного использования?
Если бы подобное игнорирование методологии повторного использования...
Не понимаю, где здесь игнорирование методологии повторного использования?
+1
Autotools — не самый ужасный костыль из существующихАууууумммм… спорно. Во всяком случае, я конечно не хочу страдать из-за солидарности с автором оригинального опуса, но моё личное мнение частично совпадает, потому что вдоволь наигрался со всем этим сам.
CMake генерирует Makefile. С общепризнанными проблемами make можно ознакомиться по ссылкам в начале этой статьи: habrahabr.ru/post/144127/ (статья про QBS).
Не понимаю, где здесь игнорирование методологии повторного использования?Игнорирование было про 1 342 копипасты криптографических алгоритмов, а цитату я привёл в тему изолированных пакетов. Раз нам пофиг на место на диске, то можно было бы сделать как в OS X — изолированные пакеты со своими копиями библиотек. Это бы избавило нас от кучи проблем с совместимостью и упростило бы процесс управления пакетами.
+5
CMake генерирует Makefile. С общепризнанными проблемами make можно ознакомиться по ссылкам в начале этой статьи: habrahabr.ru/post/144127/ (статья про QBS).
Я в курсе проблем make, спасибо. У любой системы сборки есть проблемы, и идеальной системы никогда не будет. Или вы думаете, что переписав все с нуля, у вас таковая получится? Максимализм в сфере разработки ПО обычно не приводит к положительным результатам.
Игнорирование было про 1 342 копипасты криптографических алгоритмов, а цитату я привёл в тему изолированных пакетов. Раз нам пофиг на место на диске, то можно было бы сделать как в OS X — изолированные пакеты со своими копиями библиотек.
Вот только не надо бросаться из крайности в крайность.
Про 1342 копипасты криптоалгоритмов: наверняка речь про какие-нибудь простые хеш-функции. Реализация MD5 или SHA256 занимает около сотни строк, и линковаться с отдельной динамической библиотекой только ради того, чтобы уметь вычислять хеш, не очень целесообразно. И вряд ли вам когда-либо понадобится обновить версию такой библиотеки — MD5 он и есть MD5, нечего там обновлять.
Согласитесь, есть разница между копированием себе в проект 100-строчной функции, вычисляющей MD5-хеш, и включением в пакет своей версии библиотеки Gtk3. Никто не предлагает делать последнее.
+2
А можно Вам возразить? :)
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 обещает быть идеальной билдсистемой, но на данный момент — не то, чтобы очень популярен.
0
Проблема в том, что никто не может решить, что теперь все должно собираться с помощью X. В разное время было множество систем сборок: make, imake, cmake, qmake. Наверняка я еще много чего не вспомнил.
0
Проблема в том, что некоторые утилиты требует других компонентов, которые им совершенно не надо.
И в результате монстр типа Firefox обрастает сотнями зависимостей, из которых треть НЕ используется.
И в результате монстр типа Firefox обрастает сотнями зависимостей, из которых треть НЕ используется.
+1
Треть — не такие уж и большие накладные расходы. Веб-браузер — действительно очень сложная система, и на мой взгляд, такой длинный список зависимостей вполне оправдан.
0
В Gentoo для этого есть USE-флаги, чтобы отсеивать ненужные зависимости или наоборот включать отключенные по умолчанию. Однако ж и там частенько бывают проблемы с конфликтами версий и циркулярными зависимостями.
+1
UFO just landed and posted this here
Не нравится autoconf — перепиши её.
Только потом про поддержку своей программы не забывай.
Только потом про поддержку своей программы не забывай.
-4
Мир вообще не идеален, и многие стандарты являются стандартами просто потому что — помните же про космос и ширину лошадиной задницы?
А еще можно вспомнить про архитектуру x86, которая вообще костыль на костыле. Ну и что? Нас поработили ARMы?
А еще можно вспомнить про архитектуру x86, которая вообще костыль на костыле. Ну и что? Нас поработили ARMы?
+4
Деннис Ритчи поразил своим ответом, ответ батьки. Двумя библейскими цитатами, из Нового и Старого заветов, не в бровь а в глаз.
+8
Здорово же написано. :) Хочется читать Брукса и думать.
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
+3
В начале статьи — цитата про
Дальше идет текст автора про установленную у него dev-версию FreeBSD. У меня одного диссонанс?
Linux — удивительная система. Бла-бла-бла Linux.
Дальше идет текст автора про установленную у него dev-версию FreeBSD. У меня одного диссонанс?
-1
У вас одного, потому что перед цитатой про Linux указано следующее:
В своей заметке автор использует метафору собора и базара, описанную в эссе Эрика Рэймонда «Собор и базар», я нахожу уместным привести отрывок из текста признанного перевода эссе:Короче говоря, я вставил отрывок другой книги другого чувака, на которого ссылался автор неоднократно.
+2
Это главный недостаток OpenSource — его крайне сложно стандартизировать. Потому что разработчиков масса, каждый тянет одеяло на себя, а исходники открыты, и нет никакой возможности навязать всем единое мнение (в случае чего несогласные могут состряпать форк).
Именно поэтому кривая, корявая технология, но с единым хозяином, достаточно сильным, чтобы продавить своё технологическое видение, многократно лучше архитектурно красивой технологии, но с кучей быстро меняющихся владельцев или вообще бесхозной.
Именно поэтому кривая, корявая технология, но с единым хозяином, достаточно сильным, чтобы продавить своё технологическое видение, многократно лучше архитектурно красивой технологии, но с кучей быстро меняющихся владельцев или вообще бесхозной.
0
Проблема появилась еще до становления движения за открытое обеспечение.
POSIX — то что должно бы стандартизировать на самом деле узаконило 1000 костылей и несовместимостей реализаций Unix между собой, а Linux чтобы иметь возможность переисспользовать уже существующие наработки, должен был большую часть этого стандарта и сообтветственно костылей переисспользовать.
POSIX — то что должно бы стандартизировать на самом деле узаконило 1000 костылей и несовместимостей реализаций Unix между собой, а Linux чтобы иметь возможность переисспользовать уже существующие наработки, должен был большую часть этого стандарта и сообтветственно костылей переисспользовать.
+1
Основной тезис статьи можно сформулировать коротко: «надо отвечать за базар!»
+15
С точки зрения «здравой, критической, логики» статья — просто эпическое нечто!
Во-первых, господин Брукс занимается уж слишком неприкрытой софистикой. И порой эта софистика настолько «топорна», что просто бросается в глаза. Вот скажите, как?! Как простите, это понимать сие утверждение:
> Мы не можем отрицать, что вся эра доткомов явилась настоящим бедствием для 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, настолько «чудотворный», что способен даже исправить все-все последствия
+7
Брукс здесь не при чём, автор сего опуса — Poul-Henning Kamp.
(это я на всякий случай пояснил)
А вообще да, с темы на тему скачет, я специально заголовки сам придумал, чтобы читатели не упоролись от полёта мысли.
(это я на всякий случай пояснил)
А вообще да, с темы на тему скачет, я специально заголовки сам придумал, чтобы читатели не упоролись от полёта мысли.
+6
и оказывается, по мнению Брукса, «Шанс ВСЁ Исправить» — это ВНЕЗАПНО новый формат пакетов Ubuntu а еще QT!Чуть чуть внимательнее посмотрите концовку — там Пол говорит, что с точки зрения Брукса у нас не всё потеряно. Затем перевод заканчивается и я дописал от себя абзац с двумя ссылками, которые появились в интернете совсем недавно. На мой взгляд, это отличная иллюстарция того самого шанса исправить ад сборок и ад зависимостей.
+2
Новый формат пакетов не более чем еще один формат пакетов, а на qt разве пишут без зависимостей?
+3
Новый формат пакетов не более чем еще один формат пакетовЭто невежество. Если статья на OpenNet не очень чётко объясняет суть, то вот на хабре писали про это в более простой форме и разница налицо. habrahabr.ru/post/179751/
а на qt разве пишут без зависимостей?Речь не о самих зависимостях, а о способе подготовки к линковке с ними.
+3
А кто-нибудь кроме меня читал Мифический человеко-месяц (Брукса)? Прекрасная книга! (простите за оффтоп)
+5
Эх, батенька, не понимаете вы смысла фразы «UNIX-way»… Вот из-за такого непонимания и получается всякий ужас вроде systemd и бубунто-пакетных менеджеров, что мало-помалу приближает так называемый «линуксокапец» и делает единственным светом в окошке BSD (которую некоторые уже давно для себя закопали).
Кстати, autotools — действительно тормозное и устаревшее поделие, cmake намного удобней!
Кстати, autotools — действительно тормозное и устаревшее поделие, cmake намного удобней!
-1
Sign up to leave a comment.
Поколение, затерянное на базаре