А вот я и принес мясорубку :)

>>Netscape for Win3 работает? %)))

NCSA Mosaic for MS Windows v2.0 Alpha2 (c)1993 работает без проблемм.

>А вот я и принес мясорубку :)

Неправильные у тебя кулинарные вкусы...

Причем тут мои вкусы? Это я бездомным собакам скармливать буду :).

> NCSA Mosaic for MS Windows v2.0 Alpha2 (c)1993 работает без проблемм.

И вклад Energizer'a в сей факт был решающим! Ура, товарищи!

из статьи: В большинстве своём программы на Java в использовании неотличимы от своих полноценных собратьев. Насколько мне известно, ощутимая часть GNOME написана именно на Java на такой манер.

мне тоже тоже такую траву:)

>NCSA Mosaic for MS Windows v2.0 Alpha2 (c)1993 работает без проблемм.

А Word for Windows (c) 1989 ??? :))))))

Без Word for Windows (c) 1989 сейчас никак :)

Посмотри сам, если найдешь.

>Посмотри сам, если найдешь.

слив засчитан

> Чушь!!! Не идет Linux вслед за кемто! Не нравиться визуализация - сносим иксы и радуемся первозданной чистоте консоли...

Было бы очень приятно и правильно, если бы так было везде. Но вот если мне нравился XFCE3, но не нравится XFCE4, я либо ухожу с XFCE, либо далее не обновляю систему. А XFCE как раз сделал шаг от копирования CDE к копированию Windows'ифицированого GNOME.

>Посмотри сам, если найдешь.

речь была не об этом, а об древней совместимости, которую начал демонстрировать батарейкин

> Выкинуть из GCC все остальное и будет автору счастье. Автору будет счастье, если выкинуть из gcc Java. И выкинуть из Linux mono. И уничтожить сквозную совместимость по ОС.

> любит KDE и не любит Java -> ему сидеть под Windows и грызть .NET Откуда вывод?

>> Чушь!!! Не идет Linux вслед за кемто! Не нравиться визуализация - сносим иксы и радуемся первозданной чистоте консоли...

>Было бы очень приятно и правильно, если бы так было везде. Но вот если мне нравился XFCE3, но не нравится XFCE4, я либо ухожу с XFCE, либо далее не обновляю систему. А XFCE как раз сделал шаг от копирования CDE к копированию Windows'ифицированого GNOME.

не если вы такой разборчивый уважаемый, то форкайте себе XFCE3 на здоровье и делайте с ней что угодно. Не надо валить с больной головы на здоровую :)))

Ребенок, прежде чем слив засчитывать, найди и поставь на современный линукс хоть какую-нить прогу 10..12-летней давности.

> .. найди и поставь на современный линукс хоть какую-нить прогу 10..12-летней давности.

Запросто. Даже 30..33-летней. Берем исходники и собираем. ;)

К бинарной совместимости это не имеет никакого отношения.

> К бинарной совместимости это не имеет никакого отношения.

Имеет. Полученный бинарь будет работать на современном линуксе.

А теперь найди мне исходники того Word for Windows (c) 1989 .

Весьма глубокомысленная статья. Во многом с автором согласен.

>Да, но проблема в том, что ни одним KDE живет линксоид. Возьмем, например, GIMP: как с ним интегрировать KDE-приложения? Взаимосвязь должна быть глужбе, нежели на уровне тулкитов.

Самый мудрый комментарий. freedesktop, будем надеяться, исправит положение.

>1) будет убран arts в пользу gstreamer >2) dcop в пользу dbus >3) kdebase будет разбит на N пакетов поменьше

Отлично. Вот тогда и надо будет на него посмотреть, может починят баг с переключением раскладки, хотя вряд ли.

>Отлично. Вот тогда и надо будет на него посмотреть, может починят баг с переключением раскладки, хотя вряд ли.

Нефиг KDE'шной переключалкой пользоваться, рулит иксовая.

>Про GNOME цитата: "Боясь напугать неопытного пользователя, авторы GNOME >с каждым релизом этого окружения всё уменьшают и уменьшают возможности >по настройке. К примеру, мы лишились возможности независимо >устанавливать фоновые рисунки для рабочих столов." Так в KDE идет та же >самая фигня. В старых версиях можно было "оторвать" любое подменю из >главного и расположить его в виде окна. Удобно. В новых этого нет. >Почему??? Не понимаю....

В KDE можно включить Menu tearoff handles: Application level (Style в Control Center), и "отрывалка" появляется в тех приложениях, которые это умеют. Например, в Konsole.

>>Имеет. Полученный бинарь будет работать на современном линуксе.

А как запустить бинарник 10..12-летней давности на современном линуске?

А нахрен это надо? Вот под виндой надо.

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

> А как запустить бинарник 10..12-летней давности на современном линуске?

На линуске не знаю, а на линуксе, например, берем /sbin/lsmod из slackware-3.3:

% cat /etc/sisyphus-release
ALT Linux Sisyphus (20050817)
%
% ./lsmod
Module: #pages: Used by:
sr_mod 15024 0 (autoclean)
cdrom 27744 0 (autoclean) [sr_mod]
sg 30556 1 (autoclean)
nls_iso8859-1 2812 0 (autoclean)
isofs 26228 0 (autoclean)
zlib_inflate 19748 0 (autoclean) [isofs]
loop 8376 0 (autoclean)
nls_koi8-r 3836 0 (autoclean)
nls_cp437 4348 0 (autoclean)
vfat 9676 0 (autoclean)
fat 31032 0 (autoclean) [vfat]
appletalk 20580 0 (autoclean)
ipx 16548 0 (autoclean)
cs4281 44808 1
soundcore 3652 3 [cs4281]
spca50x 149504 0
videodev 5792 1 [spca50x]
sd_mod 12044 0
usb-storage 139872 0
usb-uhci 21548 0 (unused)
usbcore 58592 1 [spca50x usb-storage usb-uhci]
nfsd 69456 8 (autoclean)
lockd 48624 1 (autoclean) [nfsd]
sunrpc 64892 1 (autoclean) [nfsd lockd]
autofs4 8244 1 (autoclean)
8139too 13256 1 (autoclean)
mii 2544 0 (autoclean) [8139too]
crc32 2880 0 (autoclean) [8139too]
xfs 525984 2 (autoclean)
reiserfs 191376 4 (autoclean)
processor 8952 0 (unused)
button 2860 0 (unused)
ac 1792 0 (unused)
battery 6000 0 (unused)
agpgart 47044 0 (unused)
ide-scsi 9520 1
scsi_mod 95440 5 [sr_mod sg sd_mod usb-storage ide-scsi]
rtc 6236 0 (autoclean)
ext3 62224 2
jbd 38076 2 [ext3]
%

Старше бинаря не нашел пока :)

>>А нахрен это надо?

В этом треде некий онанимус заявил буквально следующее: "Кстати бинарная совместимость в линухе чуть ли не крче, чем в винде"

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

ps: Сейчас слушаю музыку плеером WinPlay3 1997 г.в.

Примитивно. А как на счет гуёвого прикладного софта? Ж..па? ЧиТД :).

>Примитивно.

Что примитивно? Ядро, между прочим, за это время очень сильно изменилось.

> Примитивно. А как на счет гуёвого прикладного софта?

А это не ты писал:

>А как запустить бинарник 10..12-летней давности на современном линуске?

>Energizer (*) (23.10.2005 22:12:02)

/sbin/lsmod не бинарник разве? Так шта надо точно формулировать условие задачи, товарисч профессор ;))

> Что примитивно? Ядро, между прочим, за это время очень сильно изменилось.

btw, модули старый lsmod правильно кажет

да батарейкин с разгону перданул в лужу так что всех забрызгал :) вот только признаться не может :)

без проблем работает софт писаный под x11 хоть за 80-й год

>А как на счет гуёвого прикладного софта?

Ничего старше Mosaic 2.5 for X11 от 22.07.1995 не нашёл. Смотри http://mikhail.solutions.lv/2.png.

Бинарник почти 13-летней давности (15 января 1993 года файл датируется, сборка 5-го января того же года) gzip (версия 0.7) из дистра SLS-1.03 (на ядре 0.99 который еще), вместе с либцой 4.4.2, предварительно скопированной в /lib, пашет как швейцарские часы.

Батарейкин, это был твой самый готичный слив за всю историю твоего быта на ЛОРе. Зажигай дальше!

О какой совместимости спорите? Кажется ESR писал (а может и не он), что Open Source программы долго "живут" из-за того, что есть их код, т.е. пересобрал через пару лет на текущей системе, и все работает. А у "closed source" приходится делать всякие work-around для обратной совместимости. Конечно, это не относится к низкоуровневым вещам.

Т.е. в Open Source бинарная совместимость не так критична, как в проприетарных системах.

> Ничего старше Mosaic 2.5 for X11 от 22.07.1995

Миша, ссылку кинь, plz, на ентот mosaic, ностальгия типа гложет.

> Пришлось ему доказать, что в винде бинарная совместимость все-таки круче.

естественно круче. потому что в линуксе она не особо и нужна. даже вообще не нужна.

Философия ЮНИКС (часть 1)

модераторы сотрите плиз мой предыдущий пост
попытка номер два...

Дабы яснее было о чём собственно идёт речь в обсуждаемой статье привожу статью из Википедии любезно переведённую мной :), я узнал кое-что нового из неё и советую всем не брезговать чтением, она явно полезнее обсуждаемого опуса.
Было бы просто здорово после корректуры выложить этот перевод в онлайн с быстрым доступом.
============================================================
http://en.wikipedia.org/wiki/Unix_philosophy

Философия Unix

------------------------------------------------------------
McIlroy(http://en.wikipedia.org/wiki/Doug_McIlroy): Четверть века Unix

Doug McIlroy, создатель Unix pipes(http://en.wikipedia.org/wiki/Pipes_and_filters) и один из основателей традиции Unix кратко выразил эту философию тремя пунктами:

* Пишите программы(http://en.wikipedia.org/wiki/Computer_program) которые делают одну вещь и делают это хорошо;
* Пишите программы которые способны работать вместе;
* Пишите программы которые обрабатывают текстовые потоки, потому что это универсальный интерфейс.

Обычно эти пункты сильно сокращаются к "Делай одну вещь, делай это хорошо"

Из трёх принципов только третий характерен для Unix, хотя Unix разработчики часто подчёркивают все три принципа больше, чем другие разработчики.
------------------------------------------------------------
Pike(http://en.wikipedia.org/wiki/Rob_Pike): Заметки по Программированию в С

Rob Pike предлагает следующие "правила" в книге "Заметки по Программированию в С"(http://www.lysator.liu.se/c/pikestyle.html) как заповеди программирования(http://en.wikipedia.org/wiki/Computer_programming), хотя они легко могут быть рассмотрены как пункты философии Unix:

Правило 1: Вы не можете сказать где программа собирается тратить большую часть своего времени. Узкие места возникают в неожиданных местах, поэтому не пытайтесь предугадать и вставить хак для скорости до тех пор, пока вы не докажете что это и есть то самое узкое место.
Правило 2: Измерение. Не делайте подстройку для скорости не измерив, и даже затем не делайте, если не одна часть кода подавляет остальные.
Правило 3: Причудливые алгоритмы(http://en.wikipedia.org/wiki/Algorithm) медленны когда n мало, и n обычно мало. Причудливые алгоритмы имеют большие константы. Если вы не знаете как часто n будет велико, то не выделывайтесь (прим перев: don't get fancy). (Даже если n действительно велико используйте сначала Правило номер 1)
Правило 4: Причудливые алгоритмы более "ошибкосклонные" (прим перев: buggier - такого слова в словаре нет, есть bugger - содомит), и их реализация намного более сложная. Используйте простые алгоритмы, так же как и простые структуры данных(http://en.wikipedia.org/wiki/Data_structure).
Правило 5: Данные рулят. Если вы выбрали правильные структуры данных и спланировали вещи хорошо (прим перев: видимо имеется ввиду архитектура), то алгоритмы будут почти само-очевидными. В программировании руководят структуры данных, не алгоритмы.
Правило 6: Правила номер 6 нет.

Правила Пайка номер 1 и 2 переформулируют знаменитый принцип Тони Хоара(http://en.wikipedia.org/wiki/C._A._R._Hoare) "Преждевременная оптимизация(http://en.wikipedia.org/wiki/Optimization_(computer_science)) - корень всех зол". Кен Томпсон(http://en.wikipedia.org/wiki/Ken_Thompson) перефразировал правила Пайка номер 3 и 4 как "Если сомневаешься используй грубую силу(http://en.wikipedia.org/wiki/Brute_force)" (прим перев: к сожалению прошибить стену лбом получается не всегда и не у всех). Правила 3 и 4 - это частный случай философии проектирования KISS(http://en.wikipedia.org/wiki/KISS_principle) (прим перев: Keep It Simple Stupid - делай проще придурок). Правило 5 было ранее сформулировано Фредом Бруксом(http://en.wikipedia.org/wiki/Fred_Brooks) в труде "Мифический человеко-месяц" (http://en.wikipedia.org/wiki/The_Mythical_Man-Month). Правило 5 часто сокращается до "пишите тупой код использующий умные данные". Правило 6 родом из наброска Брюса(http://en.wikipedia.org/wiki/Bruces_sketch) из "Летающего цирка" Монтий Питона(http://en.wikipedia.org/wiki/Monty_Python's_Flying_Circus)
------------------------------------------------------------
Mike Gancarz: Философия UNIX

В 1994 Mike Gancarz объединил свой опыт с Unix (он член команды спроектировавшей X Window System(http://en.wikipedia.org/wiki/X_Window_System)) с обсуждениями, в которых он участвовал с коллегами программистами и людьми из других областей зависящих от Unix, чтобы выпустить книгу "Философия UNIX". Эта книга резюмирует изложенную философию в 9 верховных предписаний:
* Малое прекрасно
* Заставляй каждую программу делать одну вещь хорошо
* Делай прототип как можно раньше
* предпочитай переносимость эффективности
* Храни данные в простых текстовых(http://en.wikipedia.org/wiki/Text) файлах
* Используй програмные рачаги (средства) для своей выгоды
* Используй шелл-скрипты(http://en.wikipedia.org/wiki/Shell_script) чтобы увеличить "силу рычага" (програмных средств) и переносимость
* Избегай связывающих (пленяющих) пользовательских интерфейсов
* Делай каждую программу как фильтр

Десять меньших принципов не ставших универсальными как часть философии Unix и, в некоторых случаях, жарко обсуждаемых (монолитное ядро(http://en.wikipedia.org/wiki/Kernel_(computer_science)#Monolithic_kernels) против микроядра(http://en.wikipedia.org/wiki/Kernel_(computer_science)#microkernels)):
* Позволяй пользователю приспособить окружение
* Делай ядро Операционной Системы простым и легковесным
* Используй нижний регистр и будь краток
* Сохраняй деревья
* Молчание - золото
* Думай параллельно
* Сумма частей больше, чем целое
* Ищи 90-процентное(http://en.wikipedia.org/wiki/90/10_law) решение
* Хуже есть лучше(http://en.wikipedia.org/wiki/Worse_is_better)
* Думай иерархически

ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/binaries/old/2.5/Mosaic-linux-static-2.5.Z

Философия ЮНИКС (часть 2)

Хуже есть лучше(http://en.wikipedia.org/wiki/Worse_is_better)

Richard P. Gabriel(http://en.wikipedia.org/wiki/Richard_P._Gabriel) предложил, что ключевое преимущество Unix заключается в том, что Unix воплощает философию проектирования "Хуже есть лучше". В манере "Хуже есть лучше" простота обоих интерфейса и реализации более важна, чем любая другая черта этой системы, включая корректность, согласованность и завершённость. Габриель утверждает, что эта манера проектирования имеет ключевые эволюционные преимущества, хотя он ставит под сомнение качество некоторых результатов.

Например, в ранние дни UNIX имела монолитное ядро(http://en.wikipedia.org/wiki/Monolithic_kernel) (что означает, что процессы пользователя выполняют все системные вызовы на стеке пользователя). Если некоторый сигнал был вручён процессу, когда последний был заблокирован на длительном вводе-выводе в ядре, таком как sleep (10*60), то что должно быть сделано? Должен этот сигнал быть отложен, возможно на долгое время (может быть неопределено), до тех пор пока ввод-вывод не завершится? Обработчик сигнала не мог быть вызван когда процес был в режиме ядра с чувствительными данными ядра на этом стеке. Должно ядро откатить этот системный вызов и сохранить его для перевоспроизведения и перезапуска позднее, предполагая, что обработчик сигнала завершится успешно?

В таких случаях Кен Томпсон(http://en.wikipedia.org/wiki/Ken_Thompson) и Деннис Ритчи(http://en.wikipedia.org/wiki/Dennis_Ritchie) предпочли простоту совершенству. Система UNIX должна иногда возвращаться преждевременно из системного вызова с ошибкой, что ничего не сделано - "Прерванный сискол" ("Interrupted System Call") - ошибка номер 4 (EINTR) в современных системах. Конечно, этот вызов прекращается (aborted), чтобы вызвать обработчик сигнала. Такое должно случаться только для горстки "долго-играющих" сисколов таких как read(), write(), open(), select(), и тд. Что касается плюсов, то это делает систему ввода-вывода намного проще спроектировать и понять. Подавляющее количество пользовательских приложений никогда не были затронуты, поскольку они не обрабатывают или не чувствуют сигналы отличные от SIGINT/^C и должны завершиться прямо в момент его получения. Для очень небольшого числа приложений - подобных шеллам или текстовым редакторам - которые отвечают на комбинации клавиш управляющих заданиями - эти приложения могли бы вставить небольшие обёртки вокруг сисколов и перезапускать сисколы сразу, как только ошибка EINTR произошла. Проблема решена простым способом.

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

В течение дясятилетия, вследствие философии Unix и результирующей простоты системы, общим свойством UNIX систем стало превосходство над другими коммерческими операционными системами в среднем времени отказа измеряемом месяцами, а не часами.
------------------------------------------------------------
Raymond: Искусство Программирования в Unix

Eric S. Raymond(http://en.wikipedia.org/wiki/Eric_S._Raymond) в своей книге "Искусство Прграммирования в Unix"(http://en.wikipedia.org/wiki/The_Art_of_Unix_Programming) резюмирует философию Unix как широко известную инженерную философию KISS(http://en.wikipedia.org/wiki/KISS_Principle). Затем он описывает как по его предположению эта всеобщая философия применяется как культурная норма Unix, хотя неудивительно, что довольно просто найти серьёзные нарушения большинства следующих пунктов в фактической деятельности в Unix:
* Правило Модульности(http://en.wikipedia.org/wiki/Modularity_(programming)): Пиши простые части связанные чистыми интерфейсами
* Правило Доходчивости: Доходчивость лучше, чем мастеровитость (cleverness)
* Правило Разделения: Отделяй правила от механизмов; отделяй интерфейсы от реализаций (engines)
* Правило Простоты: Проектируй для простоты, добавляй сложность только где должен
* Правило Расчётливости: Пиши большую программу только когда ясно из демонстрации, что ничего другого она делать не будет
* Правило Прозрачности: Проектируй для обзора (~просмотра), чтобы сделать обследование и отладку проще
* Правило Надёжности: Надёжность есть следствие прозрачности и простоты
* Правило Представления: Свёртывай знания в данные, чтобы програмная логика была тупа и проста
* Правило Наименьшего Удивления: Проектируя интерфейс, всегда делай наименее удивительную вещь
* Правило Молчания: Когда программа не должна говорить ничего удивительного, она ничего не должна говорить
* Правило Восстановления: Когда вы должны выйти из строя, выходите из строя шумно как это только возможно
* Правило Экономии: Время программиста дорого, сохраняй его в предпочтении к машинному
* Правило Порождения(http://en.wikipedia.org/wiki/Code_generation): Избегай ручной работы, пиши программы, которые пишут программы когда можешь
* Правило Оптимизации(http://en.wikipedia.org/wiki/Optimization_(computer_science)): Прототип(http://en.wikipedia.org/wiki/Prototype) до полировки. Сделай его работающим перед тем как будешь оптимизировать
* Правило Разнообразия: Не верь утверждениям "единственно верный путь"
* Правило Расширяемости: Проектируй в будущее, потому что оно наступит быстрее чем ты думаешь

Многие из этих норм приняты вне коммюнити Unix - если не в момент когда Unix впервые использовал их, то позднее. Также, многие не уникальны для коммюнити Unix. Тем не менее, мастера прораммирования в Unix имеют тенденцию к принятию этих идей как основание стиля Unix.

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

> ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/binaries/old/2.5/Mosaic-linux-static-2.5.Z

THANX!

>Ребенок

от такаго слышу

>найди и поставь на современный линукс хоть какую-нить прогу 10..12-летней давности.

:) насмешил.

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

а если прога еще и в исходиках...

Во, хоть один знающий чел попался! Раскажи мне, родной, как поменять это идиотскую дефолтную тему в jre с белыми фонами, а то глаза чай не казённые - беречь надо! Моник у меня хороший - а вот, падлы, дезигнеры, достали своими белыми фонами! Ну, подскажи, ведь простая задачка-то.

>Однако все не так просто. В виндовсе скажем вбухиваются огромные деньги на иследование "удобства использования"

Самое смешное, что никто и никогда ни привёл ни единого аргумента в доказательство этого утверждения! Ни ссылки с графиками, ни протокола исследования! Докажите мне, пожалуйста что "многомиллионные ислледования" - это не 3.14здеж, ато смотрю я на вендовые "удобства" и плакать хочицца!

> естественно круче. потому что в линуксе она не особо и нужна. даже вообще не нужна.

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

В линухе она нужна - но ее нет. Увы. Именно из-за бардака в двоичной совместимости оракл без напильника ставится только на очень небольшой набор дистрибутивов. Из-за нее, родимой, каждый новый релиз ядра (стабильного, чтоб его!) порождает волну вопросов со стороны несчастных пользователей двоичных дров разных видях. И т.д. и т.п.

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

>>без проблем работает софт писаный под x11 хоть за 80-й год

Ну-ка, ну-на, в студию нам предоставь x11-софтину, которая будет работать в современном линуксе.

ГУИ-шный браузер Mosaic под вин3.хх датированый 1993 годом (более старой виндовой софтины с ходу не нашел) без каких-либо предврительных шаманств с ходу завелся в винХР СП2 датированой 2004 годом. Явно кто-то из нас двоих слил. Также явно, что это не я :)