Windows vs. Linux , Продолжение

Что важнее, у 8086/88 не было защищенных режимов работы с памятью (они даже в ДВК были), чтобы на них полноценно могли работать системы UNIX или BSD.
На 80286 вроде можно было запустить IBM'овский XENIX (тоже вариант UNIX)

Цитата Guderian @ 03.12.10, 23:36

Цитата D_KEY @ 02.12.10, 17:46

Создавай. Я работал в Windows и писал программы под нее достаточно долго(больше, чем делаю это под *nix) и считаю, что могу сравнивать.
Продуктивность в *nix системах гораздо выш

Я десять лет ходил в красных носках и жал лежа не больше 150, но последний год хожу в синих и стал жать 160. Синие носки определенно делают меня сильнее. Вот такая вот история об измерении продуктивности.

Странная аналогия. Окружение влияет на продуктивность, в отличие от цвета носков, которые на "жим" влиять не могут.
Кроме того, я windows не перестал пользоваться, в том числе и по рабочим вопросам. Вот тот же powershell - клевая штука, еще бы консоль была удобная...

Цитата

Цитата D_KEY @ 03.12.10, 14:19

Кроме того люди, занимающиеся решениями на базе Unix, просто не разглядели преимущества PC'шек.

Как это пустяшно звучит: "просто не разглядели". Зачем им было разглядывать, если они драли бабло с обывателя за продажу компьютерного времени. Может вопреки этому появились мальчишки вроде Пола Аллена (которому помниться не хотели давать аттестат, пока он не оплатит фантастические для начала 70-х $200 за то самое компьютерное время) и Гейтса, которые просто бредили идеей персонального компьютера в каждый дом. Зато сейчас, когда практические у каждого он есть, большинство считает, что появились они естественным путем. Без участия этой парочки. Так вознесем хвалу unix, сосредоточенному в лапах жадных корпораций. Тому самому, который в большинстве своем был одной из самых дорогих ОС и самых медленных в развитии. Хорошо, что появился еще один одержимый человек в лице Столлмана. Я бы посмотрел на развитие идеи свободного ПО без него и появление GNU/Linux без GNU (со всеми его утилитами, toolchain и т.п.).

Да я, в общем-то, согласен с тобой. Можешь убрать слово "просто", если оно тебе не нравится.

Цитата

Цитата D_KEY @ 03.12.10, 14:19

А Билл, в свою очередь, понял, что обычным людям хватит и убогого ДОСа, контракт с IBM + перекупленная за копейки ОС. Что еще нужно?

Меня даже любопытство разбирает, а кто у нас выступал в качестве конкурента "убогому ДОСу"? Я к стыду своему в 80-х из юниксов видел только BSD (еще далеко не Free) и УНИКС (та, которая на Искрах), плотно работал с RT-11, Apple DOS. После всего этого унылого говна MS-DOS (с Norton Commander, серией Turbo*- и Quick*-компиляторов, dBase, Lotus 1-2-3, а уж Лексикон…) стал просто глотком свежего воздуха и раем. Практически все московские НИИ АСУ выкидывали свои Wang 2200 и ставили машинки вроде Amstrad PC. Может просветишь, что мы все тогда должны были использовать, кто светоч? SunOS 1.x/3.x? System V?

Ты считаешь, что возможности ДОСа были богатыми? Я не говорил об альтернативах, я говорил о том, что Билл совершенно правильно проанализировал ситуацию.

Знали ли вы, что OS/2 не была первой многозадачной не-Unix ОС от Microsoft?

Цитата Ho Im @ 04.12.10, 11:03

У PC и егойного 8088 (и даже 8086) наверняка бы не хватило дыхалки гонять BSD Unix. А Minix мало того, что был потом, так он еще и позиционировался как сугубо для обучения, ввиду чего был обрезан по самые глянды.

Ho Im, тут как говорится было бы желание ;-)

Цитата korvin @ 03.12.10, 22:41

Цитата MichSpar @ 03.12.10, 14:11

Ho Im, ты так торжественно об этом написал, что мне аж самому захотелось этим пользоваться. Но потом я вспомнил, что уже пользовался "этим". А ещё я вспомнил, что рынок таки захватила компания, делающая продукты не для себя, а для других.

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

Открой же великую тайну, благодаря чему же тогда?

Добавлено 05.12.10, 07:49

Цитата Ho Im @ 03.12.10, 23:02

Торвальдс подойдет, говоришь? KISS, говоришь?

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

Ядро Linux по _простоте_ кода ни в твоем понимании, ни с точки зрения здравого смысла, критики не выдерживает. У него есть в противовес этому всего лишь два преимущества, очень весомых, которые его сложность перевешивают в пару раз: 1) открытость и даже понимаемость кода после определенного количества поллитр: написать свой драйвер для своей железяке можно быстро, доков для этого читать много и по всем подсистемам не надо; 2) оно, вопреки вообще всему, работает, причем на удивление стабильно.

That being said, если в ядре ошибка где-то на уровне инфраструктуры, то ее корневую причину заколебешься искать. Тот же 12309, к примеру — невероятно большой iowait без видимых на то причин. Оказалось синдромом из кучи разрозненных багов, хотя никто не знает, устранится ли проблема, если починить их все, или нет.

Это ты к тому, что в ядре этим KISS'ом и не пахнет? Как же это так? Тогда нафиг его вообще пропагандировать, если линус - вон какой молодец без всяких кисов обошёлся?

Добавлено 05.12.10, 07:52

Цитата Ho Im @ 04.12.10, 00:41

Не знаю, где там талант, а знаю одно: всех академиков, живущих в башне из слоновой кости и издающих талмуды о том, каким должен быть идеальный код и какой должна быть идеальная сферическая микроядерная ОС в вакууме, объединяет одно: от них никогда нет результата, который можно не боясь ставить в продакшен. Я понимаю, что теоретически Hurd труёвее всех, но оно не работает, а если и работает, то жутко тормозит и падает время от времени. Его архитектуру меняли несметное количество раз. И где ОНО? Где РЕЗУЛЬТАТ?

А мне тут интересно стало, какое процентное соотношение на продакшн серверах между бздёй и линаксам?

Цитата MichSpar @ 05.12.10, 07:47

Открой же великую тайну, благодаря чему же тогда?

Агрессивному маркетингу.

Цитата MichSpar @ 05.12.10, 07:47

А мне тут интересно стало

Целый гугл в твоем распоряжении

Цитата MichSpar @ 05.12.10, 07:47

Тогда нафиг его вообще пропагандировать, если линус - вон какой молодец без всяких кисов обошёлся?

А как связан Линус с пропагандой KISS?
В очередной раз тебе говорю, что ты под KISS'ом понимаешь что-то не то. Причем откуда ты этого понабрался остается загадкой.

Цитата D_KEY @ 05.12.10, 12:22

А как связан Линус с пропагандой KISS?

Точно так же, как Линус связан с сообществом линуксоидов, проповедующих этот принцип.

Цитата D_KEY @ 05.12.10, 12:22

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

Под KISS я понимаю его буквальную расшифровку: Keep it simple, stupid. Если это "что-то не то", тогда извините...

Цитата MichSpar @ 05.12.10, 13:05

Цитата D_KEY @ 05.12.10, 12:22

А как связан Линус с пропагандой KISS?

Точно так же, как Линус связан с сообществом линуксоидов, проповедующих этот принцип.

Ты считаешь, что этот принцип пропагандируют исключительно линуксоиды?
Найди мне хоть одну профессиональную статью/книгу по разработке ПО, где бы ругали такой подход и рекомендовали усложнять проектные решения.
Будет интересно посмотреть.
Пока же я вижу, что вся наша индустрия(разработки ПО) строится на попытках управления сложностью.

Цитата

Цитата D_KEY @ 05.12.10, 12:22

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

Под KISS я понимаю его буквальную расшифровку: Keep it simple, stupid. Если это "что-то не то", тогда извините...

Во-первых, зависит от того, что ты понимаешь под простотой.
А во-вторых... У тебя каша в голове относительно вообще процессов разработки ПО. Более того, ты защищаешь ГУИ(не понятно только от кого, ведь здесь никто его не критикует), при этом не понимая, что и при его проектировании фактически соблюдаются теже принципы.
Тебе нравятся неоправданно сложные решения? Что ты вообще хочешь доказать?

Сообщение отредактировано: D_KEY - 05.12.10, 13:41

Цитата D_KEY @ 05.12.10, 13:41

Ты считаешь, что этот принцип пропагандируют исключительно линуксоиды?

Именно.

Цитата D_KEY @ 05.12.10, 13:41

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

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

Цитата D_KEY @ 05.12.10, 13:41

У тебя каша в голове относительно вообще процессов разработки ПО.

Что-то не припомню, чтобы я тут описывал свою точку зрения на процесс разработки ПО. Ты случайно принцип с процессом не путаешь? На всякий случай внесу ясность: KISS - это принцип; принципы разработки применяются в процессе разработки.

Цитата D_KEY @ 05.12.10, 13:41

Более того, ты защищаешь ГУИ(не понятно только от кого, ведь здесь никто его не критикует), при этом не понимая, что и при его проектировании фактически соблюдаются теже принципы.
Тебе нравятся неоправданно сложные решения? Что ты вообще хочешь доказать?

Вот смотри: мы тут пришли к выводу, что на этапе становления юинксов, программист сам же выступал в роли заказчика тех утилит, которые он проектировал и реализовывал. Предположим, у разработчика был выбор, реализовать ему необходимый функционал в виде отдельных микроутилит типа find,ls,grep и т.д. или в виде более визуального и (на мой взгляд) удобного интерфейса по типу mc или NortonCommander. Основываясь на каких принципах (если основываясь вообще на чём-либо) был принят выбор в пользу первого варианта?

Цитата MichSpar @ 05.12.10, 14:49

Цитата D_KEY @ 05.12.10, 13:41

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

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

Я не так много встречал книг по проектированию ПО, где бы акцент делался на ОС.
Можно пример литературы по разработке ПО, которую ты читал?

Цитата

Цитата D_KEY @ 05.12.10, 13:41

У тебя каша в голове относительно вообще процессов разработки ПО.

Что-то не припомню, чтобы я тут описывал свою точку зрения на процесс разработки ПО. Ты случайно принцип с процессом не путаешь? На всякий случай внесу ясность: KISS - это принцип; принципы разработки применяются в процессе разработки.

Вот и спрашивается, с чего ты взял, что принцип проектирования может влиять на стадию анализа?

Цитата

Цитата D_KEY @ 05.12.10, 13:41

Более того, ты защищаешь ГУИ(не понятно только от кого, ведь здесь никто его не критикует), при этом не понимая, что и при его проектировании фактически соблюдаются теже принципы.
Тебе нравятся неоправданно сложные решения? Что ты вообще хочешь доказать?

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

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

Цитата

Предположим, у разработчика был выбор, реализовать ему необходимый функционал в виде отдельных микроутилит типа find,ls,grep и т.д. или в виде более визуального и (на мой взгляд) удобного интерфейса по типу mc или NortonCommander.

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

Сообщение отредактировано: D_KEY - 05.12.10, 15:15

Цитата MichSpar @ 05.12.10, 14:49

и (на мой взгляд) удобного интерфейса по типу mc или NortonCommander

Вот именно - на твой взгляд. Попробуй с помощью mc и т.п., например, выбрать в заданном каталоге и его подкаталогах все файлы содержащую фразу "http://.+/(.*).hmtl, заменить её на "http://myhost/\1.cgi", а файлы, которые не подошли под условие, переместить в /tmp, сохраняя структуру каталогов. Ну еще гвоздик - делать это надо ещё и по крону.
А уж насколько правильно mc и т.п. будут отображать свой гуй в различных терминалах доступа - бабушка надвое сказала.
Так что твои суждения об удобстве и неудобстве и проистекают то только от узости твоего виндузятного знания и твоей сферы деятельности.

Добавлено 05.12.10, 15:25
Подумай, кстати, почему даже твой обожаемый МС свой C/C++ компилятор не сделал ГУИ-шным? Поленились? И теперь бедные программисты ручкам набирают длинющие команды?

Сообщение отредактировано: Adil - 05.12.10, 16:15

Цитата D_KEY @ 05.12.10, 15:14

Можно пример литературы по разработке ПО, которую ты читал?

Конечно. Рихтер: Windows via C++, CLS via C#; Крэг Ларман: Применение UML 2.0 и шаблонов проектирования; Юров: Assembler; Прата: программирование на Си++; Танненбаум: Современные ОС (возможно тут kiss как раз упоминается, но я его ещё не всего осилил) и т.п.

Цитата D_KEY @ 05.12.10, 15:14

Вот и спрашивается, с чего ты взял, что принцип проектирования может влиять на стадию анализа?

Спрашивается, где я такое утверждал?

Цитата D_KEY @ 05.12.10, 15:14

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

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

Цитата Adil @ 05.12.10, 15:15

Вот именно - на твой взгляд. Попробуй с помощью mc и т.п., например, выбрать в заданном каталоге и его подкаталогах все файлы содержащую фразу "http://.+/(.*).hmtl, заменить её на "http://myhost/\1.cgi", а файлы, которые не подошли под условие, переместить в /tmp, сохраняя структуру каталогов. Ну еще гвоздик - делать это надо ещё и по крону.

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

Цитата Adil @ 05.12.10, 15:15

почему даже твой обожаемый МС свой C/C++ компилятор не сделал ГУИ-шным?

Для того, чтобы была возможность собрать уже готовый исходник, не загружая в память тяжёлую IDE вестимо. А что такого? Главное, что эта тяжёлая IDE aka frontend есть, и очень удобна .

Добавлено 05.12.10, 15:39

Цитата D_KEY @ 05.12.10, 15:14

И вообще, тебе знаком принцип разделения "механизма" и "политики"?

О таком не слышал.

Цитата MichSpar @ 05.12.10, 15:39

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

В скриптах то что будешь использовать - ту же "нечитабельную кашу из пайпов"?

Цитата MichSpar @ 05.12.10, 15:39

не загружая в память тяжёлую IDE вестимо

Ну и? Сам дальше додумаешься, или разжевывать?

Цитата MichSpar @ 05.12.10, 15:39

Цитата D_KEY @ 05.12.10, 15:14

Можно пример литературы по разработке ПО, которую ты читал?

Конечно. Рихтер: Windows via C++, CLS via C#; Крэг Ларман: Применение UML 2.0 и шаблонов проектирования; Юров: Assembler; Прата: программирование на Си++; Танненбаум: Современные ОС (возможно тут kiss как раз упоминается, но я его ещё не всего осилил) и т.п.

Строго говоря, из них именно по разработке ПО только одна книга(да и то не факт, я про UML), ну да ладно.
Покажешь, где Рихтер, например, рекомендует усложнять? Судя по его примерам, он как раз за то, чтобы быть как можно проще.
А то, что Таненбаума читаешь, уже хорошо

Цитата

Цитата D_KEY @ 05.12.10, 15:14

Вот и спрашивается, с чего ты взял, что принцип проектирования может влиять на стадию анализа?

Спрашивается, где я такое утверждал?

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

Цитата

Цитата D_KEY @ 05.12.10, 15:14

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

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

Даже если так, что это меняет?

Цитата

Цитата Adil @ 05.12.10, 15:15

Вот именно - на твой взгляд. Попробуй с помощью mc и т.п., например, выбрать в заданном каталоге и его подкаталогах все файлы содержащую фразу "http://.+/(.*).hmtl, заменить её на "http://myhost/\1.cgi", а файлы, которые не подошли под условие, переместить в /tmp, сохраняя структуру каталогов. Ну еще гвоздик - делать это надо ещё и по крону.

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

Интересно, а что будет в этих скриптах, если в них не будет пайпов?

Цитата

Цитата Adil @ 05.12.10, 15:15

почему даже твой обожаемый МС свой C/C++ компилятор не сделал ГУИ-шным?

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

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

Цитата

Цитата D_KEY @ 05.12.10, 15:14

И вообще, тебе знаком принцип разделения "механизма" и "политики"?

О таком не слышал.

Мне кажется у того же Таненбаума он описывался. Вот только в какой книге не помню.

Сообщение отредактировано: D_KEY - 05.12.10, 16:35