The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Линус Торвальдс занял нейтральную позицию в отношении systemd, opennews (??), 18-Сен-14, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


16. "Линус Торвальдс занял нейтральную позицию в отношении system..."  –3 +/
Сообщение от Yaisisemail (?), 18-Сен-14, 12:48 
"Еретик! Сначала ему GPL3 не нравится, теперь уже UNIX-way не тру. Linux 4.0 будет проприетарным, следуя такой тенденции."

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

21. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Аноним (-), 18-Сен-14, 12:58 
> "Еретик! Сначала ему GPL3 не нравится, теперь уже UNIX-way не тру. Linux
> 4.0 будет проприетарным, следуя такой тенденции."
> Читать надо уметь. Написано, что Unyx-подход является "не оптимальным в большинстве реальных
> ситуаций" из-за того, что он изначально подразумевает разбитие большой задачи на
> более мелкие и реализацией их по-отдельности, но если эту большую задачу
> реализовывать целиком, как единую систему, то взаимосвязь между её частями, которые
> были бы в Unyx-подходе, будет лучше учитывать все детали системы, а
> не только детали мелкой подзадачи Unyx-подхода, из-за чего результирующий продукт может
> получится эффективней, быть более производительным и меньше потреблять памяти.

Unyx? Таки UNIX! В остальном согласен, кроме "снижения потребления памяти",- в каком месте? Я бы на него не рассчитывал.

Ответить | Правка | Наверх | Cообщить модератору

178. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +2 +/
Сообщение от Аноним (-), 18-Сен-14, 23:41 
> Unyx? Таки UNIX!

Таки судя по радикализму некоторых "типа, юниксоидов" - именно "упух" :)

Ответить | Правка | Наверх | Cообщить модератору

332. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +3 +/
Сообщение от lolwut (?), 20-Сен-14, 14:24 
> Unyx? Таки UNIX!

Думаю, это таки влияние Game of Thrones.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

22. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +4 +/
Сообщение от Аноним (-), 18-Сен-14, 12:59 
>большую задачу реализовывать целиком

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

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

33. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +5 +/
Сообщение от тоже Анонимemail (ok), 18-Сен-14, 13:32 
Как раз сложную систему, реализованную на низком уровне, гораздо труднее держать в голове, чем ее высокоуровневую абстракцию. Для нее таки надо скрыть взаимосвязи нижнего уровня, не играющие роли в логике работы системы в целом.
В результате проект помещается в голове и позволяет эффективно учитывать детали, важные для системы, а не для ее низкоуровневых компонентов.

Здесь примерно как разница между ассемблером и С++: в ассемблере можно сделать оптимальную числодробилку. Но написав ее же на С++, можно обнаружить возможность оптимизации, геометрически снижающую сложность самого расчета. Сделать только реально используемые кэши, раннее обнаружение тупиковых ветвлений - на асме всю голову над такими вещами сломаешь, а в крестах объекты легко крутятся в голове, как надо.

Ответить | Правка | Наверх | Cообщить модератору

128. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +1 +/
Сообщение от rshadow (ok), 18-Сен-14, 18:52 
> Как раз сложную систему, реализованную на низком уровне, гораздо труднее держать в голове, чем ее высокоуровневую абстракцию.

Какое то масло масляное. Все сложные системы начинают писаться с нижних уровней. Далее нижние уровни собираются в высокоуровневые абстракции. Другого не придумали еще.
Вопрос не в этом, а в том что разделение необходимо во всех плоскостях. Разделять на части надо и сам код (пофайлово), и логику (функции, классы) и части скомпилированной программы (библиотеки) и сами программы (unix way).
Все больше программистов прикладных приходит в линукс, и все больше появляется софта в виде большого нераздельного куска. Даже на либа + гуй (консольный, иксовый...) не делят зачастую. И это печально. Функциональность сильно страдает. А для тех у кого мышка не основной инструмент так и совсем в пытку превращается.

Ответить | Правка | Наверх | Cообщить модератору

140. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Олег (??), 18-Сен-14, 19:27 
>Все сложные системы начинают писаться с нижних уровней. Далее нижние уровни собираются в высокоуровневые абстракции. Другого не придумали еще.

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от rshadow (ok), 18-Сен-14, 19:55 
Дело не в том что сверху вниз или снизу в верх. Дело в декомпозиции.
Ответить | Правка | Наверх | Cообщить модератору

146. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 18-Сен-14, 20:17 
Дело в управлении сложностью. Там, где при декомпозиции получается высокая связность, попытки привести к строгой идеологии юниксвея (то есть максимально исключить знание компонентов друг о друге) может произвести чудовищный оверхед из-за развесистых и неестественных надстроек над получившимися примитивами.
Половинчатый, идеологически некрасивый подход - вынос в отдельные модули только тех частей, которые действительно безболезненно изолируются от всего остального - может избавить от многих проблем "чистой" архитектуры. И программистов в том числе.
А доведенный до абсурда юникс-вей - разделение на примитивы того, что на них не делится без диких костылей - это и вовсе антипаттерн.
Ответить | Правка | Наверх | Cообщить модератору

162. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +1 +/
Сообщение от rshadow (ok), 18-Сен-14, 21:59 
> А доведенный до абсурда юникс-вей

Это все демогогия. Я еще не встречался с программами у которых юниксвей доведен до абсурда. Привидите примеры. Хотя бы несколько, распространенных программ.
Где то юниксвей не нужен, но таких задач мало. Игрушки? Возможно. Какие то большие прикладные пакеты (офис, IDE)? Уже с натяжкой.
А вот примеров наоборот, где прекрасно бы показал себя юникс вей хоть отбавляй. Все системное ПО сразу можно добавить. И большинство программ разделить на либу и гуй. Да и большие программы вполне можно, если у них не жесткий реалтайм. Небольшие потери в производительности вполне компенсируются удобством пользователям и программистам. Чье время как известно бесценно =)

Ответить | Правка | Наверх | Cообщить модератору

189. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 19-Сен-14, 00:11 
Вряд ли мне удастся вспомнить пример программ, построенных на антипаттерне и при этом получивших широкое распространение ;)
Игрушки - хороший пример среды с богатым и динамичным состоянием, поддержание которого не развалишь на отдельные, ничего друг о друге не знающие, процессы.
А примеров, где требуется вполне независимое последовательное выполнение сравнительно простых задач, действительно чрезвычайно много, так что юникс-вэй, естественно, царит, процветает и вообще должен рассматриваться как потенциальная архитектура в первую очередь.
Ответить | Правка | Наверх | Cообщить модератору

302. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от www2 (??), 19-Сен-14, 18:30 
> Вряд ли мне удастся вспомнить пример программ, построенных на антипаттерне и при
> этом получивших широкое распространение ;)
> Игрушки - хороший пример среды с богатым и динамичным состоянием, поддержание которого
> не развалишь на отдельные, ничего друг о друге не знающие, процессы.

Это плохо, если вы так думаете. Потому что производительность железа перестала расти за счёт улучшения технологических процессов и увеличения частоты. Современные игры просто НЕОБХОДИМО делить на отдельные процессы или хотя-бы потоки. Сервер доступа к игровым ресурсам, систему кэширования ресурсов, несколько рендеров сцены, консольный сервер, сетевой сервер. Когда трассировку лучей в играх начнут использовать? Воксельную графику?

То, что это никто ещё не пытался делать, говорит об имеющейся инерции мышления.

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

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

Ответить | Правка | Наверх | Cообщить модератору

330. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 20-Сен-14, 12:45 
> Современные игры просто НЕОБХОДИМО делить на отдельные процессы

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

Ответить | Правка | Наверх | Cообщить модератору

363. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Аноним (-), 20-Сен-14, 18:11 
> НЕОБХОДИМО делить на отдельные процессы или хотя-бы потоки.

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

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

180. "Линус Торвальдс занял нейтральную позицию в отношении system..."  –1 +/
Сообщение от Аноним (-), 18-Сен-14, 23:44 
> а в крестах объекты легко крутятся в голове, как надо.

Тем не менее, все что реально критично к скорости, как то кодеки, шифрование и т.п. - выписывают на асме :). Не все, ессно, а только горячие куски. И выигрыш таки получается в несколько раз, потому что то что генерит компилятор - ну вы понимаете какое это месиво.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

194. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 19-Сен-14, 00:15 
> Тем не менее, все что реально критично к скорости

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


Ответить | Правка | Наверх | Cообщить модератору

310. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Аноним (-), 20-Сен-14, 07:42 
> Кресты на высоком уровне отнюдь не исключают ассемблера на низком. Оба позволяют
> применить свои оптимизации: асм - машинные, а высокоуровневые языки - человеческие.

Кресты хороши для вещей типа игр - если есть 50 типов похожих по смыслу юнитов, с таким подходом их удастся сделать малой кровью, по сути как 1 реализация + мелкие твики. А при каком-нибудь процедурном подходе - задолбаешься. Но это все-таки надо не всем и не всегда, а такой уровень абстракций актуален для реально больших проектов (мегабайты сорцов и бинаря).


Ответить | Правка | Наверх | Cообщить модератору

331. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 20-Сен-14, 12:51 
Это не теоретическое рассуждение. Я переписывал уже оптимизированную на С задачу (NP, перебор с отходом назад) на "кресты" и только на этом уровне абстракции нашел оптимизации, позволяющие ускорить среднее время ожидания на порядок.
На микроуровне все уже было вылизано и вообще сплошь и рядом помещалось в кэш процессора.
Но на макроуровне нашлась возможность исключить куски расчета, заведомо бесперспективные, и скэшировать те куски, которые повторялись многократно.
Сведение вороха процедур к одному понятному человеку объекту здорово помогает этому человеку в понимании того, что происходит.
Ответить | Правка | Наверх | Cообщить модератору

364. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Аноним (-), 20-Сен-14, 18:14 
> перебор с отходом назад) на "кресты" и только на этом уровне
> абстракции нашел оптимизации, позволяющие ускорить среднее время ожидания на порядок.

Ну это круто и все такое. Только тоже специфичная задача.

> Сведение вороха процедур к одному понятному человеку объекту здорово помогает этому
> человеку в понимании того, что происходит.

Человеку помогает не столько сведение в объекты, сколько компактность записи которую можно окинуть взглядом. В куске ассемблера в 4 кило я могу ориентироваться как в своих 5 пальцах. А если мне 512 кило асма дать - у меня взорвется мозг, т.к. глобального view попросту не будет вообще.

Ответить | Правка | Наверх | Cообщить модератору

374. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от тоже Анонимemail (ok), 20-Сен-14, 20:03 
Сведение в объекты может увеличить объем кода.
Но при этом выделяется внешний интерфейс, который действительно имеет смысл окидывать взглядом. И убираются с глаз тонны кода, важность которого - только в том месте, где он непосредственно выполняется. Тут уже можно думать не о коде, а об архитектуре. И это здорово помогает сделать оптимальнее, гибче и безглючнее.
Ответить | Правка | Наверх | Cообщить модератору

411. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Аноним (-), 22-Сен-14, 07:28 
> Сведение в объекты может увеличить объем кода.

Может и увеличивает. Но оно по крайней мере человекочитабельное. Я видел большие проекты на асме. Это было еще ужаснее чем плюсы.

Ответить | Правка | Наверх | Cообщить модератору

34. "Линус Торвальдс занял нейтральную позицию в отношении system..."  +/
Сообщение от Mihail Zenkov (ok), 18-Сен-14, 13:34 
> если эту большую задачу реализовывать целиком, как единую систему, то взаимосвязь между её частями, которые были бы в Unyx-подходе, будет лучше учитывать все детали системы, а
> не только детали мелкой подзадачи Unyx-подхода, из-за чего результирующий продукт может
> получится эффективней, быть более производительным и меньше потреблять памяти.

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

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

Даже под виндой понимают, что модульность нужна, но там в силу закрытости и агрессивной конкуренции (невозможность/нежелание производителей ПО использовать наработки друг друга) большее распространение получили плагины.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру