Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 650 сообщений
Cообщения с меткой

unix - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Персона: создатель Perl Ларри Уолл — «великодушный пожизненный диктатор»

Вторник, 27 Сентября 2016 г. 23:44 (ссылка)





Сегодня на «Хабре» уже был пост, посвященный дню рождения создателя языка Perl. Здесь хотелось бы подробнее поговорить о биографии и взглядах Ларри Уолла, о его мотивации к созданию языка программирования, а также привести несколько фрагментов из недавнего интервью.



Ларри Уолл – американский программист, лингвист и создатель языка программирования Perl, один из лидеров движения за бесплатный доступ к программному обеспечению.



Первые шаги



Ларри родился 27 сентября 1954 года в Лос-Анджелесе в семье потомственных протестантских пасторов. Мальчик рос в небольшом городке Брементоне в штате Вашингтон и мечтал стать служителем церкви. Это желание не сбылось, но сам Ларри считается одним из немногих религиозных персон в мире именитых программистов.



Учился Ларри Уолл в христианском учебном заведении – Тихоокеанском университете Сиэтла. В 1976 году он получил диплом бакалавра по специальности «Лингвистика». Во время обучения и проявились задатки будущего автора Perl. В течение трёх лет, будучи студентом, Ларри работал в университетском компьютерном центре.





После окончания университета Ларри и его жена (Глория Борн) работали переводчиками Библии, а затем оба поступили в аспирантуру Калифорнийского университета в Беркли. Молодая семья лингвистов по-прежнему видела своё будущее на церковном поприще.



Но настал переломный момент, и работа Ларри в компьютерном центре стала одной из причин того, что, несмотря на лингвистическое образование, он решил заняться компьютерными технологиями. Ларри считал это более перспективным занятием.



Он поступил на работу в Unisys и в Лабораторию реактивного движения НАСА (JPL). Свободное время будущий гуру занимался разработкой программ для UNIX.



Perl: не за славу, не за плату



В 1987 году Ларри Уолл создал язык программирования Perl. Он тогда работал системным программистом в американской компании Unisys. Цели, которые преследовал Ларри при разработке нового языка программирования, отражены в его названии — PERL, которое позднее стало расшифровываться как Practical Extraction and Report Language, то есть «практический язык извлечения данных и создания отчетов».







С 1995 до 2002 года Ларри Уолл работал в компании O’Reilly & Associates, издателя его книг. Уход был связан с получением гранта Фонда Perl.



В 2004 году Ларри занял пост старшего научного сотрудника, а фактически «главного программиста» в NetLabs.



Сейчас Ларри Уолл продолжает развивать язык Perl под патронатом O’Reilly и живёт вместе со своей женой-писательницей и четырьмя детьми в городке Маунтин-Вью в Калифорнии.



Целью автора языка Perl никогда не было получение денег. Напротив, он внёс существенный вклад в «культуру» бесплатного распространения программ с их исходными кодами. Новый язык программирования Уолл разрабатывал для того, чтобы решить проблемы, с которыми он как программист сам сталкивался в течение рабочего дня.



Когда первая версия языка вышла в свет, Ларри Уолл обеспечил открытый доступ и к исходному коду самой программы. Любой желающий может бесплатно скачать и пользоваться Perl независимо от того, нужен ли он ему для усовершенствования собственной странички или для создания мультимилионного Интернет-проекта.



Несмотря на то, что в операционной системе Unix, для которой был создан Perl, уже имелись многочисленные и разнообразные средства для обработки текстовой информации (awk, csh, grep, sed и другие), новый язык полюбился огромному числу системных администраторов и программистов. Он был легок в изучении и применении: синтаксис похож на С, Perl-программы не требовалось предварительно компилировать, исходные тексты было легко модифицировать. А самое главное — это был действительно очень практичный язык: с его помощью легко решалось большинство повседневных задач — от самых простых до очень сложных.



Активно пользуясь языком Perl, программисты из разных стран направляли Ларри Уоллу предложения добавить в него новые возможности или улучшить имеющиеся. Постепенно Perl превратился из средства обработки текстов в среде Unix в мощную универсальную систему программирования. В середине 1990-х годов, по мере развития интернета, Perl стал излюбленным инструментом web-мастеров для создания динамических сайтов и Internet-программирования.



Благодаря языку Perl стартовал Yahoo, с его же помощью создан Amazon и миллионы других сайтов.



24 декабря 2015 года в официальном блоге, посвящённом новостям разработки Perl 6, появилась поздравительная запись. Разработчики поздравили всех с наступающим католическим Рождеством, и с тем, что так долго ожидаемое взросление языка, наконец, состоялось. Фактически, язык готов к использованию в рабочих проектах, и разработчики обещают больше ничего существенно не менять.



С момента выхода первой версии Perl прошло почти 29 лет, с момента выхода самой популярной в данное время версии Perl 5 – более 20 лет. Как шутит Ларри Уолл, создатель языка и лидер его разработки, 6-я версия, возможно, когда-нибудь и заменит 5-ю – примерно лет через 40.



Версия Perl 6 была анонсирована более 10 лет назад – на Amazon ещё можно купить книгу про этот «вскоре выходящий» язык, изданную в 2004 году. И хотя некоторые утверждают, что 6-ка отличается от 5-ки не более, чем C++ от C, всё-таки идеология в Perl 6 эволюционировала достаточно сильно для того, чтобы назвать его более современным языком.



Ларри Уолл надеется, что преподаватели в институтах смогут, наконец, используя один и тот же язык, обучать студентов разным стилям программирования – функциональному, процедурному и объектному.







Логотипом Perl 6 выбрали бабочку. Как (полушутя) пояснил Уолл на конференции в октябре этого года, это было сделано специально для того, чтобы сделать язык привлекательным для 7-летних девочек.



Вопросы есть?



Недавно Ларри Уолл дал интервью Slashdot. Приводим несколько фрагментов из беседы.



Каким компьютером вы пользуетесь? Какие приложения предпочитаете?



Уже год или два я пользуюсь Lenovo X1 Carbon2 с 4-ядерным процессором. За исключением отвратительной раскладки клавиатуры и почти бесполезной ёмкостной сенсорной полоски он практически идеален для разработки, общение и проведения презентаций. На нем установлена операционная система Linux Mint.



Что касается редакторов… я использую разные. У меня нет каких-то конкретных предпочтений.



На компьютере я пользуюсь браузером Firefox, а на моем древнем гуглфоне стоит Chrome.

В работе я бы не смог обойтись без IRC или Git.



Каковы наиболее важные вещи, которым нужно уделить внимание при разработке нового языка программирования?



Важно все. Если вы не разрабатываете DSL (Domain Specific Language), а язык общего назначения, необходимо сделать выбор: навязать миру свою парадигму или реализовать поддержку нескольких парадигм. Лично мы предпочитаем второе.



Даже если вы сможете предусмотреть все, в процессе вы все равно обнаружите что-то, что могли сделать лучше. Ведь не существует идеального языка программирования. При разработке Perl мы использовали 50-60 различных принципов, но самый важный принцип таков: «Не существует самого важного принципа».



С другой стороны, если сконцентрироваться лишь на нескольких важных вещах, в вашем языке будут хорошо сделаны только они. И это тоже не плохо. Плохо, когда люди путают понятие «язык общего назначения» и «язык, обладающий тьюринг-полнотой»



Можете ли назвать эффективные методы управления проектами помимо модели «Великодушный пожизненный диктатор»?

«Великодушный пожизненный диктатор» (англ. Benevolent Dictator For Life, сокр. BDFL) — в контексте разработки свободного ПО, полуюмористический термин, обозначающий главу или основателя проекта, который сохраняет за собой право принимать окончательные решения. Впервые термин использовался по отношению к Гвидо ван Россуму, создателю языка Python.
Я знаю некоторые успешные проекты с демократическими принципами. Но большинство людей не готовы достаточно учиться, чтобы к их мнению можно было прислушиваться.



В сообществе Perl я известен как BDFL, но у меня «B» превалирует над «D». Тем не менее, я больше веду себя как верховный судья, чем как генеральный директор.



Чат IRC выполняет функцию конгресса: предлагает и обсуждает новые идеи. Многие решения я делегирую другим разработчикам и вмешиваюсь только когда вижу варианты, которые другие не видят. У меня есть право «вето», но я стараюсь использовать его как можно реже. Как бы сказала королева Елизавета, я стараюсь править, а не управлять.



Как вы относитесь к господству английского языка в ИТ-индустрии? Изменилось бы что-то, если бы место английского занял язык, не связанный с национальностью? Эсперанто например?



Если бы таким языком стал Японский, мы бы перешли на обратную польскую запись – такой принцип реализован в Forth и PostScript. Я не знал, что существуют люди, думающие по принципу ПОЛИЗ, пока не начал изучать японский.



С другой стороны, я рад, что это место занимает английский. По-моему, Эсперанто все-таки больше европейский язык, чем азиатский.



В любом случае, люди хотят изучать английский, чтобы смотреть голливудские фильмы. Как носители английского языка лучшее, что мы можем сделать, это быть более внимательными к нуждам других языковых групп.



Так, в Perl 6 мы рассматриваем каждую графему в коде (из языков других народов) как изначально определенный символ, независимо от того, использует ли его Unicode-концорциум. Время исполнения нашего алгоритма индексации строк составляет O(1).



Насколько я знаю, в Swift тоже реализована поддержка родных языков. Однако там время выполнения алгоритма оценивается только в O(n). Так что, в Perl 6 это работает быстрее.



Если вам нужны китайские символы в именах идентификаторов – без проблем. Названия модулей на тамильском языке – без проблем. Мы обработаем все символы, которые поддерживает ваша файловая система. Хотите объявить новый оператор с эмодзи в виде веселой кошки? Без проблем.







Это Юникод, детка!


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/311166/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
eugene20237

LINUX: Как сделать нормальное цветное приглашение в bash в Ubuntu

Суббота, 24 Сентября 2016 г. 17:11 (ссылка)

В Ubuntu при создании нового пользователя надо указывать оболочку bash вот таким образом:
useradd ivan -s /bin/bash -m
или сделать тоже самое через usermod для существующего пользователя:
usermod ivan -s /bin/bash -m

Если этого не сделать то в терминале по умолчанию будет sh, а не bash и работать станет неудобно.

Эта информация взята отсюда:
http://askubuntu.com/questions/643411/ubuntu-14-04...mand-line-has-missing-features

На всякий случай добавлю как сделать более разноцветное приглашение bash:
http://www.calculate-linux.org/blogs/ru/193/show

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
diafabin

Как запускать крон

Пятница, 16 Сентября 2016 г. 17:02 (ссылка)

Стандартным компонентом для исполнения команд по расписанию в UNIX-подобных операционных системах является cron. Обычно демон crond стартует при запуске системы. Однако по различным причинам этого может не происходить. Запускать крон можно как вручную, так и настроив его автоматическую загрузку. ЧИТАТЬ ДАЛЬШЕ>>>



Комментарии (0)КомментироватьВ цитатник или сообщество
guilumhasb

Как посмотреть серийный номер

Пятница, 02 Сентября 2016 г. 20:30 (ссылка)

Потеряв серийный номер Windows или MS Office, при переустановке системы могут возникнуть серьезные проблемы. Чтобы не платить за покупку дорогостоящего ПО, можно «подсмотреть» серийные номера установленной операционной системы и офисного пакета от Microsoft. ЧИТАТЬ ДАЛЬШЕ>>>



Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kreozot213

Как переключиться на root

Пятница, 02 Сентября 2016 г. 14:05 (ссылка)

В операционных системах с Unix-подобной архитектурой обычно существует аккаунт с идентификатором, равным нулю. По умолчанию его логином является root. Пользователь, имеющий доступ к такому аккаунту, имеет неограниченные привилегии в системе. Многие административные задачи могут быть решены, только если есть возможность переключиться на root. ЧИТАТЬ ДАЛЬШЕ>>>



Комментарии (0)КомментироватьВ цитатник или сообщество
kacounpa

Как запускать крон

Четверг, 01 Сентября 2016 г. 07:32 (ссылка)

Стандартным компонентом для исполнения команд по расписанию в UNIX-подобных операционных системах является cron. Обычно демон crond стартует при запуске системы. Однако по различным причинам этого может не происходить. Запускать крон можно как вручную, так и настроив его автоматическую загрузку. ЧИТАТЬ ДАЛЬШЕ>>>



Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
bocadewehr

Как создать патч

Четверг, 01 Сентября 2016 г. 07:01 (ссылка)

Для распространения небольших изменений, внесенных в наборы различных файлов (например, исходный код программного обеспечения), в UNIX-подобных системах широко применяются патчи. Они содержат только сведения о правках, которые необходимо внести в исходный файл для его модификации до актуального состояния. ЧИТАТЬ ДАЛЬШЕ>>>



Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Семантический перенос строк

Вторник, 09 Августа 2016 г. 10:11 (ссылка)

От переводчика:



Некоторое время назад на Хабре публиковался перевод статьи под названием Искусство командной строки. Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один параграф приходилась ровно одна строка.



Я тогда выразил своё недоумение автору и попросил его выровнять текст на 80 символов. Но после непродолжительной дискуссии в коментариях дали ссылку на описание форматирования исходников литературных текстов по семантическому принципу. Идея, заложенная в этом принципе в общем довольно простая, но я был поражён её глубиной, которой, пусть и запоздало, хочу поделиться с окружающими.



Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.



Итак, статья.



Семантический перенос строк



На ежегодном ликбезе по Sphinx проводимом в рамках PyCon я регулярно даю один совет. Благодарный слушатель спросил, где я сам почерпнул эти знания. Я провел археологические изыскания и теперь у меня есть ответ на этот вопрос. Позвольте рассказать вам про “семантические переносы строк”, а потом я открою источник этого знания — которое, как выясняется, было явлено миру когда мне было всего несколько месяцев от роду!



На лекции я задаю вопрос — предполагается ли, что Sphinx файлы будут доступны для чтения конечному пользователю. Если нет, то я призываю слушателей рассматривать файлы как “исходник”, который можно форматировать семантически. Вместо возни со строками каждого параграфа с целью подогнать их к одинаковой ширине, можно заканчивать строку в любом месте, разделяющим две мысли.



Результат может оказаться замечательным.



Если начинать каждое предложение с новой строки и делить сами предложения на высказывания, текстовые файлы становится гораздо проще редактировать и хранить в системе контроля версий. Текстовые редакторы отлично умеют работать со строками поэтому если каждое предложение представлено блоком последовательных строк, ваш редактор внезапно оказывается чрезвычайно мощным инструментом для быстрой перестановки высказываний и мыслей.



К тому же, ваша система контроля версий будет просто в восторге от семантических переносов строк. Случалось ли у вас, чтобы после изменения нескольких слов в начале параграфа, оказывалось, что система контроля версий теперь считает изменённым весь текст?



-Великолепие решения в том, что теперь, если вы
-передумаете насчёт того, как должен выглядеть
-параграф можно изменить форматирование вывода
-простым изменением определения ‘‘.PP’’ и
-перезапуском форматтера.
+Красота решения в том, что теперь, если вы
+передумаете насчёт того, как должен выглядеть
+параграф можно изменить форматирование вывода
+простым изменением определения ‘‘.PP’’ и
+перезапуском форматтера.


Если каждое предложение и высказывание начинать с новой строки, вы можете произвести те же самые изменения в том же самом параграфе не изменяя большую его часть.



-Великолепие решения в том,
+Красота решения в том,
что теперь, если вы передумаете насчёт того,
как должен выглядеть параграф
можно изменить форматирование вывода
простым изменением определения ‘‘.PP’’
и перезапуском форматтера.


“Семантические переносы строк,” как я их называю, облегчают мне жизнь уже более двадцати лет, и диктуют устройство моих текстовых файлов под капотом независимо от используемой разметки, будь то HTML, TeX, RST, или почтенный troff .



Откуда же я узнал об этой штуке?



Долгое время я думал, что моим источником было Руководство по инструментарию для созданию UNIX документации. Инструментарий был попыткой AT&T продвинуть на рынок операционную систему, которая стала культовой среди инженеров Bell Labs, путем добавления в систему мощнейших инструментов по офомлению текста. Попытка конечно провалилась — говорят, что в AT&T с маркетингом всё было просто ужасно, также как и в Xerox, где понятия не имели что делать с идеями бурлившими в PARC в 1970-x — но мой отец работал в Bell Labs и у него дома был экземпляр документации к Инструментарию. (В интернете я копии найти не смог — может быть, все доступные копии были уничтожены во время разрушительной войны за копирайт которая совершенно заслуженно привела SCO к краху?)



Но в результате тщательных поисков, я обраружил более ранний источник и с радостью узнал, что источник моего вдохновения не кто иной, как Брайен В. Керниган!



Он опубликовал “UNIX для начинающих” в качестве технического меморандума Bell Labs 74-1273-18 29 октября 1974 года. В нём описана гораздо более простая версия операционной системы, чем в его более известной и широкодоступной “UNIX для начинающих — Второе Издание” 1978 года. В результате долгих поисков я обнаружил одинокую копию, ссылка на которую приведена выше, размещённую на малоизвестном японском сайте, посвящённом UNIX 6th Edition. В разделе “Советы по подготовке документов” Керниган делится своей мудростью:



Советы по подготовке документов



Большинство документов успевает сменить несколько версий (всегда больше, чем кажется в начале) перед тем, как работа над ними будет завершена. Соответственно, следует делать всё возможное для облегчения внесения изменений.



Прежде всего, когда вы занимаетесь чисто механическим набором текста, набирайте так, чтобы облегчить дальнейшее редактирование. Начинайте каждое предложение с новой строки. Делайте строки короткими и заканчивайте строки в естественным образом подходящих для этого местах, таких как запятые и точки с запятыми, а не где придётся. Так как у большинства людей правки состоят из переписывания фраз и добавления, удаления а также перестановки предложений, эти меры упрощают любую дальнейшую редактуру.



— Брайен В. Керниган, 1974


Заметьте, как питонически звучит его совет — он заменяет выдумки о документах написанных “раз-и-навсегда” реалистичным подходом — написанием текста, который просто редактировать в дальнейшем.



Я, должно быть, прочитал это когда впервые изучал UNIX и пронёс сквозь все эти годы. Тот факт, что совет данный в 1974, и изначально ориентированный на облегчение редактирования текста в чудовищно ограниченном редакторе ed можно с тем же успехом применить в современном мире разноцветных полноэкранных редакторов, таких, как Emacs и Vim и распределённых систем контроля версий, совершенно немыслимых в 1970-х, очень многое говорит о мощи юниксового подхода.



Если вас интересует ранняя документация к UNIX — в том числе Второе Издание Руководства для Начинающих Кернигана — посмотрите на 7th Edition manuals благородно выложенное Bell Labs в сеть в виде PDF файлов а также в виде текстовых файлы, с разметкой для troff. Обратите внимание — из troff файлов и по сей день можно собрать готовый документ, который можно просматривать современными средствами — попробуйте-ка провернуть этот фокус с форматированным текстом из любых других редакторов 1970-х!



Послесловие от переводчика:



Почему я созрел опубликовать этот перевод только сейчас? Всё в общем просто. На Хабре недавно появилась поддержка формата Markdown, чему я был несказанно рад. Только вот выяснилось, что строки Хабр почему-то не склеивает, хотя Markdown не должен склеивать строки если только они кончаются двумя висячими пробелами.



И выходит, что я не могу писать статьи в любимом редакторе, хранить их в любимой системе контроля версий, а потом просто копипастить на Хабр. Хабр! Как так то? Почему? Сделай, пожалуйста чтобы строки склеивались! Видишь, сам Керниган сказал, что это правильно!


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307388/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
eugene20237

Linux: как посмотреть список открытых портов в системе?

Среда, 22 Июня 2016 г. 23:20 (ссылка)

lsof -Pni4

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка Docker контейнеров с помощью системы многоцелевых сценариев Sparrow

Четверг, 02 Июня 2016 г. 14:28 (ссылка)

В этой статье я хотел бы рассказать как можно создавать сценарии сборки имиджей для Docker контейнеров с помощью системы многоцелевых сценариев Sparrow*.



Читать дальше →

https://habrahabr.ru/post/302278/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Linux Programming Interface

Пятница, 29 Апреля 2016 г. 16:28 (ссылка)

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.



В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:







Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.





Книга Майкла Керриска «The Linux Programming Interface» (TLPI) в первую очередь ориентирована на системных программистов, работающих с Linux, но целевая аудитория ими далеко не ограничивается. Хотя это и объемистый том (говорят, «таким можно быка пришибить»), читается книга на удивительно легко — и если вы ее просто пролистываете, и если штудируете каждый абзац. Здесь вы найдете энциклопедическую информацию об интерфейсе системных вызовов ядра Linux, но весь материал изложен в очень доступном стиле. В общем, это отличный справочник, который займет достойное место в библиотеке любого специалиста по Linux, работающего как с ядром, так и с пользовательским пространством, а также заинтересует некоторых из тех, кто не занимается Linux профессионально.



Керриск занимается поддержкой man-справки по Linux с 2004 года, поэтому отлично представляет себе Linux API. Как он упоминает в предисловии, возможно, вы уже знакомы с некоторыми его работами, а именно с разделами 2, 3, 4 и 5 этой справки. Но книга – не просто сборник статей из справки, хотя тематически во многом им близка. Ее материал организован иначе и изложен значительно более живым, популярным стилем.



Объем книги – около 1500 страниц, поэтому написать по ней обзор было не так просто. Однако, приступив к чтению, я вскоре ею увлекся. Керриск внятно описывает системные вызовы Linux и другие элементы API. Я решил прочитать лишь наиболее заинтересовавшие меня главы, а остальное пропустить, но в итоге прочитал гораздо больше, чем собирался.



Книга состоит из 64 глав, в каждой из которых примерно 20 страниц. Поэтому материал легко усваивается небольшими фрагментами, можно читать книгу и параллельно заниматься другими задачами. Основное внимание Керриск уделяет Linux, однако не забывает и о других разновидностях UNIX, отмечает, чем другие UNIX-подобные системы отличаются от Linux. Автор внимательно рассматривает различные стандарты, описывающие поведение Linux – в частности, POSIX и Single UNIX Specification (SUS) — указывая, где в Linux соблюдаются и где не соблюдаются эти стандарты.



Книга начинается с исторического экскурса: от таких классиков как Томпсон и Ричи до недавнего прошлого, с рассмотрением различных ветвей древа UNIX. Затем автор рассказывает, что такое операционная система, какую роль в ней играет ядро, а также излагает некоторые общие концепции, составляющие суть Unix (и Linux). Хотя для большинства корифеев Linux здесь нет никаких секретов, эта информация пригодится тем, кто раньше работал с другими операционными системами. Идеи «все — файл» и «файл — это просто поток байт» описаны настолько доступно, что любой системный программист, познакомившись с книгой, сможет быстро вступить на «путь Unix».



После такого введения Керриск переходит к главам, в каждой из которых описываются те или иные аспекты интерфейса системных вызовов. Этот материал занимает большую часть книги, причем каждая глава, в сущности, самодостаточна. Последующие главы основываются на предыдущих, при этом их текст изобилует ссылками на другие разделы. В предисловии Керриск упоминает, что постарался свести к минимуму количество опережающих ссылок, но это явно не слишком ему удалось, так как опережающих ссылок получилось не меньше, чем обычных.



В каждой главе приводятся понятные образцы кода, которые удобно читать. Важно, что эти примеры очень помогают напрактиковаться в теме, а некоторые из листингов легко можно доделать до хороших утилит. Весь исходный код доступен на сайте man7.org/tlpi и является свободным, выпущен по лицензии Affero GPLv3. Кроме того, в каждой главе есть упражнения для читателя, решения некоторых из них даны в приложении.



Итак, о чем же книга? Легко сказать «обо всем сразу», но это будет своеобразная отговорка, причем неточная. В книге вы найдете множество глав о файлах, файловом вводе/выводе, расширенных атрибутах, списках контроля доступа (ACL). Есть глава о каталогах и ссылках, а в другой главе рассматривается вызов inotify, позволяющий получать уведомления о событиях, происходящих в файлах.



Здесь вы найдете множество глав о процессах, потоках, сигналах, целые главы, в которых рассматриваются группы процессов, сеансы, приоритет процессов и планирование. Особенно интересной мне показалась глава о создании защищенных привилегированных программ. Есть две главы о разделяемых библиотеках, причем в первой из этих глав акцент делается на базовых идеях, лежащих в основе этих библиотек, а также о создании разделяемых библиотек в принципе; в свою очередь, вторая из этих глав посвящена системному вызову dlopen() и ему подобным.



Пожалуй, в книге слишком много глав о межпроцессной коммуникации (IPC), по одной главе посвящено каждому IPC-механизму в составе System V (разделяемая память, очереди сообщений и семафоры). Также есть по главе о каждом из трех POSIX-вариантов этих типов IPC. Как по POSIX, так и по System V IPC есть своя вводная глава кроме тех глав, в которых излагаются подробности о каждом типе. Между двумя разделами о механизмах System V и POSIX IPC втиснуты две главы об отображении на память и об операциях с виртуальной памятью, которые, возможно, лучше было бы поставить в другой части книги. Еще есть глава, в которой делается введение в IPC и глава о более традиционных каналах Unix и очередях FIFO. Всего насчитывается двенадцать глав, связанных с IPC, после чего автор начинает рассматривать API сокетов.



После IPC идет глава о блокировке файлов, а затем шесть глав о сокетах. В этих главах рассматриваются сокеты Unix и сокеты Интернета, а также рассказывается о серверном дизайне и освещаются сложные темы, связанные с сокетами. Книга заканчивается главами о терминалах и псевдотерминалах, между которыми как-то затесалась глава «Альтернативные модели ввода/вывода». Это интересная глава, в которой рассматриваются вызовы select(), poll(), epoll(), сигнально-управляемый ввод/вывод и некоторые другие темы. Но расположена она все-таки немного странно.



Само собой, содержание книги этим не ограничивается. После ее прочтения особенно впечатляет, насколько велик API Linux/Unix. В книге также рассматриваются некоторые недостатки и морально устаревшие детали, сохранившиеся в API. Керриск ничуть не стесняется делать в нужных местах подобные замечания: «Вообще, очередями сообщений System V обычно лучше не пользоваться».



Есть две темы, о которых я очень хотел почитать, но которые плохо раскрыты в книге. Во-первых, это контейнеры и пространства имен, которые лишь вскользь упоминаются при обсуждении флагов системного вызова clone(). Более странным показалось, что в книге почти не упоминается системный вызов ptrace(). В тех немногих местах, где он все-таки фигурирует, читателей отсылают к man-справке ptrace(2).



Разумеется, кроме интерфейса системных вызовов можно было бы рассмотреть и другие элементы Linux API – навскидку вспоминаются sysf, splice() и perf – но Керриску явно приходилось выбирать, что включить в книгу, а от чего отказаться. В принципе, автор справился хорошо. Некоторые технические книги по Linux достаточно быстро устаревают, но в случае с этой работой проблема устаревания стоит не так остро как, например, с книгой об устройстве ядра.



У меня есть еще некоторые претензии к книге, но все они несущественные. В первую очередь, хотелось бы сказать, что многочисленные «отступления» в книге — это именно лирические отступления. Они содержат дополнительную информацию, которая некритична для понимания темы. По-моему, многие из них лучше было бы вплести в основной текст.



Книга пригодится, прежде всего, системным программистам и разработчикам приложений, но ими целевая аудитория не ограничивается. Разработчики ядра смогут уточнить, не противоречат ли их новые фичи (или фиксы) структуре API. Программисты, занятые преимущественно разработкой для Unix-подобных систем, при помощи этой книги смогут сделать свой код более портируемым. Думаю, читатель будет регулярно с пользой возвращаться к этой книге. Полагаю, все, кто по-настоящему интересуется программированием для Linux, со мной согласятся.





Актуальность книги






































Проголосовало 42 человека. Воздержалось 28 человек.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru.

https://habrahabr.ru/post/282776/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Linux Programming Interface

Пятница, 29 Апреля 2016 г. 16:28 (ссылка)

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.



В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:







Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.





Книга Майкла Керриска «The Linux Programming Interface» (TLPI) в первую очередь ориентирована на системных программистов, работающих с Linux, но целевая аудитория ими далеко не ограничивается. Хотя это и объемистый том (говорят, «таким можно быка пришибить»), читается книга на удивительно легко — и если вы ее просто пролистываете, и если штудируете каждый абзац. Здесь вы найдете энциклопедическую информацию об интерфейсе системных вызовов ядра Linux, но весь материал изложен в очень доступном стиле. В общем, это отличный справочник, который займет достойное место в библиотеке любого специалиста по Linux, работающего как с ядром, так и с пользовательским пространством, а также заинтересует некоторых из тех, кто не занимается Linux профессионально.



Керриск занимается поддержкой man-справки по Linux с 2004 года, поэтому отлично представляет себе Linux API. Как он упоминает в предисловии, возможно, вы уже знакомы с некоторыми его работами, а именно с разделами 2, 3, 4 и 5 этой справки. Но книга – не просто сборник статей из справки, хотя тематически во многом им близка. Ее материал организован иначе и изложен значительно более живым, популярным стилем.



Объем книги – около 1500 страниц, поэтому написать по ней обзор было не так просто. Однако, приступив к чтению, я вскоре ею увлекся. Керриск внятно описывает системные вызовы Linux и другие элементы API. Я решил прочитать лишь наиболее заинтересовавшие меня главы, а остальное пропустить, но в итоге прочитал гораздо больше, чем собирался.



Книга состоит из 64 глав, в каждой из которых примерно 20 страниц. Поэтому материал легко усваивается небольшими фрагментами, можно читать книгу и параллельно заниматься другими задачами. Основное внимание Керриск уделяет Linux, однако не забывает и о других разновидностях UNIX, отмечает, чем другие UNIX-подобные системы отличаются от Linux. Автор внимательно рассматривает различные стандарты, описывающие поведение Linux – в частности, POSIX и Single UNIX Specification (SUS) — указывая, где в Linux соблюдаются и где не соблюдаются эти стандарты.



Книга начинается с исторического экскурса: от таких классиков как Томпсон и Ричи до недавнего прошлого, с рассмотрением различных ветвей древа UNIX. Затем автор рассказывает, что такое операционная система, какую роль в ней играет ядро, а также излагает некоторые общие концепции, составляющие суть Unix (и Linux). Хотя для большинства корифеев Linux здесь нет никаких секретов, эта информация пригодится тем, кто раньше работал с другими операционными системами. Идеи «все — файл» и «файл — это просто поток байт» описаны настолько доступно, что любой системный программист, познакомившись с книгой, сможет быстро вступить на «путь Unix».



После такого введения Керриск переходит к главам, в каждой из которых описываются те или иные аспекты интерфейса системных вызовов. Этот материал занимает большую часть книги, причем каждая глава, в сущности, самодостаточна. Последующие главы основываются на предыдущих, при этом их текст изобилует ссылками на другие разделы. В предисловии Керриск упоминает, что постарался свести к минимуму количество опережающих ссылок, но это явно не слишком ему удалось, так как опережающих ссылок получилось не меньше, чем обычных.



В каждой главе приводятся понятные образцы кода, которые удобно читать. Важно, что эти примеры очень помогают напрактиковаться в теме, а некоторые из листингов легко можно доделать до хороших утилит. Весь исходный код доступен на сайте man7.org/tlpi и является свободным, выпущен по лицензии Affero GPLv3. Кроме того, в каждой главе есть упражнения для читателя, решения некоторых из них даны в приложении.



Итак, о чем же книга? Легко сказать «обо всем сразу», но это будет своеобразная отговорка, причем неточная. В книге вы найдете множество глав о файлах, файловом вводе/выводе, расширенных атрибутах, списках контроля доступа (ACL). Есть глава о каталогах и ссылках, а в другой главе рассматривается вызов inotify, позволяющий получать уведомления о событиях, происходящих в файлах.



Здесь вы найдете множество глав о процессах, потоках, сигналах, целые главы, в которых рассматриваются группы процессов, сеансы, приоритет процессов и планирование. Особенно интересной мне показалась глава о создании защищенных привилегированных программ. Есть две главы о разделяемых библиотеках, причем в первой из этих глав акцент делается на базовых идеях, лежащих в основе этих библиотек, а также о создании разделяемых библиотек в принципе; в свою очередь, вторая из этих глав посвящена системному вызову dlopen() и ему подобным.



Пожалуй, в книге слишком много глав о межпроцессной коммуникации (IPC), по одной главе посвящено каждому IPC-механизму в составе System V (разделяемая память, очереди сообщений и семафоры). Также есть по главе о каждом из трех POSIX-вариантов этих типов IPC. Как по POSIX, так и по System V IPC есть своя вводная глава кроме тех глав, в которых излагаются подробности о каждом типе. Между двумя разделами о механизмах System V и POSIX IPC втиснуты две главы об отображении на память и об операциях с виртуальной памятью, которые, возможно, лучше было бы поставить в другой части книги. Еще есть глава, в которой делается введение в IPC и глава о более традиционных каналах Unix и очередях FIFO. Всего насчитывается двенадцать глав, связанных с IPC, после чего автор начинает рассматривать API сокетов.



После IPC идет глава о блокировке файлов, а затем шесть глав о сокетах. В этих главах рассматриваются сокеты Unix и сокеты Интернета, а также рассказывается о серверном дизайне и освещаются сложные темы, связанные с сокетами. Книга заканчивается главами о терминалах и псевдотерминалах, между которыми как-то затесалась глава «Альтернативные модели ввода/вывода». Это интересная глава, в которой рассматриваются вызовы select(), poll(), epoll(), сигнально-управляемый ввод/вывод и некоторые другие темы. Но расположена она все-таки немного странно.



Само собой, содержание книги этим не ограничивается. После ее прочтения особенно впечатляет, насколько велик API Linux/Unix. В книге также рассматриваются некоторые недостатки и морально устаревшие детали, сохранившиеся в API. Керриск ничуть не стесняется делать в нужных местах подобные замечания: «Вообще, очередями сообщений System V обычно лучше не пользоваться».



Есть две темы, о которых я очень хотел почитать, но которые плохо раскрыты в книге. Во-первых, это контейнеры и пространства имен, которые лишь вскользь упоминаются при обсуждении флагов системного вызова clone(). Более странным показалось, что в книге почти не упоминается системный вызов ptrace(). В тех немногих местах, где он все-таки фигурирует, читателей отсылают к man-справке ptrace(2).



Разумеется, кроме интерфейса системных вызовов можно было бы рассмотреть и другие элементы Linux API – навскидку вспоминаются sysf, splice() и perf – но Керриску явно приходилось выбирать, что включить в книгу, а от чего отказаться. В принципе, автор справился хорошо. Некоторые технические книги по Linux достаточно быстро устаревают, но в случае с этой работой проблема устаревания стоит не так остро как, например, с книгой об устройстве ядра.



У меня есть еще некоторые претензии к книге, но все они несущественные. В первую очередь, хотелось бы сказать, что многочисленные «отступления» в книге — это именно лирические отступления. Они содержат дополнительную информацию, которая некритична для понимания темы. По-моему, многие из них лучше было бы вплести в основной текст.



Книга пригодится, прежде всего, системным программистам и разработчикам приложений, но ими целевая аудитория не ограничивается. Разработчики ядра смогут уточнить, не противоречат ли их новые фичи (или фиксы) структуре API. Программисты, занятые преимущественно разработкой для Unix-подобных систем, при помощи этой книги смогут сделать свой код более портируемым. Думаю, читатель будет регулярно с пользой возвращаться к этой книге. Полагаю, все, кто по-настоящему интересуется программированием для Linux, со мной согласятся.





Актуальность книги






































Проголосовало 2 человека. Воздержалось 4 человека.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282776/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
zerg_from_hive

осиновый кол

Вторник, 01 Марта 2016 г. 12:02 (ссылка)

Новость, однако: "Компании SCO и IBM согласились принять решение суда и прекратить судебную тяжбу по претензиям SCO к IBM. 2 февраля окружной суд штата Юта принял решение об отклонении последних оставшихся претензий SCO к IBM и дал время до 26 февраля решить, согласны ли они с решением или намерены продолжить судебный процесс.

Стороны подписали соглашение, по которому в условиях банкротства компании SCO и отсутствия у неё каких-либо финансовых ресурсов помимо выдвинутого иска (т.е. единственный "финансовый ресурс", который остался у SCO, это надежда на удовлетворение иска и получение компенсации от IBM), подача апелляции и затягивание иска не имеет практического смысла. Более того, с прекращением иска, суду не нужно будет принимать решение по встречным искам от IBM, что позволит сэкономить средства суда и сторон. Интересно, что соглашение не затрагивает встречные иски IBM к SCO и оставляет IBM возможность продолжить тяжбы при желании."


Кажется, ночь живых мертвецов (сериал "SCO contra mundi" начался в 2003 году) наконец-то закончилась осиновым колом. Правда, один из комментаторов новости несколько более оптимистичен касательно покойника: "SCO хоронили -- три баяна порвали. И ещё десяток порвут. The show must go on!" 8-)

Метки:   Комментарии (2)КомментироватьВ цитатник или сообщество

Следующие 30  »

<unix - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda