LINUX.ORG.RU
ФорумTalks

Первые UNIX и современные ОС: общее и различие


1

2

Ну во-первых, такая вот интересная ссылка:
http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html

Маны к одной из первых версий юникс, датированные 1971 годом, то есть, около 40 лет назад.

Интересно, что тогда восьмеричные права доступа уже были, но было всего две цифры: rw владельца, rw не-владельца, исполнимость, suid. Вместо /etc/passwd и /etc/shadow были файлы /etc/uids который содержал только имя и uid, и собственно /etc/passwd который содержал пароли в открытом виде.

Перезагрузка машины осуществлялась командой /etc/boot и спрятана она в /etc она была что бы её случайно не запустили.

Команда cmp действовала практически так же, как в современных GNU/Linux. df и du имели даже такие же ключи, хоть и в меньшем количестве

Уже тогда был dc, правда не поддерживавший циклов, так что его нельзя назвать тьюринг-полным.

Вместо rm -i была специальная команда dsw которая показывала имена файлов и можно было выбрать, удалить их или оставить

Уже тогда была команда mount которая монтировала директорию и umount, которая, как можно догадаться, размонтировала. Правда umount понимал только формат umount /dev/... и у этих команд вообще не было опций

ln уже тогда была и позволяла делать только жесткие ссылки. И уже тогда был запрет на жесткие ссылки на директорию.

Кстати, не могу не дать ссылку вот на это: http://www.nordier.com/v7x86/download.html Хоть это и UNIX v7, но всё-таки там много общего с более старыми юниксами

★★★★★

Последнее исправление: Xenius (всего исправлений: 1)

Ответ на: комментарий от tailgunner

Не растекайся. Linux некорректно называть наследником Plan9 только потому, что где-то в ней сбоку прикрутили полторы идеи из Plan9. В них вся архитектура системы принципилаьно по-разному устроена. Линукс идейно остаётся тем самым классическим Unix, который совсем не План.

У Plan9 нет наследников. (Если не считать такие же академические проектов типа Инферно.)

geekless ★★
()
Ответ на: комментарий от geekless

> Linux некорректно называть наследником Plan9

Процитирую себя:

tailgunner> если среди ОС сейчас и есть наследник Plan9, то это Linux.

Чувствуешь разницу с тем, что ты понял?

только потому, что где-то в ней сбоку прикрутили

Ооо, сколько высокомерия. Namespace'ы прикручивали под руководством Al Viro, ты его не знаешь?

полторы идеи из Plan9.

А что, в Plan9 было больше, чем 2 идеи (9P и собственно namespace'ы)?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> > только потому, что где-то в ней сбоку прикрутили

Ооо, сколько высокомерия. Namespace'ы прикручивали под руководством Al Viro, ты его не знаешь?

Кончай глючить. Namespace'ы прикручены именно сбоку, т.к. во всей архитектуре системы они как собаке пятая нога.

> полторы идеи из Plan9.

А что, в Plan9 было больше, чем 2 идеи (9P и собственно namespace'ы)?

Из системообразующих, пожалуй, только две.

geekless ★★
()
Ответ на: комментарий от geekless

>>> только потому, что где-то в ней сбоку прикрутили

Ооо, сколько высокомерия. Namespace'ы прикручивали под руководством Al Viro, ты его не знаешь?

Кончай глючить. Namespace'ы прикручены именно сбоку

Насколько я знаю, namespace'ы - базовая часть логики современной Linux VFS. Если у тебя есть что конкрентно сказать насчет «сбоку», говори. Пока что от тебя нет ничего, кроме «кончай глючить».

во всей архитектуре системы они как собаке пятая нога.

К.О. хочет напомнить, что Linux - это не Plan9, и его софт не разрабатывался для использования namespace'ов. Но они есть уже несколько лет, и ожидают только любителей Plan9. Да, и 9P тоже есть.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Чушь. Столлман начал работать, когда свободного Unix просто не было

Как раз наоборот. До GNU Юникс был бесплатный и поставлялся с исходниками. А когда халява закончилась, началалась ломка и начали писать GNU.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

>> Чушь. Столлман начал работать, когда свободного Unix просто не было

Как раз наоборот. До GNU Юникс был бесплатный

Бесплатный - да, свободный - нет.

и поставлялся с исходниками.

Для получения исходников AT&T требовалась Unix Source License, исходники коммерческих Unix вполне могли быть закрыты. О каком именно Unix говоришь ты?

А когда халява закончилась, началалась ломка и начали писать GNU.

Совсем недавно ты утверждал вот это:

Nxx> Линус и Столман писали свой код уже когда опенсорсный ВSD получил распространение.

Ты сказал чушь. Во-первых, когда Столлман начал проект GNU, опенсорсного BSD просто не было («The BSD tapes contained AT&T source code and thus required a UNIX source license»); во-вторых, когда Линус начал писать Linux, опенсорсный BSD никакого распространения не получил, а будущее всех производных от BSD систем было под большим вопросом.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Бесплатный - да, свободный - нет.

Бесплатный с возможностью его модифицировать и исходниками.

Короче, его использовали все кому не лень, поскольку лицензии на другие ОС стоилии по тем временам миллионы.

UNIX быстро стала ОС для бедных, но в критических приложениях ее старались не использовать.

Nxx ★★★★★
()
Ответ на: комментарий от tailgunner

Особенно UNIX любили университеты, опять же, благодаря бесплатности.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

Всё это не относится к тому, почему начали работать Столлман и Линус, и к тому, когда возникла опенсорсная BSD и почему она не получила распространения.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Академическая красота - это построение системы на одной очень небольшом числе концепций, единообразно использемых для решения всех задач системы. Например, передача сообщений в Mach, работа с файлами в Plan9.

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

А что ты называешь «костылями»?

То, что ими традиционно называют - решения, прикрученные сбоку. Чем больше соотношение таких решений и нормальных решений в архитектуре системы, либо при ее использовании, тем она костыльнее.

Я у тебя видел «голубые мечты о повышении качества софта».

Ты пропустил слово «мейнстримного». На мейнстримный софт надеяться бесполезно, это ясно.

Готовой реализации нет, AFAIK. Самому написать - никаких принципиальных сложностей.

Lolwut? Ты воспринимаешь мои слова буквально? Я не хочу работать из командной строки с юниксовыми ioctl'ами, я хочу управлять из командной строки устройствами. Т.е. если драйвер предоставляет какой-то интерфейс - чтоб я его взял и использовал.

Да, согласен, нет принципиальных сложностей написать утилиту в 20 строк, вызывающую произвольный ioctl для произвольного файла, на входе принимающую числовой код, и как только я сам не догадался, спасибо. Но даже если бы я и согласился использовать числовые коды вместо нормальных читаемых имен, - воспрос: кто будет все эти коды документировать?

grusha
()
Ответ на: комментарий от tailgunner

> А что, в Plan9 было больше, чем 2 идеи (9P и собственно namespace'ы)?

Много чего. Например, масса применений этих самых неймспейсов. Рекомендую ознакомиться с предметом.

tailgunner ***** (05.05.2010 18:49:03)

> Лично я сел и стал разбираться какой для МОИХ задач будет профит

Жизни не хватит на это. Если нет шансов встретить ОС в практике, изучать можно базовые идеи, лежащие в ее основе, но не более. Базовые идеи Plan9 я изучил лет 10 назад :)

А соль-то в деталях. И за 10 лет таки - в деталях - многое изменилось.

grusha
()
Ответ на: комментарий от grusha

>> А что ты называешь «костылями»?

То, что ими традиционно называют - решения, прикрученные сбоку.

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

Lolwut? Ты воспринимаешь мои слова буквально?

А я что, должен читать твои мысли?

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

Гы, сына, лол. Вместо мечтаний о повышении качества мэйнстримного софта, займись самообразованием.

кто будет все эти коды документировать?

Ага, в Plan9 документация пишется сама собой.

А что, в Plan9 было больше, чем 2 идеи (9P и собственно namespace'ы)?

Много чего. Например, масса применений этих самых неймспейсов.

И? В Linux есть namespace'ы, что тебе, лично тебе, мешает их применять?

соль-то в деталях.

В деталях нет соли, в них дьявол. Как раз дьяволы, живущие в деталях, и похоронили Plan9.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Хватит лить воду. Давай список решений, и почему ты считаешь их «прикрученными сбоку».

Далеко ходить не надо. POSIX Threads - угребищный вендообразный интерфейс, сделанный от непонимания, зачем нужен fork. Смехотворная адаптация интерфейса телетайпов под растровые дисплеи. Всяческие сокеты, ioctl, fcntl и т.д. - ad-hoc в чистом виде.

Гы, сына, лол. Вместо мечтаний о повышении качества мэйнстримного софта, займись самообразованием.

Ну-ка, поподробнее. Просвети, чего я не знаю о таком глубоком и фундаментальном изобретении человечества как ioctl?

Ага, в Plan9 документация пишется сама собой.

Не сама, но таки пишется. Есть типа культура документирования.

Много чего. Например, масса применений этих самых неймспейсов.

И? В Linux есть namespace'ы, что тебе, лично тебе, мешает их применять?

Под применениями я имел ввиду конкретный софт. Написанный и работающий под Plan 9.

В деталях нет соли, в них дьявол.

Как ты можешь «изучить» идеи Plan 9, не ознакомившись с применениями этих идей?

Как раз дьяволы, живущие в деталях, и похоронили Plan9.

Никто его не хоронил. Он и не был никогда в мейнстриме. Почему не был - да потому что некому было его пропихивать, это же очевидно. Технические вопросы тут вторичны.

grusha
()

Вопрос не в названии ОС, не в ее взаимодействии с пользователем, и даже не в самих пользователях. Дайте мне денег. И любая ОС с станет доминирующей.

TGZ ★★★★
()
Ответ на: комментарий от grusha

> POSIX Threads - угребищный вендообразный интерфейс, сделанный от непонимания, зачем нужен fork.

Займись уже самообразованием. Начни с man rfork. Может, поймешь, чем нити отличаются от процессов. Потом выясни, что именно означает «P» в POSIX.

Смехотворная адаптация интерфейса телетайпов под растровые дисплеи.

Это о чем?

Всяческие сокеты, ioctl, fcntl и т.д. - ad-hoc в чистом виде.

fcntl, ioctl, и сокеты - это всего 3 костыля (кстати, сделаны задолго до появления Plan9). Что подразумевается под «и.т.д.»?

Просвети, чего я не знаю о таком глубоком и фундаментальном изобретении человечества как ioctl?

Ты даже не понял, о чем речь. А речь о том, чтобы сделать (автоматический или полуавтоматический) транслятор *.h-файлов с ioctl в, например, набор текстовых команд а-ля Plan9. С символическими именами констант и проверяемыми значениями.

Есть типа культура документирования.

Вот если она действительно есть (точнее, была), это было преимуществом Plan9.

Как раз дьяволы, живущие в деталях, и похоронили Plan9.

Никто его не хоронил.

Жаль его - так и лежит, мертвый и непохороненный.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Займись уже самообразованием. Начни с man rfork. Может, поймешь, чем нити отличаются от процессов.

Да, чем нити принципиально отличаются от процессов с разделяемым адресным пространством?

Потом выясни, что именно означает «P» в POSIX.

Я знаю, что означает «P» в POSIX. И?

Это о чем?

Сделай в иксовом терминале cat бинарного файла, а потом радуйся тому, что вводимый текст стал жирным или фиолетовым.

fcntl, ioctl, и сокеты - это всего 3 костыля

Зато какие!

А речь о том, чтобы сделать (автоматический или полуавтоматический) транслятор *.h-файлов с ioctl в, например, набор текстовых команд а-ля Plan9. С символическими именами констант и проверяемыми значениями.

Офигеть. Вот это решение, no comments. Самообразованием заняться, говоришь?

Вот если она действительно есть (точнее, была), это было преимуществом Plan9.

Почему было? Ты дезинформирован. Plan 9 и сейчас активно развивается.

Жаль его - так и лежит, мертвый и непохороненный.

Разнообразь свою физиологическую терминологию по отношению к техническим системам. Наряду с «мертв» употребляй «в коме» или «болен сифилисом».

grusha
()
Ответ на: комментарий от grusha

> Да, чем нити принципиально отличаются от процессов с разделяемым адресным пространством?

Займись самообразованием - узнаешь.

Я знаю, что означает «P» в POSIX. И?

Ну хоть что-то. А в чем принципиальное отличие clone(2) от rfork(2), знаешь?

Сделай в иксовом терминале cat бинарного файла, а потом радуйся тому, что вводимый текст стал жирным или фиолетовым.

Напоминаю: эмулятор терминала сделан для того, чтобы пускать на растровом дисплее программы, которым нужен tty. Каким образом это костыль?

А речь о том, чтобы сделать (автоматический или полуавтоматический) транслятор *.h-файлов с ioctl в, например, набор текстовых команд а-ля Plan9. С символическими именами констант и проверяемыми значениями.

Офигеть. Вот это решение, no comments

Это решает твою задачу лучше, чем твое решение. Можешь придумать лучше - валяй.

Самообразованием заняться, говоришь?

Да.

Разнообразь свою физиологическую терминологию по отношению к техническим системам. Наряду с «мертв» употребляй «в коме» или «болен сифилисом».

Хочешь сказать, что у Plan9 всего лишь сифилис, и его вылечат?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Займись самообразованием - узнаешь.

ОК, с чего начать? Перед этим ты советовал начать с man rfork. Его я читал много раз (ты ведь не про фряшный rfork?). Слово thread там не встречается.

А в чем принципиальное отличие clone(2) от rfork(2), знаешь?

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

Напоминаю: эмулятор терминала сделан для того, чтобы пускать на растровом дисплее программы, которым нужен tty. Каким образом это костыль?

Эмулятор терминала сам по себе - костыль. Необходимость ежедневно использовать программы, которым нужен tty, - это печально.

Это решает твою задачу лучше, чем твое решение. Можешь придумать лучше - валяй.

Какую задачу? Мое решение - использовать Plan 9. Т.е. если нужно будет портировать ОС на какую-нибудь железку, я выберу Plan 9. В том числе по этой причине.

А насчет задачи вызова ioctl'ов из командной строки в Linux - таки мое решение лучше: оно работает всегда и сразу. Если появится новый хедер с ioctl'ами в неизвестно какой директории, твой костыль надо будет этому учить. Оно мне надо?

Хочешь сказать, что у Plan9 всего лишь сифилис, и его вылечат?

Да нет, сифилис скорее у Linux.

grusha
()
Ответ на: комментарий от grusha

>> Займись самообразованием - узнаешь.

ОК, с чего начать?

С выяснения разницы между нитью и процессами с общим адресным пространством. Потом подумай, как с этим соотносится упомянутый тобой fork (именно fork, не rfork). Надеюсь, после этого ты тихо сольешься, чтобы больше не позориться.

Эмулятор терминала сам по себе - костыль. Необходимость ежедневно использовать программы, которым нужен tty, - это печально.

...хотя больше опозориться уже нельзя.

Не трудись отвечать.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> С выяснения разницы между нитью и процессами с общим адресным пространством. Потом подумай, как с этим соотносится упомянутый тобой fork (именно fork, не rfork). Надеюсь, после этого ты тихо сольешься, чтобы больше не позориться.

Чувак, я упомянул fork как раз-таки с намеком на rfork. Типа я подразумевал, что rfork - это логичное развитие fork, в отличии от pthreads, прикрученных сбоку к юниксовой архитектуре. Не пытайся меня ужалить, я неуязвим.

Где узнать, в чем разница между нитью и процессами с общим адресным пространством? Давай ссылки на источники. Что считается каноническим определением нити? Википедия сойдет? «In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system.» Чем тогда процессы в Plan 9 - не нити?

> Эмулятор терминала сам по себе - костыль. Необходимость ежедневно использовать программы, которым нужен tty, - это печально.

...хотя больше опозориться уже нельзя.

Что не так? Будешь отрицать, что эмулировать железо 30-летней давности для решения повседневных задач - позор?

grusha
()
Ответ на: комментарий от grusha

> Будешь отрицать, что эмулировать железо 30-летней давности для решения повседневных задач - позор?

Во-первых, обратная совместимость — то есть возможность запускать современный софт на старом железе.

Во-вторых, последовательное исполнение в стиле команда > вывод > команда > вывод — это логичный диалоговый интерфейс.

Ты можешь придумать что-то лучше?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от grusha

> Будешь отрицать, что эмулировать железо 30-летней давности для решения повседневных задач - позор?

Опять же, предположим, у тебя сервер без монитора, а то и видеокарты вообще. Как ты на него поставишь GNU/Linux без последовательного терминала?
Универсальный TTY-интерфейс позволяет работать с привычными программами через консоль, подключенную через последовательный порт, да и ещё отладку ядра осуществлять, например.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

> Во-первых, обратная совместимость — то есть возможность запускать современный софт на старом железе.

Ну кому сейчас нужно запускать софт на телетайпах?

последовательное исполнение в стиле команда > вывод > команда > вывод — это логичный диалоговый интерфейс.

С этим я как раз вполне согласен. Но при чем здесь TTY?

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

Опять же, предположим, у тебя сервер без монитора, а то и видеокарты вообще. Как ты на него поставишь GNU/Linux без последовательного терминала?

Универсальный TTY-интерфейс позволяет работать с привычными программами через консоль, подключенную через последовательный порт, да и ещё отладку ядра осуществлять, например.

Не путай понятия. Консоль != TTY. В Plan 9, например, нет никакого TTY.

Возможность запускать ncurses-приложения без монитора (по SSH, UART и т.д.) меня не вдохновляет. Если это новая аппаратная платформа, под которую ведется разработка, то там это не нужно - достаточно CLI. Если это просто удаленная машина, то это неправильный и ограниченный подход; вместо этого удаленная машина должна экспортировать свои ресурсы, например по 9P, чтоб я с ними работал со своей машины, используя свои локальные UI-приложения и не матерясь на тормоза.

grusha
()
Ответ на: комментарий от grusha

> вместо этого удаленная машина должна экспортировать свои ресурсы, например по 9P, чтоб я с ними работал со своей машины, используя свои локальные UI-приложения и не матерясь на тормоза.

А если наоборот, твоя машина экспортирует ресурсы — клавиатуру, дисплей и звуковую систему например? Только вот если скорость связи ограничена, то у тебя оно тормозить будет.

Ну и да, какие свои ресурсы она должна экспортировать, если это скажем сервер, который тебе нужно настроить? Конфигурационные файлы? А ты лог читаешь на терабайт?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

> А если наоборот, твоя машина экспортирует ресурсы — клавиатуру, дисплей и звуковую систему например?

И? В чем проблема?

Ну и да, какие свои ресурсы она должна экспортировать, если это скажем сервер, который тебе нужно настроить? Конфигурационные файлы?

Файловую систему, например. Включая конфигурационные файлы, да.

А ты лог читаешь на терабайт?

Я говорил о тормозах UI.

grusha
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.