Почему приложения Linux часто помещают язык, с которым это было записано в сводке?
Я понимаю это mkdir является атомарным, так возможно:
lockdir=/var/tmp/myapp
if mkdir $lockdir; then
# this is a new instance, store the pid
echo $$ > $lockdir/PID
else
echo Job is already running, pid $(<$lockdir/PID) >&2
exit 6
fi
# then set traps to cleanup upon script termination
# ref http://www.shelldorado.com/goodcoding/tempfiles.html
trap 'rm -r "$lockdir" >/dev/null 2>&1' 0
trap "exit 2" 1 2 3 13 15
Я думаю традиционный пользователь Linux (гиковатый умелец, который на самом деле установил систему сам), действительно заботится о такой информации (какая технология находится позади этого инструмента?). Я - также один из тех гиковатых парней, которые, например, воздержались бы от установки и использования пакета просто, потому что это использует некоторую технологию, которую я не люблю. Некоторый вызов этот вид религии поведения, конечно. Глупый не так ли?
Так или иначе я могу думать о двух причинах:
Поставщики программного блока как гиковские (если не больше), чем те пользователи Linux также, таким образом, они нашли хорошей идеей добавить такую информацию.
Я думаю, когда эти поставщики программного блока помещают такую информацию о своих описаниях пакета, они, вероятно, делают ее как некоторую форму продвижения. Это время от времени работает (это работало надо мной довольно много раз).
Это - просто предположение, конечно.
-
1Да, я думаю, что у Вас есть положительная сторона здесь. *отклоняют культуру, культура действительно. – Jordan Parmer 16.06.2011, 05:25
-
2Это также экономит время при удивлении "эй, в котором записан Хром языка?". – greenoldman 16.06.2011, 08:08
-
3@macias: фанат во мне заставляет меня посмотреть на зависимости пакета, где этот фанат будет чаще всего узнавать язык. На самом деле этот фанат является столь религиозным, что каждый раз, когда он посещает веб-сайт, он раздражается, что он не может быстро проверить, в каком языке незнакомый инструмент записан. Если это <вставляют нелюбимый язык>, этот фанат убегает, и если это <вставляют любимый язык>, шоу предубеждения фаната. – tshepang 16.06.2011, 09:53
-
4практическим примером о технологии, которая могла быть проблемой, является моно/.NET начиная с Microsoft, имеет много патентов в той области и имеет долгую историю о том, чтобы быть "недружелюбным"... Поэтому не странно, что некоторые люди хотели бы знать, что такого рода вещи избегают будущих проблем. – Johan 16.06.2011, 14:15
-
5С системной администраторской точки зрения записан какой проект, часто диктует, какие зависимости должны быть доступными. – J. M. Becker 20.04.2012, 07:57
Мой смысл - это, касается второй из четырех свобод программного обеспечения:
Свобода учиться, как программа работает и изменяет его, чтобы заставить его сделать то, чего Вы желаете (свобода 1). Доступ к исходному коду является предварительным условием для этого.
Разглашение языка (или другие технические характеристики) поддерживает способность людей выбрать и поощряет участие в проектах людей, которые являются опытными на тех языках.
Это может быть частично историческим. Даже в не таким образом удаленное прошлое для отдельных системных администраторов было обычно создать и установить все, что работало на их системе.
Примечания по тому, какой язык и библиотеки использовались для реализации инструмента, дают подсказку администратору о том, сколько работы, которой процесс будет для их системы.
В этом возрасте повсеместных и далеко идущих инструментов управления пакета это - что-то вроде анахронизма, но культура Unix консервативна в смысле не вывода вещей, которые, кажется, работают, таким образом, это будет некоторое время, прежде чем привычка умирает.
-
1достойный пример, о котором я думаю, является веб-приложением, названным redmine. Это записано с Ruby on Rails, ни рубин, ни направляющие обычно не обеспечиваются в системе по умолчанию. Приложения Java также похожи на это. – xenoterracide 16.06.2011, 17:10
В расширении ответа jasonwryan:
При именовании языка, он был записан в, человек, который получает его, может оценить, как трудно он должен будет обеспечить патч, или получить некоторое понимание или расширить программу.
Конечно, это только имеет смысл, если Вы - программист.
Где Вы видели сводки? В репозитории или пакете как .deb или .rpm?
При создании его из источника информация могла бы быть полезна определить, необходимо ли установить другой материал (compliler, библиотеки, инструменты сборки).
-
1Просто просмотрев репозитории Ubuntu (через Центр программного обеспечения). Почти все сводки включают язык в первом предложении. Я нахожу это довольно забавным, который большинство разработчиков Linux, кажется, на самом деле разрабатывает для других разработчиков Linux вместо пользователей. – Jordan Parmer 16.06.2011, 05:24
-
2@j0rd4n, не являющийся пользователем человечности, можно ли дать пример пакета программного обеспечения? Я значу для, они действительно помещают C в описание Firefox? Я размышлял бы, что приблизительно 90% программного обеспечения на Linux не предназначены для конечных пользователей, это - библиотека. Также... Вы не поняли, что Разработчики Linux разрабатывают для себя? это печально, но верно... как программист жемчуга, я отступаю, я ничего еще не записал для конечного пользователя :( – xenoterracide 16.06.2011, 17:30
-
3, я использую человечность, с немецким языком как интерфейсный язык, таким образом, это только поможет немногим из нас, для приведения некоторых примеров, но я могу уверить Вас: В synaptics, программе установки для нового программного обеспечения, я сделал тест и выбрал 5 пакетов - и не нашел сингл их, упомянув язык, в котором это было записано. – user unknown 16.06.2011, 17:35
-
4Расширение моего комментария: Часто, программное обеспечение записано для Unix (если Вы находите автоmake-файлы и такой), и не обязательно произведенный для Linux, но из-за совместимости, доступной на различных разновидностях Unix. – user unknown 16.06.2011, 17:37
Unix, и теперь Linux и BSDs, всегда имел действительно сломанную основу программного обеспечения, и намного более разнообразная аппаратная основа существовала в довольно недалеком прошлом. Было важно знать, что некоторое программное обеспечение работало в intepreters, который Вы имели в своей системе, или что Вы могли скомпилировать исходный код. Если у Вас нет интерпретатора языка Common LISP или интерпретатора Tcl или безотносительно интерпретатора, Вы не хотели потрудиться загружать источник, только узнавать, что Вы не могли выполнить его.
Наличие описания того, какой язык что-то было в предотвращенном много напрасно потраченного времени.
При запросе, “какова эта вещь?”, разработчик будет склонен описывать его характер, который для них связывается с исходным кодом, скорее что его функция. Кто-то, надо надеяться, перепишет описание, чтобы быть более ориентированным на пользователя, прежде чем оно закончится на пакете, но упоминание языка может все еще быть релевантно, например, к расширяемости и scriptability, или полезно для возможности притянуть участников.
-
1Репозиторий Ubuntu имеет удивительную сумму описаний пакета, что первые пять слов содержат язык. Я - разработчик сам, но я никогда не изображал своих пользователей, о которых заботятся. Я мог понять, однако, что, будучи открытым исходным кодом, это могло бы иметь больше значения, но мы разрабатываем для людей или других разработчиков? – Jordan Parmer 16.06.2011, 05:23
-
2
С моей точки зрения такая информация является важной для привлечения новых участников, а также предоставления возможным пользователям непосредственной идеи того, сколько работы это могло бы повлечь за собой для интегрирования приложения в их систему.
- Общим аспектом являются библиотеки, пользовавшиеся при запуске приложения.
Некоторые установки ограничиваются несколькими выбранными инструментариями, как GTK +, но не QT, или наоборот. Для администратора, который обслуживает систему и регулярно обновляет ее компоненты за длительный промежуток времени, это может только быть практическим и не религиозным вопросом.
- Другим аспектом являются пользовавшиеся библиотеки и предпосылки, необходимые для компиляции приложения.
Т.е. для пользователей основанного на источнике дистрибутива Linux это имеет большое значение, записано ли приложение в C, или в Objective C, потому что их компилятор должен поддерживать язык во-первых. Другие языки могут заставить устанавливать огромную стопку библиотек. Вопрос затем, снова, сколько работы Вы готовы принять для компиляции этого приложения.
- Другой аспект является намерением притянуть участников.
Большинство разработчиков имеет предпочтение небольшого количества языков или может просто испытать недостаток в опыте в других. Чтобы позволить большему числу людей способствовать приложению, некоторые проекты даже разделяют свои источники на два различных языка (как Wesnoth, Забастовка Vega, Naev, только для именования некоторых). Один из них для базового приложения (как C или C++), другой для легкой модификации (как Python или Lua). Вот ссылка на главу "Архитектуры Приложений с открытым исходным кодом", которая описывает, как и почему это было сделано в Wesnoth.
- Наконец, существует, очевидно, большая предвзятость для и предубеждение против некоторых языков.
Я просто скажу, что видел ужасно неэффективное программное обеспечение, записанное приблизительно на любом языке. Если Вы спрашиваете меня для эффективности, качество кода приложения намного более важно, чем язык, в котором это записано.
Я думаю, что многое из него имеет отношение к рекламе производительности. Приложение, записанное на скомпилированном языке (C, C++...), собирается работать чертовски много лучше, чем один записанный на языке сценария (жемчуг, Python...).
Но это также набрасывается на совместимость. Приложение, записанное в языке сценариев, также, вероятно, будет более портативным через архитектуру и OSs с мало ни к какой модификации.
-
1куба Так в обоих случаях, у Вас есть про и обманный аргумент - который не удовлетворяет. Скомпилированный код, который является закрытым исходным кодом, распространен на окнах также, таким образом, аргумент производительности не отличил бы программу Linux – user unknown 16.06.2011, 04:20
-
2что? Вы просто не имели никакого смысла. За и против точно, почему Вы перечислили бы язык. Если бы у каждого был только 'pro's, то все использовали бы его. И я даже не понимаю то, что Вы пытаетесь сказать о скомпилированном коде и oss – Patrick 16.06.2011, 04:27
-
3, я понял Ваш ответ тот путь, что люди неявно рекламируют производительность, если это записано в C/C++, и что они неявно рекламируют мобильность, если это не записано в C/C++. Который всегда является аргументом мятежника - или против мобильности, или против производительности - обе причины, не говоря уже о языке. Итак, почему это иногда - это, и в другие времена противоположное? – user unknown 16.06.2011, 04:37
В сегодняшних системах рабочего стола/сервера это не может быть настолько важно, но для меньших систем в пределах от встроенных систем к нетбукам SSD и планшетам, языки или библиотеки, пользовавшиеся программой, могут быть судьбоносной проблемой, и из-за размера и соображений мобильности.
Относительно размера: Добавление интерпретатора для дополнительного языка, наряду со всеми стандартными модулями и обычно используемыми дополнительными модулями, может легко добавить сотни мегабайтов к требованиям устройства хранения данных. То же идет для семейств библиотек, особенно те связанные с главными настольными средами как Gnome и KDE. Что хуже, идя от выполнения n кому: n+1 Программы Perl не могли бы добавить так много к требованиям использования памяти, так как большая память может быть совместно использована, но идущий от n Программы Perl и 0 программ Python к n Программы Perl и 1 программа Python приводят к значительному скачку в использовании памяти. Это становится еще большим количеством проблемы, когда у каждого дурака, пишущего бесплатное программное обеспечение, есть их собственный любимый script/radtool язык, они хотят программировать в... Perl, Python, PHP, Ruby, JavaScript, Оболочка Bourne, Bash, Csh....
Относительно мобильности: Много интерпретируемых языков (а также платформы библиотеки) делает интенсивное использование функций, которые могут быть доступными в больших системах рабочего стола/сервера Linux, но не обязательно доступными в smaller/embedded/MMU-less системах. Зависимость от динамического .so модуль, загружающийся во времени выполнения, приходит на ум...
-
1Почему Вы называете их дураками? Почему они не кодировали бы на языке, который они любят? Какой язык они должны вместо этого использовать? – tshepang 04.07.2011, 00:26