LINUX.ORG.RU
Форум — Talks  

а чего про годовщину эпохи Unix никто не вспомнил?


0

3

дохренадцать лет назад, в полночь 1 января 1970 от рождества Христова по старому стилю началась эпоха Unix. от этого момента все прогрессивное чел-овечество таперича и ведет отсчет времени. и никому дела нет!
а то как быдляцкий новогод - так аж на глагне в полэкрана, а про такое событие даже никто слова не сказал((
надо исправляться! возрадуемся же, други! и да спасет нас Столлман от проблемы 2000 2038 года! (а была ли проблема?) алюминь!
кстати, кто тут самый умный? в 0 по unix time какой год эпохи начался? нулевой же, правда ведь?

★

Последнее исправление: PerdunJamesBond (всего исправлений: 1)
← Инженер Oracle добавил в GCC поддержку ALGOL 68
Не стало Алксниса →
  1 2 3 →
Ответ на: комментарий от urxvt

А вот, например, если я из Python/Lua захочу прочитать, получится?

В Питоне стандартный модуль, например.

Если речь о том, чтобы сделать это только cat’ом, то очевидно нет. Но непонятен смысл такого ограничения. Стабильный C API меня устраивает больше, чем текстовый интерфейс, к которому в нагрузку идет мильен форматов, и к которым в доброй половине случаев пишут косячные ad-hoc парсеры.

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

Стабильный C API меня устраивает больше, чем текстовый интерфейс, к которому в нагрузку идет мильен форматов, и к которым в доброй половине случаев пишут косячные ad-hoc парсеры.

У данного подхода есть и существенные минусы.
* пользователь должен быть способен написать программу на С
* пользователь должен быть готов на каждый чих писать программу на С

Юниксовый подход тут выгодно отличается.

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

На момент начала-середины 90х ядро NT было огромным шагом вперёд.

Ядро NT это костыль на костыле и костылём погоняет. Кто ковырялся в во всяких ntdll.dll ntoskrnl.exe и пр. прекрасно представляет себе какое это убожество.

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

Отвратительный комок разнородного плохо слепленного кода, который продолжают обмазывать всё более невменяемыми козявками.

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

IBMовская OS/2 тоже, кстати, срань ещё та, но и то поприличнее.

Да, юниксы тоже ни разу не фонтан, но это на порядок более грамотный и логичный подход к созданию ядра ОС.

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

Заставить драйвер написать для категории периферии не запланированной в ядрышке.

Удивительно, но при этом для NT драйверов куда больше чем для лялекса. Как же так?

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

Я заглядывал в лялекс и в NT и лялекс кажется лютым позором тут.

Да, юниксы тоже ни разу не фонтан, но это на порядок более грамотный и логичный подход к созданию ядра ОС.

Какие именно юниксы ты имеешь ввиду здесь?

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

Удивительно, но при этом для NT драйверов куда больше чем для лялекса. Как же так?

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

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

Я заглядывал в лялекс и в NT

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

Наверно ты читал дебильные маркетинговые статейки про архитекутру Windows NT, которые ничего общего с реальным положением дел не имеют, а не ковырялся в реальных бинарниках этой дряни.

Какие именно юниксы ты имеешь ввиду здесь?

Почти все, хоть чпукс, хоть сис5, хоть бзди с линуксом.

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

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

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

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

Если бы ты не был шизофреником, тебе бы не казалось, что тебе врут.

Почти все, хоть чпукс, хоть сис5, хоть бзди с линуксом.

Это четыре разных ОС с минимум два разными подходами к архитектуре. Про чпукс я мало что знаю (как наверняка и ты). Классический UNIX (в т.ч. Sys V) был непортируемым монолитом. BSD и Linux тащат идеи в том числе из венды. См выше про *fd как реализацию объектов с более-менее одинаковым API.

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

пользователь должен быть способен написать программу на С

Зачем? Ее уже написали авторы powershell и прочих скриптовых. Так же как в линуксе написали coreutils. Разве что в старых NT этого не было из коробки, раз уж топик про историю.

А сегодня винда едва ли не более скриптуема чем линукс. Живые юниксы - наоборот уходят всё дальше от прозрачности и вот этого всего UNIX zen.

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

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

Вообще-то производители железа очень недавно начали писать драйвера под линукс для своего железа. И этих производителей можно по пальцам перечесть.

Это четыре разных ОС с минимум два разными подходами к архитектуре.

И все они намного лучше и опрятнее NT.

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

Вообще-то производители железа очень недавно начали писать драйвера под линукс для своего железа.

Ещё бы они их писали, если для каждой следующей версии ядра нужно их переписывать, потому что stable api nonsense. Я бы такую говноось тоже нахрен послал.

И все они намного лучше и опрятнее NT.

Интересно, в чём ты это измеряешь? Неужели в длине идентификаторов?

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

Интересно, в чём ты это измеряешь? Неужели в длине идентификаторов?

В том, насколько удобно переделывать и что-то дописывать. В том, сколько времени нужно чтобы разобраться как всё на самом деле устроено.

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

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

В том, насколько удобно переделывать и что-то дописывать.

Что именно ты в венде собрался переделывать и дописывать? Это закрытая система.

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

Я быстрым грепом сейчас в люнексовом ведре нашёл пять реализаций списков. Что там с систематизацией кода?

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

Что именно ты в венде собрался переделывать и дописывать?

Всё что хочу.

Это закрытая система.

Мне насрать.

Я быстрым грепом сейчас в люнексовом ведре нашёл пять реализаций списков. Что там с систематизацией кода?

«Давайте захреначим для интерфейса с ядром либу ntdll.dll которая будет работать и в юзерспейсе и в ядре, но из юзерспейса будут вызываться функции NtXxxxxxYxxxxxZzzzzzLlllllGgggBbbbbTttt а для вызовов из ядра там будут полные копии этих функций названные ZwXxxxxxYxxxxxZzzzzzLlllllGgggBbbbbTttt».

«Давайте ядро будет лазать в бинарный файл за параметрами загрузки драйвера и чтобы драйвер туда же лазал и юзерспейс тоже и чтобы это всё юзер мог снести случайно или похерить до BSOD, и назовём это registry».

«Давайте захерачим для сисколлов int 2Eh. А для GDI сисколлов другое прерывание с совершенно другим интерфейсом. А для семафоров третье. И ещё всяких чтобы было богато.»

И т.п.

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

«Давайте захерачим для сисколлов int 2Eh

Breakpoint 0 hit
ntdll!NtCreateFile+0x12:
00007ffa`6fe2df92 0f05            syscall
0:000> u
ntdll!NtCreateFile+0x12:
00007ffa`6fe2df92 0f05            syscall
00007ffa`6fe2df94 c3              ret
vM ★★★
()
Ответ на: комментарий от urxvt

Речь же была о C API vs «текстовый интерфейс» (файловый).

Какой там Си дохренадцать лет назад, в полночь 1 января 1970 ??

Объектные модули в UNIX были файловые, но не текстовые. А «текстовый» интерфейс с as, sh и ed (командный)

https://www.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix/cmd/as.s

https://www.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix/cmd/ed1.s

https://www.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix/cmd/ed2.s

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

В 1980 до выпуска 80286 надо было ещё ждать пару лет

А WinNT вообще появилось только в 1993 году когда уже и 386 был и памяти в компах по несколько мегабайтов было не редкостью. Так что IBM PC очень долго не обладали достаточными ресурсами чтобы запустить на них хоть какую-нибудь полноценную ОС. Вот Микрософту и приходилось выкручиваться.

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

XENIX несколько старше, чем the IBM PC

Так это Микрософт пытался его на писюках запускать. В то время когда пытались - сами писюки были не особо пригодны для запуска полноценной ОС.

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

Это закрытая система.

Мне насрать.

Так и авторам насрать на твои хотелки. Просто это система не для тебя. Смирись.

«Давайте захреначим для интерфейса с ядром либу ntdll.dll которая будет работать и в юзерспейсе и в ядре, но из юзерспейса будут вызываться функции NtXxxxxxYxxxxxZzzzzzLlllllGgggBbbbbTttt а для вызовов из ядра там будут полные копии этих функций названные ZwXxxxxxYxxxxxZzzzzzLlllllGgggBbbbbTttt».

А плохого-то что?

«Давайте захерачим для сисколлов int 2Eh. А для GDI сисколлов другое прерывание с совершенно другим интерфейсом. А для семафоров третье. И ещё всяких чтобы было богато.»

Не вижу тут плохого дизайна всё ещё.

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

А какая разница, на чем они были написаны изначально? Речь же была про интерфейс между ядром и пользовательским софтом, пользовательскими программами между собой.

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

Syscall стал использоваться только с появлением пней и т.п. Как минимум в Win8 это вот так выглядит для 32 бит:

        test byte [abs 7FFE0308h], 01h
        jnz label
        syscall
        ret    
label:  
        int 2Eh
        ret

Причём для 64 бит тоже так же, хотя абсолютно все процессоры умеющие amd64 умеют и syscall. :)

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

C API vs «текстовый интерфейс» (файловый)

Так я не предлагаю давать C пользователям. Я говорю, что бинарный формат - не препятствие скриптованию, и реестр это подтверждает.

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

Так я не предлагаю давать C пользователям. Я говорю, что бинарный формат - не препятствие скриптованию, и реестр это подтверждает.

Препятствует. В случае с двоичным форматом тебе придется пользователю предоставить утилиту для работы с этим данными. И пользователь в своих сприптах ограничен интерфейсом предоставленной утилиты. В случае же с «сырыми» текстовыми данными он практически ничем не ограничен и может на условном sed'е наворотить что угодно.

P. S.
Полистал виндовые доки: как-то оно вырвиглазно выгляди, для каждой команды чуть ли не свой язык (как у юниксового find). Беее...

urxvt ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
  1 2 3 →
← Инженер Oracle добавил в GCC поддержку ALGOL 68
Talks
Не стало Алксниса →