Программирование на языке ассемблера NASM для ОС Unix
Текст этой книги в переработанном виде вошёл в состав "Введения в профессию" в виде третьей части (во втором издании это первый том, в первом издании был второй); небольшие фрагменты материала также вошли в первую (вводную) часть. Переизданий этого материала в виде отдельной книги больше не планируется. Автор настоятельно рекомендует читать Программирование: введение в профессию вместо данной (и сейчас уже устаревшей) книги. АннотацияПособие основано на лекциях, читавшихся автором в рамках курса «Архитектура ЭВМ и язык ассемблера» в Ташкентском филиале МГУ весной 2007 года; часть материала также прошла апробацию в рамках курса «Архитектура ЭВМ и системное программное обеспечение» кафедры Прикладной математики МГТУГА в 2008, 2009 и 2010 гг. Пособие ориентировано на практические занятия с использованием системы команд i386, «плоской» (бессегментной) модели памяти, ассемблера NASM и операционной системы Linux или FreeBSD; в частности, описываются конвенции системных вызовов обеих систем, также для обеих систем приводятся исходные тексты файлов с макроопределениями, призванными облегчить ассемблерное программирование на ранних этапах изучения дисциплины. Бумажные публикации
Второе издание пособия, включающее ряд исправлений, новую главу об арифметическом сопроцессоре, параграф, посвящённый машинному представлению целых чисел и некоторые другие дополнения, издано в 2011 году в издательстве МАКС Пресс. ISBN 978-5-317-03627-0. Электронная версияPDF-файл, полностью соответствующий печатной версии второго издания, можно взять тут: http://www.stolyarov.info/books/pdf/nasm_unix.pdf Электронные версии обеих частей первого издания также доступны:
Статус бумажной версииИздание поступало в свободную продажу. К настоящему времени полностью распродано. 
|
пояснениеВы находитесь на официальном сайте Андрея Викторовича Столярова, автора учебных пособий по программированию и информационным технологиям. Если вы искали сайт замечательного писателя-фантаста Андрея Михайловича Столярова, то вам, к сожалению, не сюда. Андрей Михайлович Столяров в библиотеке Мошкова |
☞ From Anonymous (unverified) Sun Jul 30 12:31:59 2023 UTC
Файл stud_io.inc
Доброго времени суток. Не могу найти ссылку на файл "stud_io.inc"
ответить
Re: Файл stud_io.inc
За каким дьяволом вы вообще это старьё читаете? Возьмите первый том трёхтомника, там весь материал этой книжки оформлен в виде части III, только этот материал уже трижды переиздан и, соответственно, изрядно причёсан и доработан. Файл stud_io.inc есть там же, в смысле на самой странице трёхтомника и плюс в архиве примеров.
ответить
Re: Re: Файл stud_io.inc
Понял, благодарю!
ответить
☞ From Anonymous (unverified) Mon Jan 21 21:24:00 2019 UTC
Trailing whitespaces
$ wget -qO- http://stolyarov.info/files/stud_io_inc_linux | grep -n '\s$'
23: pop eax
40:; %1: descriptor %2: buffer addr %3: buffer length
46:; %1: descriptor %2: buffer addr %3: buffer length
trailing whitespaces =(
ответить
ах ты ж чёрт
спасибо, поправил
ответить
☞ From xdkn1ght (unverified) Sat Jan 13 12:59:00 2018 UTC
Спасибо
Не знаю почему тут бомбит так у некоторых комментаторов.
Врядли я конечно, когда-нибудь буду писать на ассемблере, но кто знает. Автоу ещё хочется сказать, спасибо, что выложил книгу в открытый доступ. Мне как человеку, который начал интересоваться системным программированием и вообще тем что происходит внутри компьютера было интересно и полезно. Ещё раз спасибо!
Надоели уже эти все современные свителки-перделки, никакой ценности они не несут, не говоря уже о моральных и этических аспектах.
ответить
Пожалуйста :-)
Только зачем это старьё читать? При подготовке второго тома я материал этой книжки изрядно причесал и вообще всячески улучшил.
А писать на ассемблере на практике обычно нет никакого смысла, соответствующие знания и опыт нужны исключительно для понимания сути вещей.
ответить
☞ From Andrey (unverified) Tue Sep 20 18:48:00 2016 UTC
Читаю страницу
Читаю страницу 32:
"Макрос PUTCHAR предназначен для вывода на печать одного символа... Наконец, аргументом этого макроса может выступать исполнительный адрес заключенный в квадратные скобки"
Вот эта программа с посимвольным выводом строки работает правильно:
А вот если раскомментировать две строки (просто исполнительный адрес берется из EDX), вылетает с треском. Где я ошибаюсь?
ответить
Очевидно же:
Первая из этих двух команд берёт четыре байта, которые лежат в памяти по адресу string+eax, и кладёт их в edx. Вторая ЭТО использует в качестве адреса, тогда как по смыслу там не адрес вовсе, а первые четыре байта вашей строки. Внимательнее, внимательнее.
ответить
Да уж!
Это я не подумавши сделал! )))
Ну, то есть, сначала-то сразу указатель отдавался на разыменование PUTCHAR, а потом добавил транзит через EDX, типа, "какая разница"! Вот она и "разница", бедный указатель разыменовали дважды... А вроде, все просто!
Погорячился, был неправ. Спасибо.
ответить
Если вы бы не
Если вы бы не писали сокращенно команды, многое стало бы очевидным и хватало бы времени подумать... Пишите "offset, byte ptr и т.п." и не используйте "mov" для определения адреса ("lea")... Не давайте компилятору повода додумывать за вас что вы написали.
ответить
В nasm'е нет ни
В nasm'е нет ни слова offset, ни этого страшного byte ptr. К большому счастью. Вы бы хотя бы разобрались сначала, о каком ассемблере идёт речь и как он устроен, а потом уже лезли со своими нелепыми советами, особенно насчёт применения lea вместо mov.
ответить
☞ From Sharab (unverified) Fri Mar 18 17:59:00 2016 UTC
Ошибка компоновщика
iMac-OMG-4:Documents Sharab$ nasm -f elf hello.asm
iMac-OMG-4:Documents Sharab$ ld hello.o -o hello
ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.10
ld: warning: ignoring file hello.o, file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x01 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): hello.o
Undefined symbols for architecture x86_64:
"start", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for inferred architecture x86_64
ответить
попробуйте ld -m
попробуйте ld -m elf_i386
ответить
Не сработало
iMac-OMG-4:Documents Sharab$ ld -m elf i386
ld: warning: option -m is obsolete and being ignored
ld: file not found: elf
iMac-OMG-4:Documents Sharab$
ответить
Увы
У меня нет макоси, так что попробовать не могу. Проблема здесь в том, что nasm выдаёт 32-битный код (и в книжке описано программирование именно для 32-битной системы команд), а ваш линкер пытается из этого сделать 64-битное приложение. Естественно, у него ничего не получается. Как ему сказать, чтобы он делал 32-битный исполняемый файл, я не знаю, как не знаю и того, возможно ли это вообще под макосью. Попробуйте на него документацию почитать. Из того, что сходу нашлось в интернете, могу предложить попробовать -arch i386 но не факт, что это поможет.
ответить
Nasm под MacOS
"возможно ли это вообще под макосью"
Говорят: "Можно и зайца научить курить, нет ничего невозможного". Если мой заяц не притворяется, MacOS Sierra 10.12.1, nasm 2.12.02, то так:
Ниже - содержимое файла hello1.asm. (Пример hello5.asm к книге так не запустится. Думаю, придется поменять имена, начинающиеся с _ в файле и в stud_io.inc и проверить в stud_io.inc выравнивание стека (кратно 16?))
mms-MacBook-Air:nasm-2.12.02 mm$ cat hello1.asm global start section .text start: push dword msg.len push dword msg push dword 1 mov eax, 4 sub esp, 4 int 0x80 add esp, 16 push dword 0 mov eax, 1 sub esp, 12 int 0x80 section .data msg: db "Hello, world!", 10 .len: equ $ - msgответить
Прикольно :-)
То есть там конвенция BSD, причём даже 32-битные приложения поддерживаются. Само по себе это прикольно, спасибо за результаты эксперимента, заодно мы теперь знаем, что точка входа там называется
startбез подчёркивания в начале. Может быть, вы ещё расскажете, как туда Nasm поставить?Но вот насчёт стека не вполне понятно, когда он, по-вашему, должен быть кратен 16? На момент int 80h? Так он и в вашем примере не кратен. А подпрограмм никаких в stud_io.inc нет.
ответить
поставить Nasm на MacOS
>Может быть, вы ещё расскажете, как туда Nasm поставить?
Это не очень детективная история.
Идти сюда:
http://www.nasm.us
Или сразу по прямой ссылке:
http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/macosx/
Скачать - разархивировать - пользоваться :)
ответить
☞ From Anonymous (unverified) Fri Apr 5 13:40:00 2013 UTC
stud_io.inc
Да, я имел ввиду "расширение". На линуксе (лубунту) недавно, так что виндовская терминология не отпускает.
С этим файлом разобрался. Книга-супер. Подача материала отличная. Огромная благодарность за сей труд. Понял, что она должна у меня быть в бумажном виде - обязательно пройдусь по книжным магазинам.
За
Версии для Windows нет и не будет.
отдельный респект, свободой веет от неё.
ответить
На здоровье
В книжных этой книги нет, единственный вариант сейчас — заказать её на этом сайте, но этот вариант тоже скоро кончится. Книга издавалась тиражом 100 экз., какие там книжные.
А версии под винду не будет в том числе и по причине сугубо технической: тамошний набор системных вызовов может осилить только мазохист, я таковым не являюсь.
ответить
☞ From Anonymous (unverified) Thu Apr 4 18:20:00 2013 UTC
Добрый вечер.
Добрый вечер. Подскажите, где можно взять файл "stud_io.inc" и в какую папку nasma положить? Пытался на этой странице взять, но куда и с каким разрешением положить не знаю.
ответить
Папки - в шкафу
Во-первых, термин "папка" в применении к директориям недопустим, оставьте такую терминологию секретаршам. Папки обычно делают из картона и ставят в шкаф. В компьютере никаких "папок" нет и быть не может.
Во-вторых, на вопрос "где взять" вы ответили сами. Файл следует взять на этой странице, выше есть ссылка.
В-третьих, чтобы всё сработало, этот файл должен находиться в той же директории, что и ваш файл, который вы транслируете nasm'ом. Вообще-то это довольно очевидно, если внимательно прочитать в книге, как работает макродиректива %include.
Но вот насчёт "с каким разрешением" — на такой вопрос я ответить не могу, я, пардон, даже представить себе не могу, что вы имеете в виду. Если имеется в виду действительно "разрешение", то такая характеристика присуща растровым графическим файлам, видео и (с некоторой натяжкой) аудио, но никак не текстовым файлам. Если имеются в виду "разрешения" (а не "разрешение"), то есть права доступа (один из очень кривых вариантов перевода термина "permissions"), то пользователь, под которым вы работаете, должен иметь права на чтение этого файла, только вряд ли это то, что вы имели в виду. Наконец, можно предположить, что имелось в виду "расширение" (то есть часть имени файла, указывающая на его формат и отделяемая от имени точкой) — в этом случае да будет вам известно, что это пресловутое "расширение" (extension) бывает только под Windows. В *nix-системах используется понятие "суффикс", которое не является однозначно связанным с типом файла и вообще необязательно. В применении к stud_io.inc таким суффиксом, очевидно, является ".inc".
На всякий случай отмечу, что, ежели вам пришло в голову пробовать это всё под виндой, то stud_io.inc вам ничем не поможет — он зависит не только от конкретного набора поддерживаемых операционкой системных вызовов, но и от конкретной конвенции вызовов, именно поэтому для Linux и FreeBSD используются совершенно разные версии. Версии для Windows нет и не будет.
ответить
☞ From admin
Fri Mar 1 08:05:00 2013
UTC 
Ещё про 64 бита
Нарылась любопытная ссылочка:
http://askubuntu.com/questions/7034/what-is-the-difference-between-32-bit-and-64-bit-and-which-should-i-choose/70551#70551
Что-то сдаётся мне, что 64-битные архитектуры идут далеко-далеко лесом, и так ещё лет на десять.
ответить
Вот еще
Вот еще любопытные ссылки
https://safe.nrao.edu/wiki/bin/view/Main/SixtyFourBitNotes https://en.wikipedia.org/wiki/X32_ABI
ответить
☞ From Anonymous (unverified) Fri Feb 15 01:41:00 2013 UTC
Хочу сказать
Хочу сказать огромное спасибо за Вашу книгу. К своему стыду должен признать, что несмотря на то, что я уже получил высшее образование по профильной специальности, некоторые вопросы, касающиеся низкоуровневого программирования, оставались для меня не до конца ясными. Ваша книга помогла решить эту проблему. Очень жаль, что у меня не было подобного курса в университете.
ответить
☞ From Anonymous (unverified) Mon Dec 10 15:08:00 2012 UTC
Инструкция loop
Здравствуйте.
На странице 64 в вашей книге:
>Однако команда loop lp, делая те же действия, работает быстее...
В IA-32 Intel® Architecture Optimization Reference Manual написано следующее:
Assembly/Compiler Coding Rule 41. (ML impact, M generality) Avoid using complex instructions (for example, enter, leave, or loop) that generally have more than four μops and require multiple cycles to decode. Use sequences of simple instructions instead
http://www.openwatcom.org/ftp/devel/docs/intel%20optimisations%20manual%20-%20p4.pdf
ответить
Спасибо!
Про enter/leave я знал, но что это к loop тоже относится, никак не мог предположить. Учту в следующем издании, если таковое когда-нибудь будет.
ответить
Скорость инструкций для разных процессоров
Я тут нашел таблицу со скоростями инструкций http://agner.org/optimize/instruction_tables.pdf
Для первого пентиума loop быстрее, если я все правильно понял. Скорее всего, аналогичная ситуация будет и для старых i386 процессоров
ответить
Спасибо!
Тоже весьма любопытная ссылочка, thanks!
ответить
☞ From EAT (unverified) Thu Oct 18 09:33:00 2012 UTC
Mac OS X
А можно ли, и как запустить его на Mac OS X?
ответить
Можно-то можно
Что можно — это я не сомневаюсь. Сам NASM представляет собой программу, написанную на ANSI C, так что с его компиляцией и запуском проблем не будет. Более того, вроде бы (если не ошибаюсь) там должны быть те же соглашения о системных вызовах, что и под FreeBSD, потому что в глубине души эта самая Mac OS X и есть FreeBSD :), так что можно будет даже запустить программы, написанные для NASM.
Но вот вопрос "как" здесь вы задаёте явно не по адресу. Я эту вашу макось видел только издали. За шашечки я денег не плачу принципиально, так что ни одного изделия фирмы Apple у меня в хозяйстве нет и никогда не будет (на всякий случай, я не Медведев, так что попытки подарить мне изделие от Apple чревато физическими повреждениями).
ответить
☞ From Роберт (unverified) Wed Sep 12 10:18:00 2012 UTC
Спасибо
Спасибо большое за книгу и Ваш труд.
ответить
☞ From Anonymous (unverified) Thu Aug 9 11:46:00 2012 UTC
Выделение памяти
Добрый день, Андрей Викторович.
Могли бы Вы прояснить ситуацию, возникшую в процессе чтения Вашего пособия. Заключается она в следующем: если выделять инициализированную память директивой db (dw, dd), то в параметрах указываются значения через запятую, кот. будут храниться в бинарнике. Если же указать одно значение, например, x db 150, то получается, что выделяется одна ячейка памяти и в эту ячейку памяти заносится байт, принимающий значение 150 (10010110) и x указывает на эту ячейку (точнее ассемблер ассоциирует эту метку с адресом ячейки на этапе ассемблирования). А если бы использовалась директива выделения неинициализированной памяти x resb 150, то здесь выделилась бы память размером в 150 однобайтовых ячеек. Верно? Наставьте, пожалуйста, непонимающего на путь света =). Заранее спасибо.
ответить
Абсолютно верно
Вы совершенно правы, а в книге на стр. 50 опечатка. Спасибо за её выявление.
ответить
Это Вам
Это Вам огромное спасибо за книгу. Стиль изложения великолепен. Желаю Вам, чтобы Ваши творческие труды продолжались также успешно. А в гостевой книги комментарий #43 оставил я. Прошу прощения за дублирование, т.к. боялся, что он не прошел премодерацию. Еще раз спасибо за ответ.
ответить
☞ From igrassa (unverified) Tue Jul 24 17:47:00 2012 UTC
Огроммное
Огроммное спасибо за Вашу книгу!Надо быть действительно прожженным
профи,а также иметь дар Сухомлинского и Макаренко ,что бы в трех
слова объяснить ,что такое указатели.R&K и рядом не валялись.
ответить
"Уж сколько раз твердили миру"
Да пожалуйста, мне не жалко :-) А где это вы в моих книгах нашли объяснение указателей? Вроде бы учебника по чистому Си я ещё не написал, да и по Паскалю тоже.
ответить
☞ From Евгений (unverified) Tue Nov 22 17:49:00 2011 UTC
Без розовых очков...
...И где, простите, Sun Microsystems и её SPARC?...
SPARC, простите, вот здесь, в первой строчке TOP 500, в суперкомпьютере производительностью порядка десяти петафлоп. Но о задачах, для которых и такой производительности будет мало, Вы, наверное, даже и не слыхали...
А по поводу качества linux-ПО: ну не стоит, в самом деле, считать, что миллионы людей вокруг - идиоты, один Вы всё правильно понимаете. Особенно среди людей, которые не ради заработка шлёпают "поделки".
Знаете ли, для скольких архитектур процессоров существует дистрибутив ПО под общим названием Debian?
Попробуйте написать программу, а лучше - несколько десятков тысяч программ разной сложности, которые почти в полном объёме переносимы на десяток совершенно разных архитектур. Тогда поймёте, что та сложность, которая присутствует даже в самых простых, но универсальных, переносимых (и т.п.) программах - это минимально возможная сложность, ошлифованная и оптимизированная многими программистами в течении многих лет.
А чтобы направить свой антиглобалистский пыл в правильное русло, советую почитать серьёзную литературу по философии Unix/Linux, например, шикарную книгу "Искусство программирования для UNIX" (Эрик С. Реймонд), из которой вы узнаете, в чём конкретно принципы проектирования большей части коммерческого ПО противоположна философии UNIX.
ответить
Пять минут смеха продлевают жизнь на сутки
Ситуация, ей-богу, начинает меня забавлять. Я уж думал, вы сдулись, но ни фига — таки припёрлись опять, причём только для того, чтобы вывалить толпу «аргументов», содержательная ценность которых приблизительно равна сакраментальному утверждению «сам дурак». У вас по существу-то есть что возразить? Ну а пока вы об этом думаете, проведём работу над ошибками.
Насчёт спарков: ну опять вы со своими ракетами. Не волнуют меня суперкомпьютеры, и в особенности меня не волнует top500, представляющий собой бессмысленное мерянье пиписьками, исполняемое, что несколько обидно, за чужой счёт (иногда, замечу, и мой счёт, я ведь тоже налоги плачу). Попадание в верхние позиции top500 означает ровно одно: у кого-то нашлось больше лишних (при этом чужих) денег, чем у других. Вы вот мне скажите, где мне сейчас купить десктоп на спарке, чтобы его на стол поставить, взгромоздить на него тот самый Debian (NB: разумеется, я знаю, на скольких платформах он работает; я, знаете ли, с Linux работаю с 1994 года, а с 1997 — только с ним; больше того, можно было бы заметить, что я и в проекте Openwall участвую, и не только в нём) — так вот, взгромоздить и использовать в качестве рабочего инструмента заместо этого идиотского интела. Что до задач — NASA человека на Луну запустила, обладая совокупной вычислительной мощностью в разы меньшей, нежели мощность современного мобильника. Если программы писать через... ээ... короче, если их как попало писать, то вам любого суперкомпьютера окажется мало. А этот ваш первый в top500 жрёт почти 13 мегаватт, то есть он за месяц одного электричества съедает на сумму, приблизительно соответствующую стоимости строительства многоквартирного дома. Меня это обстоятельство интересует гораздо больше, чем те прожорливые модели, которые на нём обсчитываются.
Писать переносимые программы я не только «пробовал», я много раз это делал, причём мне приходилось писать программы, переносимые между *nix'ом и виндой — это посложнее будет. И я на собственном опыте знаю, что при аккуратной работе и разборчивости в выборе библиотек все проблемы переносимости решаются парочкой #ifdef'ов. При этом я неоднократно (уже в роли майнтейнера пакетов для того же Openwall/*/GNU Linux) сталкивался с подельями идиотов, взявших на вооружение GNU automake/autoconf и сделавших в итоге так, что их ./configure сам по себе зависит от бОльшего количества внешних условий, чем основная программа. То есть средство, которое должно бы по идее обеспечивать переносимость, в итоге само оказалось основным источником _не_переносимостей.
Миллионы людей вокруг, как это ни печально, действительно идиоты, идиоты вообще преобладают. Среди программистов идиотов меньше, чем «в целом по больнице», но и тут их более чем хватает, и сто три системных вызова, выданные программой, которая по сути своей должна была бы состоять из трёх машинных команд — тому подтверждение (кстати, опять же — по существу есть что сказать на эту тему? Или вы всерьёз полагаете, что 103 вызова в исполнении /bin/true — это нормально?) Но идиоты идиотами, а с чего это вы решили, что я «один»? Между делом, круг моих знакомств среди людей, имеющих прямое отношение к ядрам и дистрибутивам, тоже можно было бы достаточно легко установить — ссылки есть прямо здесь на сайте, да и на гугле никого пока не забанили. Не, ну ладно, вы вот другое скажите: вы пробовали когда-нибудь читать исходники glibc? Я пробовал. Эти люди мне бы зачёт не сдали со своим кодинг стайлом (как они сами ЭТО читают — для меня вопрос открытый). А ещё мне как-то раз пришлось в GNU tar добавлять лишнюю опцию, так я туде тоже занырнул. И сходу нашел супер-конструкцию: парочка не-статических функций в модуле (не только не статических, но и вынесенных в хидер), которые реально вызываются только из статических (!) функций того же модуля. Причём всё это было обнаружено при попытке пофиксить два предупреждения компилятора. Мой отчёт по этому поводу можно вот тут, например, посмотреть: http://permalink.gmane.org/gmane.comp.gnu.tar.bugs/3124 Что такое GNU tar, насколько плотно оно используется — объяснять надо? И что можно сказать о таких вывертах в официальном релизе? (NB: я вообще ничего специально не искал, это был мой первый и последний опыт правки мейнстримовых программ — и сходу вот такое).
Книжка Реймонда — она ничего, да (хотя утверждение о том, что pipe — механизм устаревший, поскольку есть сокеты, мне глаз резануло в своё время весьма и весьма). Пару раз я её уже читал, перечитывать в третий раз, пожалуй, всё-таки не стану, некогда. Кстати, вы могли бы и заметить, что в моей книжке 2006 года издания имеются ссылки и на Реймонда, и на Стивенса, и на Танненбаума (хотя его я не люблю, он вечно пишет не о том), и на Торвальдса. Но за язык никто не тянул: берём с полки Реймонда и читаем главу 20. Лучше с карандашиком. Хотя что-то мне сдаётся, что вы сами Реймонда если и открывали, то ни хрена там не увидели.
Но самое занятное, конечно, что вы меня антиглобалистом назвали — вот тут я, извините, долго ржал. Я вообще-то либертарианец, а либертарианство и антиглобализм несовместимы принципиально. Опять же, мою принадлежность к либертарианцам можно было бы установить прямо тут, вот на этом же сайте, из текста вот этого вот сборника. Тьфу.
Да, так вот — мы с вами что-то в неравном положении. Вам про меня известно практически всё — можно легко простым поиском узнать моё имя, возраст, квалификацию, место работы, список публикаций, информацию об участии в разных проектах и всё прочее (если вы этого ещё не сделали, то это исключительно ваши проблемы), но вот мне про вас неизвестно вообще ничего, кроме имени. При этом вы тут пальцы гнёте, что я якобы о том не слышал, того не видел, этого не читал, того не делал, сего не пробовал (хотя я и видел, слышал, и делал, и читал, и пробовал) — а вы сами-то чем можете похвастаться? Основания для пальцовки есть? Или кроме пальцев ни хрена за душой? Пока что от ваших постов впечатление именно такое.
ответить
☞ From Юрий (unverified) Tue Nov 15 19:53:00 2011 UTC
Спасибо за
Спасибо за совет. Учту на будущее.
У меня к Вам есть вопрос по поводу реализации алгоритма временной задержки (таймерной привязки) для процессоров семейства i32, но, скорее всего, это уже частный вопрос, не относящийся к теме. Если у Вас нет времени, или нет желания на всё это -- отпишитесь пожалуйста (на сайте , или на мой почтовый ящик: [email removed]). С уважением, Юрий.
Удачи!
ответить
К сожалению,
К сожалению, готового ответа у меня нет, а исследовать вопрос действительно нет времени совершенно.
ответить
☞ From Юрий (unverified) Mon Nov 14 20:56:00 2011 UTC
Обсуждение книги
Здравствуйте! Заинтересовался Вашей книгой, в данный момент изучаю. Сам я,конечно, "страшно далёк от народа", не могу аргументированно возразить ни Вам, ни Вашему сопернику, да и нужды в этом нет. Вы - консервативен,минималистичен,реален(в своём мировоззрении), он - наоборот, максималист. Я не могу не согласиться, что "сегодняшние" программисты всё чаще и чаще используют шаблонный подход ко многим задачам, здесь есть и плюсы и минусы. С одной стороны - зачем изобретать велосипед, можно использовать готовые библиотеки и модули,вызывая их десятки и сотни раз в своих программах, облегчая себе задачу и, неминуемо, раздувая общий "вес" программы в целом.Но при этом, однако, теряется оригинальный подход к делу, возможно, потенциально более рациональное решение.Иными словами - застой в более продуктивной реализации программного продукта, но выигрыш в стабильности, проверенности, скажем так. Хотя, не всегда то,что является старым и проверенным на деле ВСЕГДА оказывается правильным,как потом выясняется. Понятие "правильности" относительно и актуально лишь на определённый момент времени, возможно потом окажется "более правильным" иной подход. Но и с другой стороны: если бы мы использовали строго консервативный подход к модернизации имеющегося у нас оборудования (железа), и выжимали из него буквально всё, заставляя программистов потеть для более оптимального решения (составления программы) тем самым повышая их профессиональный уровень - мы так бы до сих пор,наверно, сидели за 8-ми разрядными процессорами типа КР580ВМ1 или Z80 (Zilog) c 64 кБ памяти на борту, а иногда и того меньше, и пытались бы подогнать наши существующие потребности под эти "габариты". А вообще тему, которую Вы затронули, можно развивать до бесконечности и я просто признателен и Вам, и Вашему оппоненту , и всем тем,кто действительно пытался обсудить данный вопрос именно "по делу", а не быть безразличным ко всему происходящему, каким, увы, является очень большой процент современной молодёжи.Но повторяюсь, ни возразить, не поддержать я никого не могу, ибо "выпал из колеи" современного развития компьютерной индустрии лет эдак 20 назад. Я раньше занимался программированием на языке ассемблер под процессоры Z80 для пк ZX-Spectrum ( Zeus assembler), поэтому все мои теперяшние познания в программировании практически равны 0. Но всё равно сел вот за книги (ваши в том числе).Я не считаю, что программирование на чистом ассемблере является нецелесообразным. Всё в мире относительно. Для меня, допустим, интересна ОС Колибри, написанная на чистом FASM,многозадачная,перспективная ОС. Вы скажете: это несерьёзно, у этой ОС нет будущего, что я дилетант, и этой операционкой занимаются дилетанты.Возможно в чём-то и будете правы,Вам виднее как опытному программисту. Но вспомните, ведь и ядра Linux бы не появилось в своё время, и FREEBSD, все работали бы и модифицировали UNIX. Я благодарен и Вам, и всем тем, кто освещает подобные "редкие" темы, кто не стоит на месте и пытается двигаться вперёд, а не просто сидит у экрана монитора с отвисшей челюстью, гоняет GTA или World Of Warcraft и тупо рассуждает на тему " Мой комп тупит, надо побольше оперативы,проц побестрее, сборку винды получще (экстрим там или зверька ) и всё пойдёт ок". Поверьте, ужасно слышать такие суждения, причём это происходит всё чаще и чаще. Удачи Вам! Спасибо за книгу.
ответить
Комментарий
Для начала дам небольшой совет (знаю, что непрошенный, но уж раз пришли — :-) ) -- ознакомьтесь с правилами сочетания пробелов и знаков препинания. Ну вот хотя бы здесь: http://www.proza.ru/diary/drcroco/2011-09-10
Ну а по существу... мне сложно что-то ответить, вы мне приписываете тезисы, которых я не выдвигал, и аргументы, которых я не произносил, как мне тут что-то отвечать? Вот та же колибри -- у неё действительно нет перспектив, но отнюдь не потому, что она маленькая и шустрая, а потому, что всё написанное на асме привязано к конкретному процессору и от него зависит, вон через два-три года окончательно забудут про i32, будет везде эта вот 64-битка (у меня она тоже рано или поздно появится, хотя и не раньше, чем стоимость б/у системного блока упадёт до ста баксов), но это ещё полбеды, а если Intel совсем загнётся? Например, его ARM начнёт всерьёз теснить? Ведь язык Си появился, когда Кену Томпсону стало лень переписывать Unix под уже третью архитектуру. "Старое и проверенное", знаете ли, я тоже никогда не считал истиной в последней инстанции -- про заведомую негодность существующей Glibc, заметим, именно я упомянул.
Я вот тут недели три назад запустил F-19 в dosbox'е. Dosbox -- это интерпретатор старого машинного кода, то есть работает он ну оооооочень медленно, но F-19 когда-то летал на IBM XT с CGA-монитором (говорю на собственном опыте: я сам в него играл на XT), так что в dosbox'е на моём дохлом celeron'е чувствует себя просто замечательно. Современные игрушки требуют ресурсов в десятки тысяч раз больше, а стали ли они от этого доставлять пользователю больше кайфа? Супер-пупер-графику и всё остальное, на что уходят ресурсы, пользователь перестаёт замечать через пять минут. Это я к тому, что да, не умеют нынче программы писать эффективно; только ассемблер тут, извините, ни при чём. Эффективность программ на Си -- если их писать правильно -- в большинстве случаев оказывается _выше_. "Внезапно", как сейчас модно говорить.
ответить
☞ From Игорь (unverified) Sun Nov 6 11:00:00 2011 UTC
Спасибо
Спасибо большое за хорошую книгу. К сожалению, это большая редкость - книга по ассемблеру для юникс. Однако, хочу присоединиться к предыдущим комментаторам и сказать, что все-таки очень не хватает описания ассемблера для х64. Каково бы ни было Ваше отношение к современным тенденциям, это реальность, к тому же реальность востребованная самыми разными людьми, и не только для игр. Я занимаюсь моделированием физических процессов в атмосфере, и использование больших объемов памяти дает мне немалый выигрыш в скорости расчетов. Нет у Вас планов сделать что-то в виде приложения к уже изданной книге?
Еще один вопрос интересует - устройство позиционно-независимого кода. Если для х86 все более или менее понятно (есть довольно подробная информация в мануале NASM), то про х64 полное молчание. Может, Вы посоветуете, где можно почитать?
ответить
Пожалуйста
Реальность -- это то, что реально происходит. В мою реальность 64-битные машины не проникли и ещё долго не проникнут, поскольку для имеющихся задач мне это не нужно. Чтобы написать книгу по ассемблеру для x64, мне для начала придётся купить соответствующий компьютер, потом потратить уйму времени на изучение новой архитектуры, и ничего взамен не получить кроме сомнительного морального удовлетворения. Так что ответ на ваш вопрос, собственно говоря, уже был дан в комментариях выше, и остаётся прежним: нет, я не буду заниматься 64-битными архитектурами, и их описание не входит в мои планы ни в каком виде. Ну разве что произойдёт чудо и найдутся идиоты, готовые создание такой книги профинансировать, причём не по договору авторского заказа (такой я не подпишу, противоречит убеждениям), а в порядке спонсорско-грантовом. Но поскольку чудес не бывает, идиотов таких не найдётся.
Что касается моделирования физических процессов в атмосфере, то здесь, я полагаю, язык ассемблера вообще никак и низачем не нужен: пишите лучше на Фортране, или на Си, или ещё на чём-то, но уж никак не на асме. Это бессмысленная трата времени, по быстродействию вы всё равно не переплюнете существующие математические библиотеки, да и если и переплюнете, то разве что на жалкие проценты; а жизнь коротка.
ответить
Пишу,
Пишу, естественно, на С со всякими OpenMP и прочее, но некоторые небольшие функции оптимизировал на ассемблере. При этом была ощутимая отдача в продуктивности. Еще раз спасибо за книгу.
ответить
Спонсоры найдутся
Ну почему же, на http://www.kickstarter.com/ не раз предлагали разные проекты и находились спонсоры.
Так что можете составлять бюджет (покупку ПК, окупанием своего времени на изучение архитектуры) и описание плана по написанию книги.
ответить
Подельями ублюдков не пользуемся
С отключённым JS я на этот ваш кикстартер зайти не смог. Следовательно, мне там делать нечего.
ответить
Хотя kickstarter
Хотя kickstarter пример и не очень хороший, но все таки в умелых руках JS очень повышает юзабилити, а временами позволяет делать очень удобные и мощные программы-сайты, например полноценные IDE или музыкальные плееры.
Конечно, если посмотреть на strace javascript кода можно увидеть просто невероятные числа, но, зато, код на JS полностью абстрагирован от реального железа и не зависит от среды выполнения.
С другой стороны - kickstarter отличный сайт, если у вас есть идея, но нет денег. Но там, обычно, собирают деньги на больше забавные проекты, например игры. Еще на звезду смерти собирают, и собрали достаточно много.
И еще у вас капча адская, у меня около 5 попыток ушло.
ответить
только массовые расстрелы спасут цивилизацию
Начать с того, что...
в умелых руках JS
... что в умелых руках JS оказаться не может, потому что умелые руки об него пачкаться не станут. Человек, мало-мальски понимающий, что он делает, никогда, ни при каких условиях не станет применять JS на сайте. Иное дело, что в современных условиях грамотные люди в веб-разработке не задерживаются.
JS очень повышает юзабилити
Смешно, да. Ну давайте посмотрим, как реально обстоят дела с этой вашей юзабилити. Лично я обычно просто не хожу на сайты, которые не работают без JS, то есть вообще не хожу — точно так же, как не хожу, например, в такие магазины, где продавцы хамят и матерят покупателей. Но, увы, есть парочка сайтов (буквально: два), которые мне использовать приходится, несмотря на наличие там JS и невозможности работы без него. Так вот, чтобы зайти на такой сайт, мне приходится на рабочей машине держать специально для этого пустой аккаунт, на котором периодически сносится всё, что там успел нагвоздить браузер; перед заходом на JS-нутые сайты я делаю
ssh -X bolvan@localhostи уже там запускаю браузер. Это вы называете "повышением юзабилити"?!NB: у любого сколь бы то ни было технически грамотного человека JS в браузере должен быть выключен. Period. А дальше те, кто пользуются *nix-системами, хотя бы могут делать как я — гонять второй браузер из-под чистого и изолированного аккаунта, тогда как пользователи Win и прочей нечисти не имеют даже этой возможности. Но ублюдков-вебразработчиков, разумеется, это не волнует, потому что, видимо, они всерьёз не понимают, почему это всё так.
программы-сайты, например полноценные IDE
IDE не имеют права на существование вообще, то есть изначально. Что касается идеи IDE как браузерного приложения, то автора этой идеи следовало бы, как мне кажется, изолировать от общества. Этот псих опасен для окружающих.
или музыкальные плееры
Я знаю только одно применение для браузерного плеера — сделать так, чтобы скачанная пользователем музыка при этом не сохранялась локально на компьютере пользователя. При этом неискушенные пользователи уверены, что они вообще ничего не скачали (реально, сам таких видел). Тех, кто это всё делает, следует подвергнуть смертной казни в особо продвинутой форме — например, путём утопления в бочке с дерьмом. Публичного.
код на JS полностью абстрагирован от реального железа и не зависит от среды выполнения
То же самое можно сказать про любой интерпретируемый язык, а равно и про язык, который компилируется в байткод. И это никоим образом не повод иметь в браузере интерпретатор любого алгоритмически полного языка, неважно, JS это или что-то ещё. Кстати, от среды выполнения JS очень даже зависит — если статический HTML ещё более-менее реально заставить выглядеть одинаково в разных браузерах, то заставить JS вести себя всегда одинаково — невозможно в принципе, это превышает возможности человека.
ответить
Юзабилити
> Так вот, чтобы зайти на такой сайт, мне приходится на рабочей машине держать специально для этого пустой аккаунт, на котором периодически сносится всё, что там успел нагвоздить браузер; перед заходом на JS-нутые сайты я делаю ssh -X bolvan@localhost и уже там запускаю браузер. Это вы называете "повышением юзабилити"?!
Нет, я бы назвал это паранойей :) Для Вас специально в браузере Firefox существует "Приватный просмотр", при котором ничего никуда не гадится. Включается он через меню или кнопками Ctrl+Shift+P, и никаких бредней с ssh и отдельным браузером нифиг не нужно.
Для страдающих запущенной формой паранои, режим приватного просмотра сайтов можно сделать умолчательным :)
Подробнее: http://support.mozilla.org/ru/kb/privatnyj-prosmotr-prosmotr-veb-stranic-bez-sohran
И да, яваскрипт позволяет делать таки сайты удобнее. Но это уже другая история...
ответить
Нет, я бы назвал
Нет, я бы назвал это паранойей :)
Совершенно верно, это называется паранойей. Когда дело касается сферы IT, паранойя являет собой признак профессиональной пригодности. Причём много её не бывает. И нечего мне тут лыбицца, ага. Людям, лишенным паранойи, вообще нельзя приближаться к компьютерам.
Для Вас специально в браузере Firefox существует "Приватный просмотр",
Мне эта штука ничем не поможет. То есть вообще. Потому что никакие опции браузера по определению не могут закрыть дыры того же браузера и — особенно — виртуальных машинок, в которых выполняется приехавший непойми откуда и непойми что вытворяющий алгоритмически полный код.
Пора бы знать, что от глюков программы невозможно защититься средствами самой этой программы. Защите, которая в *nix'ах разграничивает полномочия пользователей, я с горем пополам доверяю (заметим, при этом, например, нельзя пользоваться всяческими su, sudo и другими подобными вещами, которыми нынче пользуется практически каждый админ), но вот "опциям браузера" в качестве защиты может доверять только, извините, идиот. Этот браузер, простите, раз в неделю в корку падает, а на stderr высыпает (ВСЕГДА, даже при отключённом JS) кучу сообщений о нарушениях assert'ов. То есть эту программу не контролирует НИКТО, даже разработчики. Какие к дьяволу при этом опции, окститесь.
При этом, не имея возможности к исполнению алгоритмически полного кода, злоумышленник вряд ли получит контроль над моим браузером, а вот с использованием JS и прочего задача взломщика облегчается раз этак в сто. Между прочим, то и дело во всех этих виртуальных машинках находят remote code execution, года не проходит, чтобы очередная дыра не всплыла.
И да, яваскрипт позволяет делать таки сайты удобнее.
Руки бы вам оторвать. Медленно, по кусочку. С прямой трансляцией по телевиденью. В назидание другим. А потом ещё в лоб дать, чтобы не зная падежов, не болтали глупостев.
ответить
Что-то вас заносит
> не имея возможности к исполнению алгоритмически полного кода, злоумышленник вряд ли получит контроль над моим браузером
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом. Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки. Неужели вы и картинки тоже поотключали для пущей безопасности? :)
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть флеш включить, хоть яву, хоть сильверлайт в браузере, но если он регулярно обновляется, то взлома вам ждать придётся до следующего века.
Кроме того, моя паранойя мне говорит, что такие данные, утечка которых могла бы Вас "сильно огорчить", вообще не должны находиться на компьютере. А всё что есть на моём компе я готов любому показать и так :)
ответить
Ну что же, тут нужен ликбез
Ой. я вас умоляю. Безопасность браузера слабо коррелирует с яваскриптом
Судя по вашим дальнейшим сентенциям, в безопасности вы вообще ничего не понимаете. Как, впрочем, и большинство людей, в том числе и «профессиональных айтишников» (кавычки выделены жирным). Но я — понимаю, и смею заверить, что связь тут самая прямая. Некоторые пояснения даны ниже.
Мне, наверное, будет достаточно напомнить Вам об эпичной дырище с эксплойтами через jpeg картинки
Это вы не вот этот вот, случайно, имеете в виду?
http://nakedsecurity.sophos.com/2012/06/19/ie-remote-code-execution-vulnerability-being-actively-exploited-in-the-wild/
Это, во-первых, IE (ну, если человек использует Windows, то о безопасности ему можно забыть, а если он ещё и IE гоняет, то ему поможет разве что бригада докторов). А во-вторых, там сразу, то есть прямо сходу, упоминается, что Cunningly-crafted JavaScript code - which can be embedded in a web page to foist the exploit on unsuspecting vistors - is circulating freely on the internet. Как говорится, sapienti sat.
Можно ещё вот такое вспомнить: https://bugzilla.redhat.com/show_bug.cgi?id=639920 Тоже задействованы JPEG'и, и — surprise — речь идёт о Java. Правда, не JS. Ну, обычная Java уже по умолчанию в большинстве браузеров выключена, но принцип всё тот же: есть интерпретатор — есть дыра, нет интерпретатора — нет дыры.
Информации об эксплойтабельных дырах, которые используют JPEG, но при этом не зависят от интерпретатора на стороне ломаемого клиента, сходу не нашел. Ссылку в студию — интересно, о какой дыре идёт речь и что через неё можно было сделать.
В любом случае, дыры бывают, конечно, разные, но если дыра в коде распаковщика JPEG — это (а) последствия безалаберности программиста и (б) как правило, через такую дыру сложно сделать что-то серьёзное, то дыра в алгоритмически полном интерпретаторе (любом) — это, во-первых, свойство предметной области (т.е. недырявых интерпретаторов не бывает, вопрос только в скорости обнаружения дыр и в том, кто первый до неё, дыры, доберётся) и во-вторых, сам факт наличия интерпретатора сильно облегчает взломщику дальнейшую работу после того, как взлом уже состоялся.
В своей паранойе вы забываете о том, что для того, чтобы вас взломали, вы должны кого-то заинтересовать. Если ваши данные никому не интересны, коммерческой ценности не имеют, то можете хоть
Это верно только для случая, когда взлом моей машины выполняется вручную (человеком) и целенаправленно (то есть целью взлома являюсь именно я, а не "просто кто-нибудь"). Если дело до этого дойдёт, то маловероятно, что ломать меня будут через браузер, потому что для этого нужно сначала узнать, на каких сайтах я бываю, потом получить к ним админский доступ (желаю успехов), и только потом что-то может получиться. Ну то есть со мной, конечно, не получится.
Эксплойты, работающие через JS/flash/прочее, обычно нацелены не на конкретную машину и не на конкретного пользователя, а на бомбардировку по площадям. Целью такой бомбардировки является установление контроля над возможно бОльшим количеством случайных машин с целью, например, ретрансляции спама или организации DDoS-атак. Слышали такое понятие "ботнет"?
Кроме того, нельзя забывать про обыкновенный вандализм, не имеющий целью ни личное обогащение, ни шпионаж, а только "сделать бяку". Для вандалов JS — просто золотая жила, ведь, скажем, атакам типа denial of service оно подвержено имманентно, просто в силу того, что время рендеринга статической страницы есть некая функция от её длины, тогда как время исполнения алгоритмически полного кода от его длины никак не зависит и, более того, не может быть предсказано ВООБЩЕ (сие есть алгоритмически неразрешимая проблема).
Наконец, есть ещё и попросту сволочные авторы сайтов, всерьёз полагающие, что они вправе решать за пользователя, что пользователю делать, а что нет. Например, JS позволяет задать пользователю вопрос, от ответа на который отказаться можно, разве что пристрелив браузер. В частности, vk.com такое делает для аккаунтов, зарегистрированных до повального затребования номеров мобильных телефонов: введите, мол, свой номер мобильника, и точка. Возможность отказа попросту не предусмотрена, диалог модальный, кнопки Cancel нет. Я уже молчу про всевозможные ползающие, подпрыгивающие, уворачивающиеся от мышки и т.п. элементы оформления страницы, которые заодно заставляют страницу, точнее, браузер при открытии этой страницы, жутко тормозить. Так вот, я совершенно не желаю никому давать таким вот способом развлекаться в МОЁМ браузере.
Подчёркиваю: ни вандализм, ни формирование ботнетов, ни проявление мразостной сущности разработчиков сайтов — то есть как раз всё то, для чего может быть применена дырявость JS — никак не зависят от наличия или отсутствия на моей машине "коммерчески ценной информации". Впрочем, см. ниже.
Кроме того, моя паранойя мне говорит, что такие данные, утечка которых могла бы Вас "сильно огорчить", вообще не должны находиться на компьютере. А всё что есть на моём компе я готов любому показать и так :)
Людей с такими воззрениями следует сажать в клетки и подвергать интенсивной психиатрической терапии, потому что они, эти люди, опасны для окружающих. Для себя-то ещё ладно, тут каждый вправе решать сам. Но я более чем уверен, что на вашем компьютере есть (или с вашего компьютера вы осуществляете доступ к, что практически то же самое) информация, раскрытия которой не хотели бы, например, люди, с которыми вы переписываетесь или общаетесь через IM. Например, сами по себе архивы почты и логи IM; если, скажем, кто-нибудь из моих визави выложит переписку со мной в открытый доступ, я пойду ему бить морду, даже не разбираясь, попало ли в этот архив что-то серьёзное.
Более того, коммерческую ценность, пусть и сравнительно небольшую, представляет сейчас любая информация, связанная с человеком. Google вон в узел завязывается и из кожи вон лезет, чтобы пропускать через себя как можно больше персональной информации — история поисковых запросов, содержимое писем в ящиках Gmail'а, содержимое документов в GoogleDocs — всё у них идёт в дело. Пока единственной их целью является таргетинг рекламы. Ключевое слово "пока".
Ну а что до меня, то я со своей рабочей машины осуществляю доступ к серверам, в том числе принадлежащим другим лицам (в порядке оказания услуг по удалённому администрированию). Взлом моего основного аккаунта равносилен получению доступа ко всем этим серверам. Одного этого уже более чем достаточно, чтобы о неразборчивости в плане безопасности не могло идти никакой речи. Но, подчеркну, дело тут не в этом; это скорее лишь иллюстрация того, по каким причинам недопустимо наплевательское отношение к безопасности. Название этому — безответственность. В самом худшем смысле этого слова.
ответить
Защите, которая
Защите, которая в *nix'ах разграничивает полномочия пользователей, я с горем пополам доверяю (заметим, при этом, например, нельзя пользоваться всяческими su, sudo и другими подобными вещами, которыми нынче пользуется практически каждый админ)
Прошу прощения за любопытство, а что не так с su и sudo, и чем же тогда следует пользоваться вместо них?
ответить
Ну здрасссссте
Если вы из-под аккаунта с одними полномочиями осуществляете доступ к аккаунту с другими полномочиями, то с точки зрения безопасности компрометация первого автоматически влечёт компрометацию второго. Из этого следует, что в сеансе работы нельзя повышать полномочия. Понижать можно, повышать нельзя. Вообще нельзя, понимаете? Никаким способом. В этом плане sudo вообще попадает под категорический запрет, а su остаётся в системе (без suid-бита) для понижения полномочий при возникновении такой потребности. "Вместо" них пользоваться нельзя ничем, ssh root@localhost тоже делать нельзя. Если нужны права root'а, в систему следует изначально зайти под root'ом. Если машина локальная, то переключиться на текстовую консоль и на ней зайти. Если удалённый доступ, то ssh root@remote-host, только следует при этом понимать, что тот аккаунт, под которым вы работаете на своей рабочей станции и из-под которого делаете этот вот ssh root@somewhere, охранять надо аки зеницу ока, уж во всяком случае браузеры под ним гонять нельзя совершенно точно.
А уж как надо беречь root на такой станции — ну, можно не объяснять. Почему-то часто встречаются админы, которые уверены, что аккаунты серверов надо беречь сильно-сильно, а аккаунты на личных машинах "типа фиг с ними". Ну так вот они заблуждаются: компрометация любого аккаунта означает компрометацию всего, к чему из-под него осуществляется доступ. Компрометация личного админского ноута означает компрометацию всех серверов, которые он админит.
У меня встречный вопрос: а что, это всё не очевидно?
ответить
Очевидно, да не совсем
Если удалённый доступ, то ssh root@remote-host, только следует при этом понимать, что тот аккаунт, под которым вы работаете на своей рабочей станции и из-под которого делаете этот вот ssh root@somewhere, охранять надо аки зеницу ока
Чем в таком случае удалённый доступ к remote серверу будет принципиально отличаться в плане безопасности от su - или ssh root@localhost? Чем localhost хуже любого другого адреса, если эта учётная запись охраняется как зеница ока? Безусловно, локальный вход под рутом из текстовой консоли будет безопаснее, но для большинства пользователей крайне нежелательна компрометация именно пользовательского аккаунта, а не root-а, так как систему переустановить гораздо проще, чем восстановить свои данные или получить проблемы из-за их утечки.
уж во всяком случае браузеры под ним гонять нельзя совершенно точно.
С этим я соглашусь, причём по-хорошему, на мой взгляд, браузер нужно запускать под отдельным пользователем всегда, а не только если возникла необходимость включить javascript или что-либо похуже. Другой вопрос, что на практике это делают редко.
ответить
Чем в таком
Чем в таком случае удалённый доступ к remote серверу будет принципиально отличаться в плане безопасности от su - или ssh root@localhost?
Если на сервере есть непривилегированный аккаунт, то он, очевидно, там для чего-то нужен. Если из-под него делают ssh root@localhost, то это примерно то же самое, как вообще всё на том сервере гонять под root'ом.
Удалённый доступ лучше, например, тем, что его можно делать из-под специально для этого предназначенной учётной записи на рабочей станции. Как ни странно (хотя совсем не странно, если подумать), при должном умении аккаунт рабочей станции оказывается более защищённым, чем аккаунт сервера, и к тому же на этом аккаунте мы можем ничего не делать, кроме ssh root@server.
для большинства пользователей крайне нежелательна компрометация именно пользовательского аккаунта, а не root-а, так как систему переустановить гораздо проще, чем восстановить свои данные или получить проблемы из-за их утечки.
Компрометация root'а на машине — это, собственно говоря, всё, то есть скомпрометирована при этом вся машина целиком. В частности, если для разных видов работ у нас разные непривилегированные аккаунты, то компрометация одного из них — это, конечно, неприятно, но хотя бы остальные при этом остаются в прежнем статусе; а вот если root — ну всё, хана.
Посему набор периметров выглядит (ну, для меня) примерно так:
Можно ли ходить из одной записи на другую, во многих случаях определяется из соображений здравого смысла: если одна из них определённо "главнее" другой, то с вот этой другой на первую ходить нельзя.
ответить
Вряд ли вас
Вряд ли вас переубежу, но в многопользовательском варианте использования серверов без него никуда.
Например, есть несколько машин и несколько админов, админы могут заменять друг друга (сменные дежурства, выходные, отпуска и т.п.) и при этом должны иметь возможность что-то сделать от рута на любой из машин (чтобы не ждать Васю, который в отпуске). В добавок было бы не лишним записывать кто и что навыполнял от рута.
В таком варианте использования sudo очень даже к месту, т.к. разрешив админам выполнять от sudo команды, можно писать в лог исполненные команды, при этом будет видно от какого пользователя что выполнено, а не просто что все команды выполнены от рута. Если же всем дать пароль рута, такого журналирования не будет. Всякие способы запуска шелла через sudo - конечно же запретить.
Если админ уволится, то достаточно заблокировать его аккаунт, а не менять пароль рута на всех машинах и сообщать его оставшимся админам в email рассылке. Этот пароль вообще никому сообщать не нужно в случае настроенного sudo.
ответить
Да уж конечно не переубедите
Как можно заметить, у меня довольно обширный опыт коллективного администрирования серверов, и я на собственном опыте знаю, что sudo совершенно не нужен (плюс к тому -- см. выше, он ещё и недопустим, притом категорически). Разумеется, сообщать пароль рута нельзя никому, пароли вообще никогда никто и никому сообщать не должен. Вообще, понимаете? Никогда, никто, никому. Человек сам себе ставит пароли и никогда их никому не говорит. Но это и не нужно, и sudo тут ни при чём.
Просто у каждого админа должен быть СВОЙ аккаунт с нулевым uid'ом. В коллективах, где работал я, обычно мы такие аккаунты называли с префиксом r_. Например, мой личный root на всех машинах назывался r_croco.
Что касается логгинга выполняемых команд -- польза от него несравнима с зияющей дырой в безопасности, которая открывается из-за наличия sudo.
А ещё -- если использовать криптоключики и authorized_keys, то можно обойтись и одним аккаунтом рута.
ответить
А что не так с IDE?
IDE не имеют права на существование вообще, то есть изначально.
А что не так с IDE? Я ещё могу понять, что обучение начинать с IDE неправильно. Но чего такого неправильного в использовании IDE при наличии понимания происходящего?
Что касается идеи IDE как браузерного приложения, то автора этой идеи следовало бы, как мне кажется, изолировать от общества. Этот псих опасен для окружающих.
А вот с этим не могу не согласиться.
ответить
Что не так с IDE
Ну как это "что не так", очевидно же. Среда разработки состоит из множества компонентов, и их выбор — во многом дело вкуса программиста. И вот теперь мы видим этот безумный вариант "всё в одном": компилятор и текстовый редактор, плюс к ним отладчик, сборщик, профилировщик, ещё и контроль версий (хорошо если просто клиент к существующим системам, а то ведь можно и свою сотворить), итд. Почему, вот с какого такого бодуна, если мне нравится компилятор, то мне "должен" понравиться также и редактор текстов, который с ним насильно соединили? (Лично мне, кстати, не понравится совершенно точно: я не видел ни одной IDE, в которой редактор текстов хотя бы отдалённо напоминал vim). Когда я сам для себя подбираю набор инструментов, я могу выбрать каждый отдельно; идея IDE как раз в том, чтобы такой выбор у меня отобрать.
Про их (IDE) громоздкость и монструозность, про использование проприетарных форматов где ни попадя (попробуйте файл проекта расшифровать) — это я уже молчу.
ответить
Да разве?
Почему, вот с какого такого бодуна, если мне нравится компилятор, то мне "должен" понравиться также и редактор текстов, который с ним насильно соединили?
Так в любом нормальном IDE "гвоздями" прибит только текстовый редактор и парсер исходного кода на том или ином языке программирования (для того, чтобы работало автодополнение и подсказки прототипов функций при их вызове). Всё остальное можно выбрать самому.
Например, в QtCreator можно в качестве команды сборки указать любую консольную команду с любыми аргументами - от банального make или build.sh до ssh, который будет выполнять сборку на удалённом сервере. Про компилятор IDE может вообще не знать. Конечно, ему неплохо бы знать про формат, в котором компилятор выдаёт сообщения об ошибках, чтобы предствавлять их в удобном виде и при клике мышью в нужном месте, либо нажатию клавиши автоматически переходить в нужное место в коде. Но и это настраивается: в частности, тот же Qt Creator поддерживает форматы для gcc, clang, а также (извиняюсь за неприличное на этом сайте слово) msvc и позволяет добавлять свои собственные.
Аналогично дело обстоит и с отладчиками, хотя для того, чтобы поддержать новый отладчик, может быть и не достаточно настроек, а нужно писать plugin для IDE. Впрочем, gdb поддерживают все разумные IDE, хотя качество графических обёрток во всех IDE, что я видел, увы, оставляет желать лучшего. Впрочем, почти везде можно выполнять консольные команды gdb как при обычном запуске. Ну и запуск gdb отдельно от IDE в особо тяжёлых случаях тоже никто не отменял.
попробуйте файл проекта расшифровать
Да без проблем, тот же QtCreator поддерживает проекты вида "простой текстовый список файлов". Для других IDE есть инструменты, позволяющие генерировать проекты по текстовому списку. Зачем его обратно расшифровывать? Он же не является первичной информацией о составе файлов проекта, а является временным файлом, который нужен только при использовании этой IDE (сборку проекта из консоли можно делать и без него).
Лично мне, кстати, не понравится совершенно точно: я не видел ни одной IDE, в которой редактор текстов хотя бы отдалённо напоминал vim
Вообще во многих IDE, включая вышеупомянутый QtCreator, есть vim-mode, хотя, скорее, всего, он может не дотягивать до оригинального vim-а. Мне сложно об этом судить, так как vim я знаю только на уровне "поправить конфигурационный файл".
Кстати, насколько я знаю, тот же vim или emacs при желании можно использовать как IDE, просто это требует более долгой настройки.
Про их (IDE) громоздкость и монструозность,
Ну, это да, что правда, то правда.
ответить
Так в любом
Так в любом нормальном IDE "гвоздями" прибит только текстовый редактор
Что, мало? Лично для меня — более чем достаточно.
Про компилятор IDE может вообще не знать.
Видимо, нужно договориться о терминах. Если IDE не знает про компилятор, то — в терминологии, к которой я привык — это не IDE.
есть vim-mode, хотя, скорее, всего, он может не дотягивать до оригинального vim-а.
Ага, может быть, оно ещё и в терминальном окне в текстовом режиме умеет работать? NB: я пробовал gvim'ом пользоваться, так что о недопустимости (для меня) редактора как отдельного оконника заявляю со всей ответственностью.
тот же vim или emacs при желании можно использовать как IDE
Мне здесь не вполне понятно, что понимается под выражением "использовать как IDE". Я, естественно, make вызываю из vim'а — кстати, в том числе и тогда, когда не программирую, а книжку пишу; команду make view, которая у меня транслирует текущий том и показывает результат, я повесил на клавиатурный shortcut. Для случая LaTeX'а это практически ничего не даёт, для случая компиляции программ — очень даже даёт, vim перехватывает stderr от make и потом можно пробежаться по тем местам исходников, на которые компилятор выдал ошибки. Вот только при чём тут IDE?
ответить
☞ From ping (unverified) Tue Oct 11 17:06:00 2011 UTC
FASM vs NASM
Только без холивара, вопрос что лучше для написания кода для биоса FASM или NASM ? один советует одно, второй советует другое.
Хочется услышать мнение как специалиста
ответить
Какой там холивар
Сказано же в явном виде (у меня в предисловии), что выбор между этими двумя ассемблерами в моём случае был сугубо случаен. Не могу я посоветовать ни тот, ни другой, и вообще я FASM только издали видел.
Гм... вообще-то я бы сказал, что лучше это делать на Си, а не на асме; жизнь коротка, знаете ли. Уж если микроконтроллеры можно программировать на Си, то полноценный комп (пусть даже имеется в виду его биос) -- тем более. На асме стоит, видимо, сделать только обёртку с точками входа, один маленький файлик. А всю функциональность лучше всё-таки на Си.
ответить
☞ From BratSinot (unverified) Wed Jun 8 17:53:00 2011 UTC
FPU
Планируется ли добавление в пособие информации о FPU? Я понимаю что в i386 он был еще в виде сопроцессора, но где-то с i486 появился в самом процессоре, а пособие же не строго по i386?
ответить
Уже есть
Во втором издании про FPU целая глава, хотя и не очень большая (см. стр. 166--181). В первом издании этой главы не было из-за, во-первых, жестких ограничений по объёму книги (в МГТУГА не умеют издавать ничего кроме брошюр) и, во-вторых, из-за того, что на лекциях в МГТУГА я этот материал всё равно не успевал прочитать. Самая первая версия моего курса, прочитанная в Ташкенте, этот материал содержала.
ответить
☞ From ASM (unverified) Sun Jun 5 17:37:00 2011 UTC
Не удается скачать кнги по nasm.
При переходе по ссылке для скачивания появляется соообщение "Страница не найдена." Книги были убраны из свободного доступа?
ответить
Исправлено
Там перемудрили с настройками drupal. Сейчас вроде всё нормально.
ответить
Благодарю!
Благодарю!
ответить
☞ From Евгений (unverified) Sat Jun 4 10:28:00 2011 UTC
Опровергать
Опровергать тут нечего: всё, что приносит деньги - гипертрофируется, раздувается до безобразия. И вы, почему-то, "предпочли не заметить", что в этом смысле я ничего не опровергаю, а поддерживаю, потому что невозможно опровергать бессмысленность использования современных компьютеров в офисах для набора документов и т.п.
Хотя на самом деле, за то, что мы с Вами имеем возможность иметь у себя на рабочем столе плоды колоссальных научных достижений за совершенно ничтожную цену, мы должны быть благодарны как раз-таки тому, что процессоры продаются "сотнями миллионов", а не "десятками тысяч штук".
Где вы нашли такой make, который не понимает -j? Когда я набирал текст предыдущего поста, в фоне была запущена компиляция gcc командой make -j 4. Это обеспечило почти непрерывную 100% загрузку всех моих четырёх ядер, и соответственное уменьшение времени компиляции, тем более, что современные процессоры знамениты не только своей многоядерностью, но и большим кэшем (причём, это всего лишь недорогой прошлогодний ноутбук). В правильно написанном программном продукте все модули делаются независимыми для компиляции и связываются только по интерфейсам, что позволяет великолепно распараллеливать процесс компиляции. Если бы на это влияли скорость обмена с ОЗУ или внешними устройствами, то 100% загрузки не было бы. А с 512-ю МБ памяти, конечно, не понять, что всё целиком, ОС, системное ПО, компиляторы, исходные и промежуточные данные, и результаты компиляции могут не выходить за рамки оперативной памяти (при достаточном её количестве). К жёсткому диску вообще при компиляции обращений нет, т.к. при распаковке архива с исходным кодом всё это кэшируется в ОЗУ, потом обрабатывается и опять кэшируется, а не сразу пишется на диск. Для не-супервычислений проблема медлительности жёстких дисков перекрывается большой оперативной памятью. А скорость компиляции gcc достигается за счёт эффективности производимого им кода - отключить оптимизацию, и компиляция будет летать. Но только жертвовать приходится чем-то одним - либо скоростью компилирующего, либо скоростью компилируемого.
Компилируют не многие, но играю почти поголовно. С видео работают уже многие, т.к. цифровые камеры - не редкость.
Кстати, в былые времена доходил до такого маразма, как написание на ассемблере под Windows, поэтому могу отметить, что это вполне реально. Загляните на www.wasm.ru. Правда, NASM там не в моде...
ответить
Вы читать-то вообще умеете или как?
make -j, разумеется, работает и всегда работал, я иного и не утверждал, тем более что реализуется это -j совершенно очевидным образом (достаточно представить себе граф зависимостей, который строит make). А утверждал я другое: если бы кого-то волновала скорость сборки ядра Linux, его можно было бы собирать через make -j (и без всяких промежуточных make deps), плюс к тому его можно было бы не пересобирать с нуля при каждом изменении конфига, а делать, как это принято в нормальных проектах, обычный make, который пересобирал бы лишь то, что нужно, и перелинковывал всю махину (последнее происходило достаточно быстро даже на 386-х). Что gcc собирается с make -j -- это я не удивлён, так и должно быть. Удивляет как раз то, насколько наплевать на скорость сборки своего детища авторам линуксовых ядер.
Далее, "не выходить за ОЗУ" -- конечно можно, и очень даже понятно, но, во-первых, для сборки того же ядра Linux, чтобы вообще не лазить к диску, потребуется тогда гигов 16 памяти (я деньги лучше пропью и потерплю раз в год, что оно собирается полчаса), а во-вторых, память находится _за_ шиной. Кроме того, построение страничных таблиц каждый раз при запуске процесса, собственно говоря, от диска никогда не зависело, оно всегда происходит "не выходя за RAM", что никак не отменяет его чудовищной ресурсоёмкости. Ergo, 64-разрядность и многоядерность процессора вам ничем не поможет. Ну, почти ничем.
Что играют поголовно - я вот тоже не играю. А из периода 286-х машин сохранил нежные воспоминания о симуляторе f-19, который нормально работал на XT с 640 Kb RAM (прописью: 640 _кило_байт) и CGA (4 цвета), а на убогой 286й летал как я даже не знаю что. Более реалистичного флайт-сима я с тех пор не видел, зато нынешние монстры на 512 Mb даже запускаться не хотят. Это замкнутый круг: железячники гонят процессоры и память, софтверщики (язык не поворачивается их программистами называть) гонят всё более и более монструозные и тормознутые приложения.
Про массовые тиражи процессоров — а я и не спорю, что это хорошо, когда массовые процессоры идут большими тиражами, что снижает их стоимость. В качестве мракобесия, подлежащего искоренению, я считаю из пальца высосанное "совершенствование" процессоров для массового потребителя, которое должно было остановиться лет семь назад (кстати, процессоры нынче стоили бы ещё дешевле, если бы это всё ещё были селероны или на худой конец P4).
Ну и последнее, про "нормальные продукты" -- вот то-то и оно, если дальше гнать процессоры, скоро нормальные продукты писать никто не будет. Не останется людей, которые это умеют. Впрочем, гнать дальше уже не получится, предел технологии по процессорам, к счастью, достигнут (многоядерность - это уже жизнь после жизни), плюс к тому несколько обнадёживает появление netbook'ов, всё-таки у кого-то хватило здравого смысла. Подозреваю, что логическим завершением всего этого мракобесия станет появление коробочки размером с пачку сигарет с дырками для монитора и USB (ненавижу USB, но вряд ли оно куда-то денется), на которой работает какой-нибудь OpenOffice, которая не ломается в принципе, за отсутствием трущихся частей, а стоит пять баксов. Надеюсь, после этого компьютерная индустрия всё-таки сдохнет.
ответить
Бесконечно
Бесконечно далеки Вы от настоящей компьютерной индустрии... Я бы тут и высказываться не стал, если бы не увидел, что к обучающим материалам, какими являются Ваши книги, прилагаются такие странные комментарии. Процессоры естественно развиваются, и что же удивительного в том, что предназначенное для решения больших вычислительных задач пытаются под любым предлогом продать как можно большей аудитории? Если бы компании, производящие процессоры и вообще ПК, не зарабатывали бы на поставке сверхбессмысленно мощных компьютеров в офисы и обычным пользователям, то ни о каком развитии технологического процесса, ни о сверхэкономичных процессорах, netbook-ах, коробочках за пять баксов - речь ещё долго не шла бы.
Меня то как раз и удивляет такое безграмотное отношение к этому вопросу, как будто все, кто создают компьютерную технику и ПО - это идиоты. И, что ещё более удивительнее, все, кто пишут ядро Linux - тоже чего-то не додумали. А вам не кажется подозрительным, что gcc позволяет параллельную компиляцию, а ядро Linux нет? Это потому что тысячи программистов туповаты, или же всё-таки в этом есть какой-то смысл? Так вот в серьёзных книжках по этому вопросу поясняют, что при компиляции самого главного, что работает на компьютере и управляет всем остальным, необходим полный контроль за последовательностью компиляции и достоверность того, что будет на выходе, чего параллельная компиляция в полном объёме не даёт.
Насмотревшись на Windows, другие продукты Microsoft, политику Intel, и развитие ширпотребных компьютеров начинает везде чудиться обман, избыточность, неэффективность, бессмыслица. Мой совет похож на Ваш (см. выше) - выбросить всё это из головы, и искать рациональность в серьёзных вещах. Linux, как и многое другое базовое свободное ПО, пишут гениальные программисты, и упрекать их в непрофессиональности и не стремлении к эффективности - это только самому позориться. А на самом деле эффективно использовать современную компьютерную технику могут только настоящие учёные.
ответить
Смешно, да
Бесконечно далеки Вы от настоящей компьютерной индустрии...
К счастью, да — далёк, причём удалился я от индустрии вполне намеренно, когда понял, на что она похожа.
Правда, очень забавно слышать подобные заявления в свой адрес от человека, который начал (и, судя по всему, на полном серьёзе) с утверждения, что-де только суперЭВМ и есть настоящая индустрия, а всё остальное — побочное производство.
Процессоры естественно развиваются
Естественное развитие процессоров для ПК закончилось около семи лет назад, с выходом P4 и его аналогов. Всё, что было после этого, никакого отношения к естественному развитию процессоров не имеет; многоядерные процессоры, как я уже говорил, представляют собой классический пример потреблядства и являются результатом маркетоидских игрищ, а не технического развития.
Если бы компании, производящие процессоры и вообще ПК, не зарабатывали бы на поставке сверхбессмысленно мощных компьютеров в офисы и обычным пользователям, то ни о каком развитии технологического процесса, ни о сверхэкономичных процессорах, netbook-ах, коробочках за пять баксов - речь ещё долго не шла бы.
Это опровергается одним примером: Cray. Компания, создававшая лучшие в мире суперкомпьютеры и ничем другим, никаким офисным потреблядством никогда не занимавшаяся. И работавшая до тех пор, пока её маркетоиды не уничтожили.
Но, на самом деле, в вашем утверждении системная ошибка гораздо глубже. Утверждение о том, что-де коммерческим компаниям нужны деньги, чтобы изменять мир к лучшему — это очень популярный миф, его можно услышать и в применении к автомобильной индустрии, и, скажем, в применении к так называемым звукозаписывающим компаниям (дескать, мы заработанные деньги используем для поиска и раскрутки молодых исполнителей, а пираты нам мешают, из-за них у нас нет денег), да и вообще везде, где есть коммерция. Люди в целом не очень любят, когда на них наживаются, поэтому коммерсанты при любой возможности пытаются создать у публики ощущение собственной полезности. В действительности коммерческая компания есть, по определению, компания, единственной целью деятельности которой является извлечение прибыли, никаких иных целей у них нет и быть не может, не потому, что они "плохие", а просто таково определение слова "коммерческий".
Чтобы проиллюстрировать действительный эффект от финансовой мощи тех, кто продаёт в офисы четырёхядерные компьютеры, я вас вот о чём спрошу. Где, простите, процессоры Alpha? И сама компания DEC? И где, простите, Sun Microsystems и её SPARC? И остальные архитектуры, не имевшие отношения к Intel? Выжил в итоге самый идиотский из всех имевшихся в наличии процессоров — причём его создатели сумели заработать достаточно денег, чтобы купить и уничтожить всех перспективных конкурентов. Это вы называете техническим прогрессом?
Я бы сказал, что очень важно понимать опасность этого вот мифа о том, что у коммерческих компаний есть какие-то полезные цели. Просто исходно мир был устроен так, что заработать деньги можно лишь принеся кому-то пользу. В области малого бизнеса это до сих пор так. В области крупного бизнеса это не так вот уже примерно полтора столетия.
Так вот в серьёзных книжках по этому вопросу поясняют, что при компиляции самого главного, что работает на компьютере и управляет всем остальным, необходим полный контроль за последовательностью компиляции и достоверность того, что будет на выходе, чего параллельная компиляция в полном объёме не даёт
Сие есть гуманитарный бред, не имеющий отношения к технике. Ядро — это такая же программа, как и любая другая, и к ней точно так же применимы принципы построения зависимостей. Если бы кого-то так сильно волновала конкретная последовательность сборки, загружаемых модулей бы уж точно не было.
Иной вопрос, что конфигурация ядра записывается в один большой файл; результатом этого становится зависимость буквально всего, что там есть, от этого одного файла и категорическая невозможность построить настоящий граф зависимостей. Можно это переделать? Можно. Но потребует серьёзных усилий. А зачем, если оно и так за четыре минуты собирается?
Linux, как и многое другое базовое свободное ПО, пишут гениальные программисты, и упрекать их в непрофессиональности и не стремлении к эффективности - это только самому позориться
Да неужели? Ну, ядро, допустим, в основном пишут действительно гениальные люди, и некоторых из них я даже лично знаю. Что никоим образом не отменяет того факта, что все программисты — люди, во-первых, ленивые, а во-вторых, всегда могут себе найти другое занятие, нежели переделывать систему сборки ядра. Наконец, в-третьих, от одних людей, имеющих прямое отношение к ядру Линукса, я слышал весьма нелестные отзывы о других людях, имеющих отношение туда же, как и обо всём проекте в целом (в частности, про ядро 2.6 при его появлении я слышал буквально следующее: всё это всё меньше похоже на Unix и всё больше похоже на Win NT).
Что касается другого программного обеспечения — знаете такую программу /bin/true? Ну вот запустите её под strace'ом и посчитайте, сколько она делает системных вызовов. Я тут 103 насчитал. Мораль: основная юзерспейсовская библиотека — та самая GNU libc — сейчас представляет собой монстра, негодного к использованию, но которым продолжают пользоваться, потому что всем всё пофигу. То есть если ещё про "ядерщиков" и их гениальность я соглашусь, то команда Столлмана моё уважение потеряла давно и прочно. Ну то есть самого RMS я безмерно уважаю как политика и пропагандиста, но как программиста-профессионала — увы (в особенности после его ответа на мой вопрос об отношении к C99; в шоке был не только я, но и половина аудитории).
Где-то мне статья попадалась на эту тему (не смог сейчас найти, к сожалению), там автор сделал весьма поверхностный code quality review нескольких известных проектов, которыми миллионы людей пользуются, и сделал весьма неутешительные выводы. Что-то вроде "вы думали, серьёзные программы пишут боги? увы, это такие же люди, как и вы, причём часто гораздо хуже вас подготовленные; причём это ещё open source, а что творится внутри проприетарных проектов, остаётся только догадываться".
upd Вот, набрёл-таки снова на этот текст: http://corte.si/posts/code/reading-code.html Рекомендую весьма :) очень полезно для избавления от розовых очков.
А на самом деле эффективно использовать современную компьютерную технику могут только настоящие учёные.
Современную компьютерную технику эффективно использовать не может никто, потому что это невозможно. А эти ваши настоящие учёные (во всяком случае, в России) поголовно винду гоняют, какое там к дьяволу эффективное использование.
ответить
задачи
И всё же есть некоторые задачи у «простых смертных», требующие более-менее высокой скорости компьютера. Это и обработка видео (не просмотр, а именно обработка в редакторе), и аудио — а сегодня всё больше музыкантов сводят свою музыку на домашнем компьютере, дабы не кормить жирных продюсеров. Даже обработка фотографий в большом разрешении может потребовать немалых ресурсов — как вычислительных, так и оперативной памяти.
В остальном Вы, конечно же, правы — для повседневных задач четырехъядерный процессор и >=4 гигабайт ОЗУ ну нафиг не сдались.
ответить
10 лет спустя. Привет из 2021
> Ну вот запустите её под strace'ом и посчитайте, сколько она делает системных вызовов. Я тут 103 насчитал.
Прогресс? Если что, у меня GNU/Linux x86_64, ядро, глыба-ц и всё прочее самой новой версии.
> Мораль: основная юзерспейсовская библиотека — та самая GNU libc — сейчас представляет собой монстра, негодного к использованию,
Сейчас моду набирает musl. uClibc всегда было не очень, а сейчас и вовсем мертво. Но почему-то "большие" дистрибутивы традиционно всё-таки на гнутой сидят. А musl всё больше на мини-дистрах, где и остальное гнутое заменено на busybox / toybox
ответить
Про musl я в
Про musl я в курсе, читаю их список рассылки. Сам на неё перейти не могу из-за принципиального отсутствия поддержки не-юникодных кодировок: сам я сижу на koi8r и категорически не собираюсь её ни на что менять.
Думал даже сделать форк musl'а, но это вряд ли — не потяну, нет ни времени, ни сил.
ответить
Про ядра
Я думаю, что отсутствие параллельной сборки для ядра Linux - традиция/лень к переделке. Потому что ядро FreeBSD - собирается параллельно.
ответить
☞ From Саид (unverified) Wed Jun 1 15:05:00 2011 UTC
Про осваивание LInux для девелопинга
Здравствуйте, господин Столяров. Рекомендуете ли Вы основательное осваивание системы Linux ВМЕСТО Windows для будущего программиста, и насколько полезно изучение конкретной реализации языка ассемблера для Linux - NASM в курсе общего изучения самого языка?
ответить
Разумеется :)
Я рекомендую забыть Windows вместе со всеми её вирусами и прочими прелестями как страшный сон, навсегда, и рекомендую это не только программистам. Я вообще не понимаю, как можно всерьёз говорить об использовании системы, в которой бывают вирусы.
Что касается конкретно NASM, то, во-первых, у вас очевидный бардак в голове: какого это "самого языка"? Язык ассемблера — это всегда именно язык конкретного ассемблера, а не чего-то ещё, сколько есть ассемблеров, столько есть и их языков, никакого "самого языка" здесь нет и быть не может. Во-вторых, причины выбора именно NASM подробно изложены в предисловии к моей книжке, повторяться смысла не вижу. А в-третьих, NASM — это ассемблер для x86-х процессоров, а не "для Linux". NASM есть и под виндой, разумеется, ведь сам NASM — это программа на ANSI C, переносимая со страшной силой. Вот только писать под винду (в смысле, оконные приложения) на ассемблере нереально, особенно в рамках учебных задач.
ответить
NASM, С99 и изучение ассемблера
>NASM — это программа на ANSI C
Уже нет http://repo.or.cz/w/nasm.git/blob_plain/HEAD:/INSTALL
We recommend MinGW over Visual C++ 2005 as we have found it to be more up to date with regards to C99 compliance, and we are increasingly using C99 features in NASM.
>переносимая со страшной силой.
А вот тут вы правы. Под DOS он отлично скомпилировался open watcom компилятором.
>Вот только писать под винду (в смысле, оконные приложения) на ассемблере нереально, особенно в рамках учебных задач.
Совершенно с вами согласен. Кстати, можете посмотреть доклад по теме использования GNU/Linux в качестве платформы для изучения ассемблера http://esyr.org/video/pereslavl.2010/kostjuk.ogv
И лабораторные работы https://github.com/fiowro/asm
Но я считаю, что правильнее обучать ассемблеру GNU т.к. он поддерживает не только интел/амд архитектуры (которые, вполне возможно, отправятся на покой лет через 5-10). Макросредства обычно плохо переносимы между различными ассеблерами. Кроме того, уже есть книга по ассемблеру GNU под лицензией GNU Free Documentation License https://savannah.nongnu.org/projects/pgubook/ надо только ее перевести
ответить
Про gas
GNU assembler не катит по двум причинам. Первая — синтаксис AT&T (почему интеловский предпочтительнее при выборе учебного пособия, я написал в предисловии). А вторая — и главная — на GNU asm'е невозможно писать. Он и не предназначен, чтобы на нём писали. Его основная и единственная задача — быть связующим звеном между компиляторами высокого уровня и объектным кодом. И вообще, что значит «правильнее обучать»? Правильнее с какой точки зрения? Целью обучения программированию на асме, как ни странно, не может быть само по себе программирование на асме, это навык (если его рассматривать с профессионально-коммерческой точки зрения) абсолютно бессмысленный. Никто никогда не пишет на асме. Но при этом опыт такого писания жизненно необходим, чтобы примерно представлять себе, что на самом деле происходит при выполнении программы. И с этой колокольни, вообще говоря, пофигу, какой ассемблер и под какой процессор изучать. Ну, допустим, процессор всё-таки желательно использовать живой и реально существующий, чтобы не оставалось ощущения, что «с настоящим точно не получится», но и только.
Впрочем, переводите что хотите :) (нет, я ничего переводить не буду, сам я и по-английски неплохо читаю, чего и всем желаю).
ответить
А как быть с другими архитектурами?
Ну допустим что NASM подходит для программирования под x86-совместимые процессоры, является более привычным итд итп. Но как быть с другими архитектурами, те же ARM, AVR, SPARC?
ответить
вопрос, извините, идиотичен
Что значит "как быть"? Ассемблер есть, по определению, программа, переводящая мнемонические обозначения машинных команд в собственно машинные команды. Если машинные команды принципиально другие (а они, разумеется, совершенно другие на каждой из перечисленных архитектур), то и ассемблер, естественно, придётся взять другой.
Впрочем, если говорить о практическом программировании, то ассемблер вообще брать не надо, лучше писать на Си (жизнь, в сотый раз повторяю, коротка). А если припрёт писать именно на языке ассемблера, то, имея опыт работы на одном ассемблере, любой другой можно освоить за пару часов. Главное — «поймать» логику системы команд. Ну и, естественно, понимать, что делаете — под те же AVRы программирование сильно отличается от привычного, даже если пишем на Си, всё-таки нефоннеймановская архитектура, это раз, и операционки нет, это два.
ответить
☞ From Anonymous (unverified) Wed May 11 13:50:00 2011 UTC
А х64 редакция будет?
А х64 редакция будет?
Ведь не секрет, что х64 версии дистрибутивов оказываются быстрее своих х86 версии и не в последнюю очередь из-за того что последние выпускаются с разной совместимостью (i386/i486 и т.д.) что существенно сказывается, так как не используются все современные инструкции процессоров.
В х64 в этом плане проще, так как набор инструкций появился относительно недавно.
Спасибо за внимание и книгу, ознакомлюсь.
ответить
Вряд ли
Имеющаяся книга появилась как обобщение опыта, полученного в ходе чтения соответствующего курса. Сам курс появился в результате моего категорического нежелания вспоминать, как всё это делается под MSDOS в 16-битной системе команд. В Ташкенте курс был прочитан один раз и больше, видимо, читаться не будет никогда; из МГТУГА я тоже потихоньку ухожу, так что там этот курс (во всяком случае, в моём исполнении) более тоже не имеет шансов быть прочитанным. И уж совсем невероятным кажется мне такое стечение обстоятельств, при котором мне захочется подготовить новый курс практически с нуля -- при том, что для себя я давно уже провёл чёткую черту между прогрессом и потребл$$ством, и 64-битные архитектуры однозначно отношу к этой вот второй категории, как и многоядерности и прочую "мощную" лабуду. Самая мощная машина у меня дома представляет собой Celeron 1.7 с 512 Mb RAM и я не вижу никакого резона для её замены. Вообще, мировую компьютерную промышленность стоило бы законсервировать лет на десять, до тех пор, пока существующие компьютеры не начнут рассыпаться от старости -- именно рассыпаться, а не "морально устаревать". Это, впрочем, касается не только компьютеров, с автомобилями ситуация точно такая же.
А чтобы линукс не тормозил, выкиньте гном и кде. В помойку, где этим жирным уродцам самое место.
ответить
Слишком мощные компьютеры, говорите?
А о больших задачах, для которых и несколько тысяч ядер - это мало, о таких вы не слыхали? А ведь вся компьютерная техника для таких задач и создаётся. А домашние компьютеры - это уже побочное производство. Обычный узел суперЭВМ сегодня - это материнская плата с четырьмя двенадцатиядерными процессорами и RAM по два гигабайта на ядро (!). И это только один узел.
ответить
Слыхал-слыхал
Мне ваше утверждение о "побочности" домашних компьютеров напоминает старое советское "зато мы делаем ракеты". Это когда всякие "великие стратеги" предпочитают мыслить "великими задачами" масштаба не менее чем БАМ или там разворот северных рек, а об окружающей реальности (типа, скажем, колбасы в магазинах) подумать считают ниже своего достоинства. С таким же успехом можно заявить, что карьерные самосвалы массой не менее 250 тонн — это и есть настоящие автомобили, а всякие там легковые и грузовые машины, а равно и автобусы — это всё побочное производство.
По поводу задач — я и не о таких задачах слыхал, смею вас заверить. А ещё я слыхал (и даже не то что слыхал, а точно знаю), что у нас на ВМК сейчас монтируют зачем-то уже третий суперкомпьютер, при том что первые два ничем полезным не заняты — нечем их занимать. Но дело даже не в этом. Даже если бы эти конкретные машины было чем занять, доля суперЭВМ среди всех имеющихся в мире машин составляет не то что не проценты, даже не тысячные доли процентов, причём даже если считать не машины, а процессоры. Это мизер, не заслуживающий внимания. И доля расчётных задач, требующих серьёзной мощности -- это ничтожная, пренебрежимо малая часть задач, решаемых с помощью компьютеров. А для подавляющего большинства задач, которые решаются на машинах, мощность процессора не нужна совсем, то есть вообще, то есть никак — потому что это интерактивные задачи, ведущие диалог с пользователем. И чтобы процессор не успевал за пользователем, нужно либо чтобы этот процессор был на паровом ходу или там с педальным приводом, либо чтобы программист, который написал программу, был полным идиотом (последнее, к сожалению, встречается очень часто — вот те же браузеры тому пример).
Так или иначе, именно домашние и офисные машины, ну и примкнувшие к ним серверные решения, которым мощность тоже нафиг не нужна, поскольку они упираются не в процессор, а в скорость сети, диска и объём памяти — это и есть основа компьютерной индустрии, а суперЭВМ, производимые в единичных экземплярах, никакой погоды не сделают. Если мощные процессоры нужны для суперЭВМ, то пусть их для суперЭВМ и производят — партиями по несколько тысяч штук, а не по несколько десятков миллионов. Ну, это если бы мир был идеален.
Но поскольку мир не идеален, производители домашних и офисных компьютеров очень хотят продолжать кушать бутерброды с икрой, а для этого им необходимо продавать компьютеров не меньше, чем раньше, а, напротив, всё больше и больше. Для этого есть два способа. Первый — сделать так, чтобы компьютеры быстро ломались. Способ старый и проверенный, но у него есть недостаток — трудно сделать так, чтобы компьютер отработал свои три года, а потом рассыпался. Если сделать его совсем на соплях, то половина компьютеров сдохнет во время гарантии, и тут уже проблемы обеспечены. Соответственно, используют второй способ: сделать так, чтобы компьютеры подвергались "моральному устареванию". Пока работал закон Мура, это получалось само собой. Но вот когда производители процессоров лет семь назад упёрлись в предел тактовой частоты и закон Мура неожиданно для всех захлебнулся, менеджменту железячных компаний пришлось срочно что-то изобретать для сохранения своего места в мире. Инженеры сказали "мы не можем сделать процессор вдвое мощнее", на что манагеры им объяснили, что если они не сделают процессор вдвое мощнее, то будут кушать баланду. Поскольку баланда — аргумент убедительный, инженеры почесали репу и придумали некий протез — два ядра на одном камне, потом четыре, потом восемь... А программисты проприетарных компаний им в этом помогли, создавая год от года всё более и более тормознутый софт и создавая тем самым у конечного потребителя ложное ощущение необходимости перманентного апгрейда. Вот это я и называю потреблядством — не когда удовлетворяются имеющиеся потребности, а когда искусственно создаётся ощущение потребности там, где никакой потребности и рядом не лежало.
Итог всего этого мракобесия в том, что 99,9999% всех процессоров в мире простаивает (ничего не делает) в течение 99,9999% времени, но при этом на изготовление этих процессоров тратится немерянное количество ресурсов, потом на их питание на холостом ходу тратится прорва электричества, и оплата всего этого влетает конечным пользователям в несуразно гигантское количество денег.
Увидел маркетоида — убей его.
ответить
Наука и бизнес
А на чём сегодня держится почти любая естественная наука? На реальных экспериментах? Это уже дела давно минувших дней. Ни одна современная производственная и научная задача не обходится без численного моделирования. Погоды, говорите, не делают... Ну, ну... А как появляется техника, к которой мы привыкли, от сотовых телефонов до автомобилей и зданий? На персональном компьютере чертежи рисуют? Всё это моделируют, и для работы в таких сферах в реальном режиме, в режиме рынка, необходимы огромные вычислительные мощности. И никакие ПК, и даже никакое их количество, не смогут заменить современные супер-ЭВМ на производстве. О том как у нас всё простаивает я по-лучше вашего знаю (у нас и не такие машины занимаются не пойми чем), но это свидетельствует только о том, что у нас мозгов не хватает для того, чтобы это эффективно использовать, но уж никак не о том, что это всё не нужно. И то, что в этой области мы как обычно протормаживаем - это наши проблемы (людей), а не прогресса вычислительной техники. То, что у нас обычно всё бестолково используется, это и так понятно, но о бессмысленности роста вычислительной мощности вообще, в принципе - Вы лучше никому не говорите, люди, связанные с реальной наукой, над Вами смеяться будут. Рассуждения, приведённые выше, свидетельствуют о том, что вокруг Вас одни ПК, и с реально большими задачами Вы не сталкивались. Уровень развитости производства напрямую зависит от вычислительных мощностей, доступных инженерам. Да и безопасность страны уже измеряется в терафлопсах и петафлопсах, т.к. ядерное оружие невозможно испытывать, его можно только моделировать.
Для персональных компьютеров, естественно, уже давным давно, во всяком случае в офисах, не имеет никакого смысла весь современный прогресс. Но для тех, например, кто играет в реалистичные игры, производительности процессоров и видео-карт всегда не хватало. Я вот вообще не играю, но компилирую, например, ядро Linux. И как-то удобнее, когда на 4-ядерном процессоре оно компилируется несколько минут, а не несколько дней, особенно если к этому ещё кучу чего компилировать нужно. Вычислительные мощности ощущаются и обычным пользователем в виде моментальности тех действий, которые раньше нужно было ждать, пока выполнятся, и в итоге - в большей комфортности и свободе при работе на компьютере.
А в смысле стоимости и производительности, персональные компьютеры - действительно ничтожная часть по отношению ко всем мировым вычислительным ресурсам. А на маркетоидов не смотрите - если на них обращать внимание - никаких нервов не хватит. Общество потребления выгодно, и его пытаются сделать любыми способами - не получится с компьютерами, будут что-нибудь другое рекламировать.
Когда Вы сажаете рассаду в огороде, вам достаточно лопаты, и уму не постижимым кажется, зачем только делают экскаваторы: столько металла тратят, столько соляры жрёт, и используют его для какого-нибудь ландшафтного дизайна без толку. Но когда Вам нужно будет вырыть котлован для собственного дома - тогда и оцените, насколько это грандиозный инструмент.
ответить
Прямо как в том анекдоте
Получается в точности как там — "дядь, а ты с кем сейчас говорил?"
Мне, честно говоря, немного непонятно, зачем столь страстно убеждать меня, что суперкомпьютеры нужны и важны. Я, собственно, не предлагал прекратить производство суперкомпьютеров — если их кто-то покупает, пусть их производят. Я бы только, например, учредил практику проверки обоснованности расходов: если где-то поставили суперЭВМ, а она не задействована, то имеет место очевидная растрата, причём вне зависимости от того, о коммерческой компании идёт речь или о бюджетной. В первом случае впустую растрачены деньги акционеров компании, во втором растрачены деньги налогоплательщиков, но в обоих случаях есть тот, кто получил откат, и этого кого-то стоит, очевидно, посадить известно куда. Ну да это, впрочем, лирика, не имеющая отношения к исходному вопросу. А исходный вопрос тут вот какой. Допустим, я полностью соглашусь с вами по части нужности и полезности суперкомпьютеров (я не собираюсь, на самом деле, с этим соглашаться, но допустим). И как, пардон, из этого следует, что 64-битный 4-ядерный процессор на десктопе у секретарши, которая кроме ворда и пасьянса ничего никогда не запускает, являет собой что-то отличное от потреблядства?
Кстати, ядро линукса и я компилирую, и мне как-то совсем непонятно, откуда вы взяли "несколько дней". На моём дохлом селероне 2.6'е ядра собираются меньше получаса, да и вообще, при чём тут процессор? Львиная доля времени (я бы даже сказал, чуть менее чем всё) при этом тратится на старт и останов gcc, сегмент кода при этом не перезагружается, конечно, но у gcc и сегмент данных нехилый, а самое страшное при создании процесса — это генерация страничных таблиц (а это каждый раз с нуля и без вариантов); и процессор тут вообще ни разу ни на что не влияет, а влияет скорость шины (хрена с два вы её увеличите, скорость света помешает) и скорость обмена с диском (тоже хрена с два что тут можно ждать, упёрлись давно в физические ограничения). Впрочем, ядра бы и быстрее собирались, если бы у тех, кто их пишет (а заодно и у авторов gcc), на столе что-нибудь помедленнее стояло, а то привыкли об эффективности не думать, вот и имеем то что имеем (например, ну они хоть бы make -j работать заставили нормально, а то как не работало, так и не работает, несмотря на то, что в ядре до чёрта совершенно не зависящих друг от друга подсистем). Но вообще-то пересборка ядра операционки — это не та задача, которую часто приходится решать конечному пользователю, да и не только конечному.
Если мне экскаватор потребуется, я вряд ли его покупать стану, и тем более не стану сокрушаться, что мой автомобиль не оснащён соответствующими функциями. Да он мне если и понадобится, то разве что раз за всю жизнь. Уж как-нибудь я с этим одним разом справлюсь. А в повседневной жизни мне нужен автомобиль — не экскаватор и не карьерный самосвал, и даже не болид формулы-1, а обычный автомобиль, чтобы возить мою задницу и мой чемодан. При этом я никоим образом не отрицаю полезности и нужности карьерных самосвалов и экскаваторов, пока их разработка не влияет на свойства моего авто.
Короче говоря, не надо мне рассказывать про полезность суперкомпьютеров. Лучше попытайтесь опровергнуть моё утверждение, которое вы предпочли не заметить: если быстрые процессоры нужны для суперЭВМ, то пусть их и производят для суперЭВМ, и ровно в тех количествах, в которых они нужны на суперЭВМ — то есть десятками тысяч штук, а не сотнями миллионов.
Кстати (припоминая свои знания из области параллельных вычислений и численных методов), процессор общего назначения в роли узла суперкомпьютера — это вообще-то нелепость, не?
ответить
Добавил
Добавил отдельным комментарием, а про этот вопрос забыл...
Отвечаю. Естественно, нелепость. Но это можно только теоретически утверждать, а реально, когда строится огромная машина, берут массово производимые и, соответственно, относительно дешёвые (относитено не-массовых), но самые высокопроизводительные процессоры. К тому же, всё ПО поменять под другую архитектуру не представляется возможным.
Но сейчас, как только появилась возможность, начитают отходить от бестолкового использования кристалла процессора, и всё больше используют процессоры SIMD или полу-SIMD архитектуры, в частности, графические процессоры. Самые мощные суперЭВМ уже большей частью своей производительности обязаны процессорам НЕ общего назначения. Но эффективно использовать эту архитектуру намного сложнее.
ответить
Ага
Ну тогда внесём поправочку в моё исходное утверждение. Всю мировую компьютерную индустрию, за исключением, возможно, производства суперкомпьютеров, следует заморозить лет на десять, до тех пор, пока существующие компьютеры не начнут рассыпаться от старости. В такой формулировке согласны? :) Впрочем, оставляю за собой право продолжать считать оправданными ревизионные проверки любой организации, которая купила суперкомпьютер. Ибо нефиг.ответить
Говоря простым
Говоря простым языком, это означает, что часть стоимости этих самых суперкомпьютеров банально перекладывают на массового потребителя, впаривая ему завышенные от реальных потребностей вычислительные мощности путем принуждения через массовый софт с искусственно раздутым ресурсопотреблением. Почему же потребитель пользуется этим софтом? Его опять же вынуждают к этому, но уже через форматы различного контента. Если вам постоянно приходит документация, чертежи и т.п. материалы от смежников, заказчиков и т.д. - вам зачастую будет проще приобрести новую версию софта, чем постоянно выбивать из людей копии в старом формате, которые они неизменно будут забывать присылать, заставляя терять вас время и, как следствие, потом работать в авральном режиме. Нет, можно воспользоваться и официальными трансляторами - только, если что-то у вас откроется не так - это уже ваши проблемы.
В итоге имеем тормозящий на все более мощных компьютерах софт, в котором все баги, глюки и нелепости тщательно приберегаются для исправления в последующих версиях, которые нужно покупать отдельно. А с другой стороны - в суперкомпьютерах используются не вполне адекватные задачам процессоры, поскольку: "когда строится огромная машина, берут массово производимые и, соответственно, относительно дешёвые (относитено не-массовых), но самые высокопроизводительные процессоры". А, ну да, для полного счастья на суперкомпьютерах используется всё то же неадекватное по ресурсоемкости ПО, т.к. "всё ПО поменять... не представляется возможным".
Я вас правильно понимаю?
ответить
Ещё привет через десять лет
Насколько я понимаю, процессоры за это время уже развивались в основном в сторону энергоэффективности при сохранении почти той же производительности — или я не прав?
У меня современных процессоров нет, уж очень отвращает от себя фигня под названием Intel ME / AMD PSP, которая представляет из себя отдельную ОС, имеющую большие полномочия, по сравнению с основной.
Проприетарный BIOS, в принципе, мне пофиг был бы сам по себе, если бы он после передачи управления ядру ОС, больше ничего не мог делать. Мне кажется, излишний пуризм в этом вопросе контрпродуктивен.
Но когда эта дрянь может лезть в сеть сама по себе — ну её нафиг. Не знаю даже что буду делать, когда мои компы, купленные 10 лет назад начнут рассыпаться.
ответить
☞ From Anonymous (unverified) Mon May 9 12:01:00 2011 UTC
Nasm и библиотека Си
Здравствуйте!
Я попытался вызвать функцию printf из библиотеки Си, но програмку убиват ОС с сигналом SIGILL. Но когда я слинковал через gcc, то всё заработало. (т.е. надпись "Hello, world!" благополучна вышла). Не подскажете как правильно линковать через ld.
Я делал так:
# ld -o hello -shared /lib/libc.so.6 hello.o
# ./hello
Недопустимая инструкция
Через gcc так:
# gcc hello.o
# ./a.out
Hello, world!
#
ответить
Узнать, что там
Узнать, что там конкретно делает gcc, вы можете очень легко - дайте ему флажок -v, он вам сам расскажет. Но вообще идея делать динамически слинкованную бинарь из ассемблерной программы кажется мне по меньшей мере странной - нафига тогда вообще на ассемблере писать.
ответить
☞ From Anonymous (unverified) Mon Mar 21 18:13:00 2011 UTC
Приветствую.
Приветствую. Спасибо за книги, но вот в чем проблема, они не адаптированны по 64 битные версии ОС.
fylh@calculate ~/Сталец/labs/jap $ nasm -f elf lab1.asm
fylh@calculate ~/Сталец/labs/jap $ ls
3.asm asm lab1.asm lab1.o lab2 stud_io.inc
fylh@calculate ~/Сталец/labs/jap $ ld lab1.o -o lab1
ld: i386 architecture of input file `lab1.o' is incompatible with i386:x86-64 output
fylh@calculate ~/Сталец/labs/jap $
ответить
64-битное окружение
Попробуйте сказать линкеру -m elf_i386, то есть вот так:
ld -m elf_i386 lab1.o -o lab1
У меня сейчас под рукой нет 64-битной системы, так что проверить этот вариант я не могу. Если не сложно, сообщите о результатах. Если не сработает, скажите ld -V и киньте сюда результат. Спасибо.
ответить
fylh@kubuntu-2011-03:~/Ста
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ nasm -f elf lab1.asm
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ld -m elf_i386 lab1.o -o lab1
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ls
3.asm asm lab1 lab1.asm lab1.o lab2 lab.o stud_io.inc
fylh@kubuntu-2011-03:~/Сталец/labs/jap$ ./lab1
Hello, world!
fylh@kubuntu-2011-03:~/Сталец/labs/jap$
ответить
Спасибо!
Большое спасибо за отчёт, одной проблемой меньше. Обращаю ваше внимание на второе издание -- вполне возможно, вас заинтересуют появившиеся в нём дополнения.
ответить