The OpenNET Project / Index page

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



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

Оглавление

Выпуск systemd 219 с поддержкой расширенных возможностей Btrfs, opennews (ok), 17-Фев-15, (0) [смотреть все]

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


16. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +1 +/
Сообщение от Васёк (?), 17-Фев-15, 18:31 
Да вот тоже не пойму. Похоже на троллинг по инерции. Ну как в том мульте "Баба-Яга против", увидел про systemd статью, нужно все забрызгать, как дворовый бобик. Аргументированных комментов от хейтеров давно не читал, все сводится к "ололо поцтеринг, комбаин, ненужно" и пр. высеры. Кому они нужны - понять затрудняюсь.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +4 +/
Сообщение от Аноним (-), 17-Фев-15, 18:42 
> Да вот тоже не пойму. Похоже на троллинг по инерции. Ну как
> в том мульте "Баба-Яга против", увидел про systemd статью, нужно все
> забрызгать, как дворовый бобик. Аргументированных комментов от хейтеров давно не читал,
> все сводится к "ололо поцтеринг, комбаин, ненужно" и пр. высеры. Кому
> они нужны - понять затрудняюсь.

Гуманитарии, сэр.

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

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

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

87. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от да я же (?), 18-Фев-15, 00:34 
> Гуманитарии, сэр.
>
> Техника для них - это некая вещь в себе, которую можно постигнуть только опытным путем.

О! Технари в треде!

По моему опыту, "постигнуть только опытным путём" - как раз удел технарей. Нужно решить проблему? Да не вопрос, вот тут мы вам написали модуль, сейчас проставим галочки в настройках и он заработает. Ой, не заработал, давайте попробуем снять вот эту галочку. Не помогло, ну давайте ещё вот эту снимем, и софтинку перезагрузим, авось поможет. Помогло? Ну я не знаю, что это было, но вы впредь вседа перезагружайте - верьте мне, я же технарь! Что, всё ещё не работает? Не знаю, в чём проблема, по коду понять не смогу, сейчас в отладчик залезу, посмотрю. А, вот, почему-то memcpy не работает. Вчера, когда я проверял - работало. Студия пишет что ещё есть какая-то strcpy, тоже что-то копирует, давайте с ней попробуем. Тоже не работает? Даже и не запускается уже? Хм... Ну мне вот тут студия ещё автокомплитом memmove выдала, давайте попробуем её - на stackoverflow пишут что почему-то иногда помогает (а иногда нет), вдруг и сейчас поможет. Помогло? Ура! Сейчас юнит-тест допишу и закоммичу, после этого зарелизим официальное обновление. Хотя странно, в документации написано, что тоже копирует память, как и strcpy. Наверное, вы что-то не так делаете. Систему давно переустанавливали?

И не приведи вам случай попытаться понять, почему система тормозит, и попытаться оптимизировать её до скоростей, больших, чем написано в тз. У нас в ТЗ что написано? Что страница должна генерировать максимум за 500 миллисекунд. А генерируется за сколько? За 480? Ну так и что, что на ней только шапка и список из десяти товаров с постраничной навигацией. Ты же ТЕХНАРЬ! Технически, страница удовлетворяет заданию клиента. Что-что? Интересно, почему список из картинок и десяти строк текста генерится полсекунды со включённым кешем? А почему тебе это интересно? ГУМАНИТАРИЙ что ли, вопросы-то философские задавать? Генерится и ладно, клиент не жалуется.

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

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

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

Технарь пишет код, рассчитывая на юнит-тесты, падающие, когда он что-то делает не так, на выдаваемые компилятором предупреждения, на то, что IDE сама грамотно расставит отступы. Он лишь примерно понимает, как работает система и что делает его код (и то по большей степени лишь потому, что у него есть тесты). Гуманитарий пытается сначала понять, как работает система, какие взаимосвязи в ней есть и какие из них он может задеть при реализации задачи, и лишь потом начинает писать код. Ему доставляет удовольствие расстановка отступов вручную. Гуманитарий вбивает названия функций без помощи автодополнения, чтобы самому почувствовать, когда какая-то функция станет настолько часто используемой, что пора будет укоротить её название, заменив, скажем, writePlainMessageToLocalSystemLogFile на log. Гуманитарий понимает, что автодополнение упрощает написание кода, но не его чтение и тем более понимание.

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

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

90. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +1 +/
Сообщение от да я же (?), 18-Фев-15, 00:56 
А, и главное забыл, что касается systemd.

Технарь руководствуется логикой, а гуманитарий - здравым смыслом.

Позиция гуманитария по systemd основана на общих принципах: systemd имеет плохую архитектуру (всё завязано друг на друга), он непереносим (использует linux-специфичное), он буквально проталкивается в дистрибутивы с вытеснением (а не параллельной поддержкой) альтернатив, апстрим неадекватен.

Позиция технаря менее абстрактна: systemd решает конкретные проблемы (их перечень, как правило, прилагается), не предназначен для отличных от linux систем, а желающие альтернатив пусть сами их пилят, адекватность апстрима описывается на конкретных примерах.

Типичный пример - сборка и использование udev отдельно от systemd. Технари утверждают, что это возможно, нужно максимум написать свой Makefile и установить несколько dev-версий пакетов, не нужных для сборки самого udev (и, да, патчи апстрим не принимает). Гуманитарии же утверждают, что устанавливать для сборки udev пакеты, которые не нужны для его сборки, а используются лишь самим system - бред, и с таким же успехом можно считать, что отдельная сборка udev невозможна.

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

102. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 05:18 
Хорошо приложил! Но это скорее не гуманитарий vs технарь, а теоретик vs практик получилось.

Теоретику подавай мегаархитектуру и стройные концепции. А как оно фактически колесить по дорогам будет - теоретику вообще неинтересно. Поэтому их мегаконцептуальный хлам пылится в лучшем случае в музее политехники, а в хучшем - на помойке. Эталонный пример - minix какой-нибудь, например. Или даже что позабористее, типа paln9. Все расово верно. Концепции дypом прут! И ... даром никому не надо. Даже под пермиссивными лицензиями. Потому что недопилок с неважными рабочими параметрами. Академики фапают, остальные дружно блюют.

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

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

156. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  –1 +/
Сообщение от Аноним (-), 18-Фев-15, 20:49 
> Хорошо приложил! Но это скорее не гуманитарий vs технарь, а теоретик vs практик получилось.

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

А вот если к делу подойдет гуманитарий, у которого вместо представлений об архитектуре - религия, то каждому DE придется готовить _собственный_ suid-ный бинарник для изменений настроек, и специальный демон для отслеживания изменений. Философия юникс во все поля!

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

183. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  –2 +/
Сообщение от Аноним (-), 18-Фев-15, 23:14 
> Да не, архитектурно systemd тоже продуман.

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

> По крайней мере, по сравнению со скриптовыми костылями.

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

> то, за что отвечают, и при этом сами контролируют права клиентов
> через polkit - довольно неплохая штука.

Я правда не понимаю почему это именно "демон". Ну ладно там "task" или как там его, запускаемый единоразово. Ну там надо сменить хосту - вызвали task "сменить имя хоста" и отвалили в туман. Демон же обычно подразумевает нечто резидентное. Нафига какой-нибудь менялке имени хоста быть демоном - загадка.

> для изменений настроек, и специальный демон для отслеживания изменений. Философия юникс
> во все поля!

Да что там, тут вон кадры бочку катят на (k)dbus. Им вон sysv IPC хватает. Правда показать как через него сделать кидание неопределенной группе подписчиков сообщения вида "а вот самолетный режим - а ну, радиопередатчики, заткнитесь!" эти кадры почему-то традиционно ссыкуют. Им это видите ли не надо. Ну да, пыриться в черно-зеленый терминал можно и без этого. Ну а вот толпе народа это надо. По поводу чего эти вопящие стройными рядами пойдут на йух.

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

192. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 00:52 
> Да что там, тут вон кадры бочку катят на (k)dbus. Им вон
> sysv IPC хватает. Правда показать как через него сделать кидание неопределенной
> группе подписчиков сообщения вида "а вот самолетный режим - а ну,
> радиопередатчики, заткнитесь!" эти кадры почему-то традиционно ссыкуют. Им это видите
> ли не надо.

Совершенно верно - не надо ;)

Если мне нужно прекратить весь сетевой обмен - я выключаю сетевой интерфейс (ip link set eth0 down), а не шлю всем сетевым программам "пожалуйста, заткнитесь" с надеждой, что авторы всех программ умеют это адекватно понимать.

Логично экономить энергию и отключать непосредственно сам передатчик(и).

Возможно kdbus будет действительно полезен для каких-то определенных ситуаций. Но пока на десктопе и простой dbus не особо нужен.

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

201. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  –1 +/
Сообщение от Аноним (-), 19-Фев-15, 07:36 
> Совершенно верно - не надо ;)

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

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

> Если мне нужно прекратить весь сетевой обмен - я выключаю сетевой интерфейс
> (ip link set eth0 down), а не шлю всем сетевым программам "пожалуйста, заткнитесь"

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

При этом проводная сеть (если она у вас при этом есть) как таковая никому жить не мешает. Всем надо именно радиомолчание - чтобы заткнулись радиопередатчики. При этом никому не интересно, wi-fi там у вас, блутус, wi-max, 3G, LTE или что там еще. Лучше всего отрубить всё и сразу. И поэтому в мобильных девайсах по жизни есть под это специальный режим. Ну а почему так должно быть нельзя сделать в линухе - загадка природы. Ноут с линухом в самолете ничему не противоречит. А требования к нему такие же как и ко всем остальным.

Поэтому было бы логично если бы какой-нибудь обработчик кнопок/менюшка/команда/... дергаемые по усмотрению юзера на такую ситуацию - могли бы разослать уведомления неопределенной группе подписчиков. Потому что лично делать энумерацию всего что может излучать в вон той программе которая рисует пунктик меню "вырубить радио" - это как-то зело круто получается. Программа получится макаронным монтром. Которому придется в себя интегрить крупным оптом modem manager, network manager, bluez и еще чего-нибудь.

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

Это вы не умееете адекватно понимать существующие реалии.

> Логично экономить энергию и отключать непосредственно сам передатчик(и).

Зато...
1) Нифига не логично в крыжике настроек "а вот у нас тут сейчас самолет!" делать хардкорную энумерацию и умение рулить для вообще всех мыслимых разновидностей радиопередатчиков которые понимает линух.
2) Человек - не чип power manager, и в отличие от железки ему западло дергаться лишний раз на всякие сугубо техниеские сущности. Та что отвлекать человека на такую буиту - каменный век и мсдосовщина.
3) Если вы вдруг не заметили, при вашей пещерной "технологии энергосбережения" - отпадает линк! И если цель была именно сэкономить питание - вообще-то это нынче предпочитают делать БЕЗ потери функциональности. Спасибо, конечно, за экономию питания путем вырубания линка. А если компьютер не включать - во сколько сэкономится! Но так мало кому нравится. Поэтому предпочитают более умные варианты. С уходом проца в low power режим и/или низкие частоты, если нет активных задач. С частичным отключением неиспользуемых блоков чипов. При длительной неактивности линка наличие новых данных могут проверять лишь сильно эпизодически, променяв латенси на экономию питания. Ну и так далее. Когда и функциональность сохраняется (может быть с небольшой деградацией параметров) и питание экономится.

> на десктопе и простой dbus не особо нужен.

Мамонтам которые хотят самолично дрюкаться с управлением питанием и расстановкой перемычек IRQ на шине ISA? Их время вышло, добро пожаловать на свалку истории.

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

218. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 13:01 
del
Ответить | Правка | Наверх | Cообщить модератору

219. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 13:05 
> Ну а почему так должно быть нельзя
> сделать в линухе - загадка природы. Ноут с линухом в самолете
> ничему не противоречит. А требования к нему такие же как и
> ко всем остальным.

Так сделайте - делов на десть минут.

> Поэтому было бы логично если бы какой-нибудь обработчик кнопок/менюшка/команда/... дергаемые
> по усмотрению юзера на такую ситуацию - могли бы разослать уведомления
> неопределенной группе подписчиков. Потому что лично делать энумерацию всего что может
> излучать в вон той программе которая рисует пунктик меню "вырубить радио"
> - это как-то зело круто получается. Программа получится макаронным монтром. Которому
> придется в себя интегрить крупным оптом modem manager, network manager, bluez
> и еще чего-нибудь.

Вы создаете сложности на ровном месте - ваш любимый андроид в этом режиме полностью гасит сетевые интерфейсы (adb shell ifconfig в помощь) и питание на них.

>> Логично экономить энергию и отключать непосредственно сам передатчик(и).
> Зато...
> 1) Нифига не логично в крыжике настроек "а вот у нас тут
> сейчас самолет!" делать хардкорную энумерацию и умение рулить для вообще всех
> мыслимых разновидностей радиопередатчиков которые понимает линух.

И что характерно их всех можно определить заглянув в /dev или /sys. Элементарный скрипт в помощь.

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

226. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 19:28 
> Так сделайте - делов на десть минут.

В человеческом виде делов несколько побольше. А программе крыжика "самолетный режим" совершенно не в кассу узнавать как рулить вот конкретно тем 3G свистком, например. Этот свисток - вообще может не сетевой интерфейс быть! А какой-нибудь AT-командовый модем, или даже что позаковыристее.

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

> режиме полностью гасит сетевые интерфейсы (adb shell ifconfig в помощь) и
> питание на них.

Андроид много чего по своему делает. И если что, там еще и свой самопальный IPC есть, кстати. Если вы вдруг не заметили - гугель вполне убедительно помахал факом. И в сторону имевшегося IPC, запилив свое, более подходящее для их целей, и в сторону окаменелостй типа иксов. Сделав свой вывод графики. И вообще-то когда людям такие вещи приходится делать где-то out of tree и местечково - это не есть нормально нифига. А кто считает иначе - здорово оторвался от реалий и шел бы он куда подальше, ибо ведет к дезинтеграции и вылету на задворки истории. По причине "неактуальная фигня не от мира сего, которую проще списать в утиль чем закостылить до кондиции".

> И что характерно их всех можно определить заглянув в /dev или /sys.

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

> Элементарный скрипт в помощь.

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

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

227. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 20:23 
> И что характерно, большинство людей труба шатали самолично костылировать столько хлама.

Так гугол в помощь - наверняка кто-то уже озадачился и написал. Если нет - могу написать для вас, за цену билета на самолет ;)

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

То, что предлагаете вы - это попытка создать все на все случае жизни, что на практике порождает больше проблем, чем решает их. Не говоря уж об overkill/overhead/overengineering.

Ваше предложение - программа посылающая сообщение о необходимости прекращения передачи радиосигнала. Потенциально я вижу следующие вопросы:
1. Кто будет определять формат сообщений?
2. Как убедить всех использовать единый формат сообщений?
3. Что делать с программами не умеющих/не желающих/игнорирующих сообщения?
4. Что делать если программ запущенна после прохождения сообщения?
5. Что будет если несколько программ попытаются выключить/включить один и тот же интерфейс?
6. Потребление памяти и усложнение программ - им всем придется уметь принимать сообщения и корректно их обрабатывать.
7. Сколько понадобится человеко-часов на внедрение и отладку этого?

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

230. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 22:11 
> Так гугол в помощь - наверняка кто-то уже озадачился и написал. Если
> нет - могу написать для вас, за цену билета на самолет ;)

Вы там вообще в своем уме? Нафига я буду возиться с тем что вообще должно работать по дефолту, т.к. обыденный и повсеместный сценарий? И тем более - за что платить вам? Это ж не кастомдев, это - СТАНДАРТНАЯ хотелка, типичная для *легиона* юзерей. Прикиньте?

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

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

Единственная проблема: постановка задачи отморожена на всю голову и являет собой образец квадратно-гнездового мышления имени мсдоса. Если я сажусь в самолет, последнее о чем я хочу думать в этот момент - какие же там в этом девайсе классы беспроводных устройств?! Есть четко поставленная задача: ВСЕ РАДИО ДОЛЖНЫ ЗАТКНУТЬСЯ. Вот это - нормальная человеческая постановка задачи. С понятной мотивацией (чтобы не было шанса создать помехи навигационному оборудованию) и логичной реализацией через нечто типа системной шины.

А то что вы предлагаете - эталонный образец ДОСявого однозадачного однопроцессного мышления: перехватить контроль над девайсом единолично из 1 приблуды и вообще никак не согласовывать с другим софтом использование этого девайса. Арбитраж? Использование более чем 1 программой? Не, не слышали! Вот поэтому и мамонты, собственно...

> То, что предлагаете вы - это попытка создать все на все случае жизни,

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

> говоря уж об overkill/overhead/overengineering.

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

> 1. Кто будет определять формат сообщений?

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

И кстати d-bus как таковой появился в том числе и для того чтобы програмеры не сношали себе мозг низкоуровневой формировкой пакетов. Мало кто коммуницирует с сервером, например, опеннетом, самолично выкраивая все кадры эзернета в своей программе.

> 2. Как убедить всех использовать единый формат сообщений?

В жестком виде ессно никак. А по факту какая-то из реализаций станет стандартом де-факто, основная масса софта это станет понимать. А как там особо хитрый мамонт будет дрoчить сетевым интерфейсом туда-сюда потому что это в его понимании и есть power management, это уже проблемы этого мамонта (варианты для этого всегда найдутся). Ну то-есть вы можете любить IPX хоть до поросячьего визга. Но послать пакеты мне по нему не сможете. Потому что я и промежуточные роутеры его не понимаем. Будете пользоваться TCP/IP и HTTP. Или пойдете нафиг. На выбор. Но разумется приказать вам использовать именно TCP/IP и HTTP никто не может. Просто вы будете взаимодействовать только сами с собой, если перестаратетесь с кастомом.

> 3. Что делать с программами не умеющих/не желающих/игнорирующих сообщения?

Ничего. Если кому-то станет это надо - они пойдут и сделают так чтобы умели и не игнорировали. А на нет и суда нет.

> 4. Что делать если программ запущенна после прохождения сообщения?

А это как с IRC. Вы присоединились к каналу. Но сообщения уже пролетели. Что делать? А ничего. Если это что-то критичное - ну давать по сусалам на потуги например врубить вафлю в самолете. Т.е. пока самолетный режим явно не снят - фиг вам а не вафля.

> 5. Что будет если несколько программ попытаются выключить/включить один и тот же
> интерфейс?

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

> 6. Потребление памяти и усложнение программ - им всем придется уметь принимать
> сообщения и корректно их обрабатывать.

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

> 7. Сколько понадобится человеко-часов на внедрение и отладку этого?

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

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

222. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 13:40 
>[оверквотинг удален]
> отпадает линк! И если цель была именно сэкономить питание - вообще-то
> это нынче предпочитают делать БЕЗ потери функциональности. Спасибо, конечно, за экономию
> питания путем вырубания линка. А если компьютер не включать - во
> сколько сэкономится! Но так мало кому нравится. Поэтому предпочитают более умные
> варианты. С уходом проца в low power режим и/или низкие частоты,
> если нет активных задач. С частичным отключением неиспользуемых блоков чипов. При
> длительной неактивности линка наличие новых данных могут проверять лишь сильно эпизодически,
> променяв латенси на экономию питания. Ну и так далее. Когда и
> функциональность сохраняется (может быть с небольшой деградацией параметров) и питание
> экономится.

Ну раз вы так хорошо разбираетесь в энергосбережении и вообще прогрессивный человек - элементарная задача: есть ноутбук с линуксом - нужно поднимать wi-fi только тогда, когда идут сетевые пакеты. У "мамонта" эта задача решена.

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

229. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 21:30 
> - элементарная задача: есть ноутбук с линуксом - нужно поднимать wi-fi
> только тогда, когда идут сетевые пакеты. У "мамонта" эта задача решена.

Во первых, сама постановка задачи - некорректная. Ну нет у нормальных людей в здравом уме и твердой памяти такой задачи как "дрoчить сетевой интерфейс". Это кусок бреда, а не целеполагание. Изначальная цель у нормального инженера может звучать как нечто типа "сэкономить питание" (а у юзера - "чтоб подольше работало"). И решают такую задачу, соответственно, намного менее извращенскими и кривыми методами. С намного меньшим мозготрахом пользователю.

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

Если вы думаете что изгибаться такой буквой зю для использования сети кого-то радует - вы чего-то очень сильно не понимаете в этой жизни. Грубо говоря, вы придумали себе высосанную из пальца проблему, с помпой ее решили, и почему-то считаете что это решение еще и имеет какую-то очевидную всем ценность. А на самом деле это как забег по потолку в ластах и противогазе с аргументом "во как я могу!". Ну, ок, вы можете бегать в ластах и противогазе по потолку. И чего? Этот скилл несет в себе какую-то практическую ценность?

Нормальные инженеры, к вашему сведению, давно сделали для вафли "power save". Так что дрюкать интерфейс для экономии питания отнюдь не требуется. А современные чипы, между прочим, даже в активном режиме кушают столько что не то что вайфай, а все вместе, включая проц на 400-500 мегагерц с линухом - запросто пашет чуть ли не целый день от обычной батареечки типа 18650, упакованой прям в корпус карманного девайса. На фоне того как это работает, сколько лопает, сколько усилий в настройке требует, какие скорости и латенси и прочая - вы с вашими извращениями и выглядите мамонтом, если вы еще не поняли.

P.S. и да, я совсем не против автоматики под какие-то сильно кастомные запросы. Но, опять же, ваша автоматика - не интегряется с другими случаями. Например с случаем "эй, радио, заткнсь, это - самолет!". А самолично выписывать все такие моменты в скриптах можно и за..ться.

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

193. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 00:57 
> А вот если к делу подойдет гуманитарий, у которого вместо представлений об
> архитектуре - религия, то каждому DE придется готовить _собственный_ suid-ный бинарник
> для изменений настроек, и специальный демон для отслеживания изменений. Философия юникс
> во все поля!

Не, демонология - это к Поттерингу, это его любимая концепция - все демон. Нормальные люди используют inotify.

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

202. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 07:44 
Рассказ о нормах жизни от человека, считающего что нагружать гуманоидов управлением питания линка нормально - спасибо, но...
Ответить | Правка | Наверх | Cообщить модератору

220. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Mihail Zenkov (ok), 19-Фев-15, 13:14 
> Рассказ о нормах жизни от человека, считающего что нагружать гуманоидов управлением питания
> линка нормально - спасибо, но...

Человек, считающий что управление линком должно быть в одном месте (скрипт/программа), а не в десятках отдельных приложений ждущих сообщений.

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

231. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 22:20 
> Человек, считающий что управление линком должно быть в одном месте (скрипт/программа),
> а не в десятках отдельных приложений ждущих сообщений.

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

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

224. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +1 +/
Сообщение от Аноним (-), 19-Фев-15, 15:44 
> А практику плевать что там в архитектуре, лишь бы из пункта А
> в пункт Б доставляло за оговоренное время. А если при этом
> еще салон комфортабельный и кондей работает - вообще замечательно. А то
> что ДВСина этой штуки - клубок проводов и трубок, куча вспомогательных
> агрегатов, какие-то костыли-микропроцессоры и прочая, так что оно ни разу не
> похоже на простую и доходчивую модель из кабинета физики - да
> всем похрен. Лишь бы колеса крутило.

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

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

232. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 22:22 
> ...правда спустя некоторое время этот "практик" внезапно обнаруживает что доставляют его
> уже за то время которое удобно владельцу этого агрегата, той дорогой,
> которая удобна владельцу,

Несомненно, мир неидеален. Проблема только в одном: в вашем случае придется идти пешком. Что может быть очень несколько непрактично при расстоянии больше чем несколько километров и совсем не вариант если по пути попадется какой-нибудь там океан (коих у нас 2/3 планеты, блин).

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

130. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Товарищ Майор (?), 18-Фев-15, 12:11 
эм... а причем тут гуманитарии? вы, таки про разные подходы с не совсем адекватными примерами. и никак не про технарей-гуманитариев.
Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

161. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 21:08 
> эм... а причем тут гуманитарии? вы, таки про разные подходы с не
> совсем адекватными примерами. и никак не про технарей-гуманитариев.

Похоже, вы чувствуете, что "наших бьют", но возразить ничего не можете :)

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

23. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +4 +/
Сообщение от Аноним (-), 17-Фев-15, 18:47 
Аргументы?

https://bugzilla.redhat.com/show_bug.cgi?id=719952

Багрепорту четвёртый год уже пошёл, а он до сих пор открыт.
We change! We create! We propose! The future will be awesome! Btrfs! Kdbus! Containers! Snapshots! Oh, wait, what's that? Bugreport? Not our business! Systemd!

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

26. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  –1 +/
Сообщение от Аноним (-), 17-Фев-15, 18:49 
> https://bugzilla.redhat.com/show_bug.cgi?id=719952

Если вы решили перезагрузиться во время fsck, то зависание - не самая страшная из ваших проблем :)

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

30. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +4 +/
Сообщение от Аноним (-), 17-Фев-15, 18:52 
Изначально проблема была в том, что systemd-fsck не интерраптится вручную практически никак. Пришёл я, например, презентацию перед большой аудиторией показать, включил ноутбук, а systemd-fsck решил, что ему всенепременно надо прочекать диск. И всё, приехали.
Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +2 +/
Сообщение от 3 (?), 17-Фев-15, 20:19 
нет системд - нет проблем...
Ответить | Правка | Наверх | Cообщить модератору

209. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 08:24 
> нет системд - нет проблем...

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

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

208. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 19-Фев-15, 08:22 
> Изначально проблема была в том, что systemd-fsck не интерраптится вручную практически никак.

И что характерно, root cause - в том что корректное прерывание fsck в нем элементарно не предусмотрено. А вырубить его некорректно - можно с разваленной файлухой остаться. Ясен фиг никто в здравом уме не подпишется такое делать. Что в багтрекере и написали.

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

103. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 05:28 
> Аргументы?
> https://bugzilla.redhat.com/show_bug.cgi?id=719952

Да, забойный аргумент: последняя запись в баге была более 2 лет назад, в том числе дуп этого бага. Видимо с тех пор 2 года как всем пофигу. Ну раз пофигу - так зачем чинить? :)

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

140. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от путещщ (?), 18-Фев-15, 19:41 
http://cgit.freedesktop.org/systemd/systemd/commit/?id=07f9a...

Не оно?

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

83. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 17-Фев-15, 23:37 
> Да вот тоже не пойму. Похоже на троллинг по инерции. Ну как
> в том мульте "Баба-Яга против", увидел про systemd статью, нужно все
> забрызгать, как дворовый бобик. Аргументированных комментов от хейтеров давно не читал,
> все сводится к "ололо поцтеринг, комбаин, ненужно" и пр. высеры. Кому
> они нужны - понять затрудняюсь.

Ну так аргументированных постов от сторонников столько же. Ня, прогресс.

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

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

104. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 05:29 
> критичными для разных нелюбителей systemd.

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

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

121. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +1 +/
Сообщение от Аноним (-), 18-Фев-15, 10:03 
А _что_ содержательного можно добавить в баг, если upstream уже сказал «нам наплевать, мы ничего полезного делать не будем по этому поводу» или даже «круто, мы и хотели это сломать»?

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

136. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +1 +/
Сообщение от Аноним (-), 18-Фев-15, 14:36 
Узнаю стиль Портера :) он так же отвечал - когда Pulse audio сломал alsa/oss. "пусть все работают через пульсаудио - а остальное никому не надо". За столько лет ничего не поменялось.
Ответить | Правка | Наверх | Cообщить модератору

164. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 21:12 
> Узнаю стиль Портера :) он так же отвечал - когда Pulse audio
> сломал alsa/oss. "пусть все работают через пульсаудио - а остальное никому
> не надо".

Это когда такое было? Опять все выдумываем?

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

144. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 20:21 
> А _что_ содержательного можно добавить в баг, если upstream уже сказал «нам
> наплевать, мы ничего полезного делать не будем

Да нет, они уже буквально несколько часов назад запилили systemd-fsckd, позволяющий останавливать процессы fsck независимо от их количества.
Пруф: http://cgit.freedesktop.org/systemd/systemd/commit/?id=07f9a...

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

254. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 21-Фев-15, 17:40 
> Да нет, они уже буквально несколько часов назад запилили systemd-fsckd, позволяющий останавливать

Оперативно работают :)

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

184. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 23:20 
> А _что_ содержательного можно добавить в баг,

Как минимум, если бы это мешало жить толпе народа - были бы дупы багов. Но дуп был лишь 1. И 2 года назад. Видать, фича не слишком мешает жить юзерям...

> если upstream уже сказал «нам наплевать, мы ничего полезного делать не будем
> по этому поводу» или даже «круто, мы и хотели это сломать»?

Не вижу где там написано именно это. Там написано что fsck как таковой нынче не предусматривает возможности его корректно вырубить. Поэтому мы дескать понятия не имеем как это надо делать. Не надо быть семи пядей во лбу чтобы догадаться что разработчики системного стартера не подпишутся брутально срубать fsck, потенциально оставляя юзера с убитой в хламину ФС. А корректных методов это сделать просто нет. И вопросы при этом надо по логике задать авторам fsck'ов для начала. Ну так, если делать это по уму.

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

148. "Выпуск systemd 219 с поддержкой расширенных возможностей Btr..."  +/
Сообщение от Аноним (-), 18-Фев-15, 20:31 
> Ну так аргументированных постов от сторонников столько же. Ня, прогресс.

Сторонники systemd - звери редкие. Можно выделить три класса линуксоидов:
1. "systemd так systemd, освоимся, делов-то".
2. "ААА НЕНАВИСТЬ НЕНАВИСТЬ УБИТЬ ПОЦТЕРА!!!!1"
3. "Ммм, хейтеры - это отличная еда!"

:)

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

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

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




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

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