The OpenNET Project / Index page

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

Эксперимент с CPU Intel позволил на 40 процентов снизить энергопотребление в Linux

28.04.2015 12:41

Мэттью Гаррет, известный разработчик ядра Linux и лауреат премии за вклад в развитие свободного ПО, опубликовал результаты эксперимента по задействованию в Linux новых механизмов экономии энергии, появившихся в процессорах Intel серии Haswell и Broadwell. Результат превзошел все ожидания и показал плачевное состояние с работой по оптимизации энергопотребления в Linux. В частности, потребление энергии удалось снизить с 8.5 до 5 Ватт, что значительно продлило время автономной работы системы от заряда аккумулятора.

Причиной выявленных проблем является то, что CPU Haswell и Broadwell не переходят в глубокие режимы энергосбережения, если в активном состоянии находится хотя бы одна из интегрированных подсистем, таких как CPU, GPU и PCH (Platform Controller Hub). PCH обеспечивает работу систем ввода/вывода, в том числе USB и SATA. В Linux по умолчанию отключено использование механизмов снижения энергопотребления для SATA, т.е. интерфейс SATA всегда находится в активном состоянии, что не даёт процессору активировать глубокий режим энергосбережения и сохраняет питание многих частей CPU, потребность в которых отсутствует. Похожее поведение наблюдается и в Windows, но большинство производителей оборудования поставляют в данной ОС дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления.

Для решения проблемы для ядра Linux предложен небольшой патч, который извлекает настройки прошивки на стадии загрузки ядра и добавляет две новые политики энергопотребления: первая на основе выдаваемой прошивкой конфигурации и вторая, повторяющая настройки в драйвере Intel. Использование данных политик позволило при неактивности системы снизить потребление энергии на несколько ватт за счёт того, что изменение состояния линка SATA дало возможность добиться включения режима PC7 вместо PC2.

При этом исследование ещё не закончено, так как предстоит учесть влияние на выбор режимов энегосбережения состояния других компонентов, в частности, GPU. Например, активность экрана приводит не только к затратам энергии на его работу, но и к нахождению во включенном состоянии дополнительных компонентов чипсета. В спецификации Embedded Displayport 1.3 определён интерфейс Panel Self-Refresh, позволяющий согласовать отключение линка с GPU, сохранив при этом содержимое экрана. Патчи для включения подобного режима уже подготовлены для систем Intel, но пока не включены по умолчанию.

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

  1. Главная ссылка к новости (http://mjg59.dreamwidth.org/34...)
  2. OpenNews: В обновлениях ядра Linux 3.0.20 и 3.2.5 устранены проблемы с повышенным энергопотреблением
  3. OpenNews: Патч для решения проблемы с повышенным энергопотреблением Linux на некоторых ноутбуках
  4. OpenNews: Выявлены новые проблемы с установкой Linux на оборудовании, поставляемом с Windows 8
  5. OpenNews: Раскрыты причины блокирования работы UEFI-прошивки ноутбуков Samsung
  6. OpenNews: Проблемы с ноутбуками Samsung не исчерпаны после выпуска обновлений ядра Linux
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/42119-power
Ключевые слова: power, linux
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (94) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Макс (??), 13:55, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Марк должен исправить ситуацию в своём дистрибутиве.
     
     
  • 2.72, Анончег (?), 03:59, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Примерно вот так он должен исправить...

    > Мэтью Гаррет, известный разработчик ядра Linux и лауреат премии за вклад в развитие свободного ПО, опубликовал результаты эксперимента по задействованию в Linux новых механизмов экономии энергии, появившихся в процессорах Intel серии Haswell и Broadwell. Результат превзошел все ожидания -- [b]ПРОЦЕССОР НАЧАЛ ОТДАВАТь ЭНЕРГИЮ ОБРАТНО В СЕТь, НА ОДНОМ ИЗ НОУТБУКОВ ДАЖЕ ВЗДУЛО БАТАРЕЮ !!![/b]

     
  • 2.73, Анончег (?), 04:04, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проклятые проприерасы успели таки обогнать и Мэтью, и Марка, и стратегических он... большой текст свёрнут, показать
     
     
  • 3.88, Lilian (?), 20:35, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > стратегических онолитегов с опеннета:

    Сперва прочитал как "стратегических олигофренов". Очень лол!

     
  • 2.76, Анончег (?), 04:07, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Проблемным также остаётся вопрос доведения всех доступных средств энергосбережения до пользователей. Компания Intel обеспечила в ядре поддержку всех возможностей управления питанием для своих систем, но данные возможности лежат мёртвым грузом и остаются неактивированными. Задача применения данных возможностей и выбора оптимальной политики энергопотребления ложится на дистрибутивы, которые не спешат что-то менять и склоняются к использованию консервативных универсальных настроек, не учитывающих возможность дополнительной оптимизации для отдельных систем.

    Виноваты проприерасы и лично Путен, тут даже сам Марк бессилен что либо сделать !

     

  • 1.2, Аноним (-), 13:57, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждем какой-нибудь ЦианогенМодОС ...
     
     
  • 2.7, Аноним (-), 14:17, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Зачем ждать, если она уже есть?
     
  • 2.16, Аноним (-), 15:11, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    вы "изобрели" Tizen, поздравляю :)
    который(помимо прочих корпораций) пилит и intel. так что оная фича  будет и там.
    а если надо чтонить "потоньше и без html5 софтин", то всегда есть форки sailfish или bada(развитие которого замедлено, но не остановлено).
     
     
  • 3.43, Аноним (-), 17:14, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Покажи мне форк Sailfish.
     
     
  • 4.45, Аноним (-), 17:29, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    "knowledge itself is power" (c) F. Bacon.
     
  • 4.50, Аноним (-), 18:09, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У закрытых программ не бывает форков (почти)
     
  • 2.21, Аноним (-), 15:34, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://cyngn.com/cyanogen-os
     
     
  • 3.54, Аноним (-), 18:43, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > https://cyngn.com/cyanogen-os

    Это там где с микрософтовскими зондами то?

     

  • 1.3, L29Ah (?), 14:03, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Почему последний абзац без пруфлинка?
     
     
  • 2.4, ano (??), 14:09, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    потому что опеннет - не вики. ваш кэп.
     

  • 1.5, Макс (??), 14:09, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Это как c Kdbus. Не пускают его пока в Mainline Kernel. Так и эти патчи.
    В 4.1 ядре будет много новинок и изменений, так чего бы не впихуть было уже в этот релиз терминаторский.
     
     
  • 2.9, Аноним (-), 14:22, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Да, нужно увеличивать время автономной работы. А то что за терминатор, если за два часа батарейка сядет?
     
     
  • 3.23, pkdr (ok), 15:44, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Обычный андроид.
     
     
  • 4.92, plain5ence (ok), 14:50, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Андроид на хасвеле или бродвеле - это далеко не обычный андроид...
     
  • 2.15, Аноним (-), 15:08, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Вот, кстати, почему его не пускают в ядро: https://news.ycombinator.com/item?id=9450806

    > No Greg. Just remove the shit. Really.
    >
    > We don't add crap that then has to be disabled with secuirity rules just because it was a bad interface. Just make the interface not do it in the first place. It's that simple.
    >
    > My guess is that pretty much the entirely of the quoted kdbus "speedup" isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.
    > So really. The people who talk about how kdbus improves performance are just full of sh*t. © Linus
    > Anyways. "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex".

     
     
  • 3.24, Макс (??), 16:02, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • –7 +/
    А по-рууски
     
     
  • 4.29, rob pike (?), 16:22, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Потому что shit.

    А вот что интересней - это почему оно shit. Не только потому что имплементация отвратительного качества.

    >KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.

     
     
  • 5.32, Аноним (-), 16:31, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > KDBus was designed with sandboxed applications in mind. <...> without leaking information about the system.

    Отвечу цитатой Линуса:

    > So the whole "capabilities and user information" is really to me a non-issue. It's clearly required information, and if you don't want to expose it, you damn well have absolutely *zero* business talking to system daemons.

     
     
  • 6.44, rob pike (?), 17:23, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Последнее предложение Линус забыл аргументировать
     
     
  • 7.78, Аноним (-), 04:48, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Линус себя всегда аргументацией не утруждал и формальной логикой. "потому что!" его все.
    возможно, иначе бы какие-то неочевидные для нас всех, мотивы - были виднее.
     
     
  • 8.95, гость (?), 16:59, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Верно подмечено Но печально не это, а количество людей, которые считают нормой ... текст свёрнут, показать
     
     
  • 9.102, Михрютка (ok), 11:44, 01/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ЩЬТО за что люблю опеннет за незамутненность некоторых комментаторов Линус типа... текст свёрнут, показать
     
  • 3.65, Михрютка (ok), 21:27, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот, кстати, почему его не пускают в ядро: https://news.ycombinator.com/item?id=9450806
    >> No Greg. Just remove the shit. Really.
    >>

    ыхыхых

    http://article.gmane.org/gmane.linux.kernel/1930426

    > You don't have to enable the metadata if you don't want to use it, it's
    > an option :)

    OK, _that_ argument needs to be stomped out.  It had been used before,
    and it was a deliberate scam.  There is no such thing as optional kernel
    interface, especially when udev/dbus/systemd crowd is nearby.

    Ал Виро няша <s>я хочу от него ребенка</s>

     
  • 3.66, rob pike (?), 22:11, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When I read that, a big light bulb turned on in my head about what the actual problem is here.
     

  • 1.6, iPony (?), 14:09, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Довольно не простая задача, учитывая разношёрстность железа. К тому же малое время автономной работы - это такая вещь второстепенная, хоть и неприятная, но не ошибка же и не сразу бросается в глаза пользователю, а значит и разработчиков есть соблазн это проигнорировать.
    Тут конечно всякие macbook'и выигрывают в автономности в виду чёткого подпиливания ОС под конкретное железо.
     
     
  • 2.8, Аноним (-), 14:21, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Пользователю как раз таки бросается в первую очередь. Так приятно когда твой свеженький ноут живет под виндой 5 часов, а под линуксом 3 не вытягивает. Я даже боюсь представить какая разница будет на макбуке с MacOS и линуксом
     
     
  • 3.11, Святоша (?), 14:50, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот ровно наоборот ситуацию наблюдал на нетбуке Samsung N130... под виндой новый шесть-семь часов тянул, под линуксом 8-9
     
     
  • 4.47, Аноним (-), 17:41, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Установи "дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления" и в винде будет 10-12 часов. Неужели так сложно внимательно прочитать новость и сделать логические выводы?
     
     
  • 5.55, Аноним (-), 18:56, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Установи "дополнительный AHCI-драйвер компании Intel,

    ЧСХ, большинство пользователей кладут на это с прибором.

     
  • 3.13, iPony (?), 14:58, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кэп, я же написал "в сравнении". Сравни, например, если у тебя дистрибутив валится с ошибками будет или мало от батареи работать будет. Но и само собой и автономность важна.
     
  • 3.19, денис (??), 15:32, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    стоковая убунта 14.10 на прошке 11 года по датчикам в панеле жила где-то на час меньше osx


    т.е. где-то 5-6 часов против 6-7, а кинцо смотреть так и дольше выходило почему-то

     
     
  • 4.26, iPony (?), 16:07, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    смотря в чём смотрел кино, vlc этак только в версии 2.2 сделали нормальное декодирование видео
     
     
  • 5.56, Аноним (-), 18:58, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > смотря в чём смотрел кино, vlc этак только в версии 2.2 сделали
    > нормальное декодирование видео

    Лично мой ноут в убунте спокойно тянет часов 7 с гаком если браузить и т.п. не слишком активные нагрузки. В винде он работает даже меньше чем в убунте. Правда там более древний проц и ему эти улучшенные режимы не грозят.

     

  • 1.10, Аноним (-), 14:47, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    На моем двухгодовалом 13" макбуке макос - 9,5ч., убунту 14.04.1 - 4,5ч.
     
     
  • 2.14, iPony (?), 15:07, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > На моем двухгодовалом 13" макбуке макос - 9,5ч., убунту 14.04.1 - 4,5ч.

    Есть ещё один нюанс. С видеосистемой тоже негладко. Например на OS X браузеры (safari, chrome, opera) умеют аппаратно декодировать видео, а на линуксе такого нет. Если смотришь котят на ютюбчике, то батарея сильнее будет разряжаться под линуксом нежели в OS X.

     
     
  • 3.18, Макс (??), 15:25, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так 2015 год. Когда ж уже научится линукс такому? Успевают люди новые вещи делать со всеми ништяками, а линуксу треть века почти, а все еще в древности.
     
     
  • 4.70, freehck (ok), 02:36, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А Вы на список браузеров посмотрите сначала, а потом ответьте себе на вопрос: это точно Linux виноват?
     
     
  • 5.74, iPony (?), 04:04, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    При чём тут это? Я написал список браузеров, которые под OS X поддерживают GPU декодирование, под линуксом этот нулевой.
     
     
  • 6.79, Аноним (-), 04:54, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > При чём тут это? Я написал список браузеров, которые под OS X
    > поддерживают GPU декодирование, под линуксом этот нулевой.

    ну, ситуация когда конкретный юзверь полагает что "под линуксом список браузеров с оффлоадингом рендеренга на GPU - нулевой" - не вина Линукса или браузеров(в тч с оного, поддержкой).
    потому отчасти, что юзанье оного - предполагает неслабую мантру RTFM, перед.
    ибо 4 разных интерфейса этого декодирования, три разных вендора GPU(каждый со своими тараканами в реализации каждого) в отличие от однородной "MacOS"-и где все прибито гвоздями и анально прозондированно. настолько, что даже гугль по-дефолту выключает в хроме(и намерен - впредь)оное в браузере.
    с приходом Vulkan - оно наверное станет более хомячково-френдли. наверное. но не факт.

     
     
  • 7.81, soarin (ok), 05:27, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пруф заведения GPU декодирования видео на nvidia карте хоть в каком-нибудь браузере под линуксом, пожалуйста.
    Про гугль враньё, они в начале этого года запилили GPU декодирование видео под OS X. Разве что до стабильной версии вот неуверен что ещё дошло. Проверял - работает. https://code.google.com/p/chromium/issues/detail?id=133828
     
     
  • 8.89, Аноним (-), 06:39, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    нудк для OSX запилили, а под Linux - выпилили и выключенным намерены оставлять и... текст свёрнут, показать
     
  • 8.98, SPRog (?), 19:09, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сойдет firefox gstreamer http www opennet ru opennews art shtml num 33651 ... текст свёрнут, показать
     
     
  • 9.103, soarin (ok), 14:08, 01/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не сойдёт - это теория, которую я и так знаю Реальный тест HTML5 видео этак 4K ... текст свёрнут, показать
     
  • 7.82, iPony (?), 08:16, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Собственно говоря вот такой RTFM:
    Под chromium c vdpau вообще дохлый номер.
    Под фурифокс вроде как что-то есть, но только этак с GStreamer-vaapi версии 0.5.9 и старше (он, например, не успел войти в ubuntu 14.04 LTS). Для vdpau ещё надо впендюривать прослойку vdpau-va-driver. Как это всё в реальности работает (плохо/хорошо) - без понятия, не пробовал, ибо сижу как раз на ubuntu 14.04. Например, VLC просто отвратительно работал через vdpau-va-driver, пока в VLC 2.2 не сделали прямую поддержку VDPAU.
     
  • 5.77, iPony (?), 04:12, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > это точно Linux виноват?

    Ну и для пользователя неинтересно, кто именно виноват из цепочки (разработчики ядра или видеосистемы или браузера или ещё кто), для него есть результат, что не работает, и в конечно счёте для него виноват линукс.

     
     
  • 6.80, Аноним (-), 04:55, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> это точно Linux виноват?
    > Ну и для пользователя неинтересно, кто именно виноват из цепочки (разработчики ядра
    > или видеосистемы или браузера или ещё кто), для него есть результат,
    > что не работает, и в конечно счёте для него виноват линукс.

    на Linux, где "пользование" самой ОС, включая ее установку нередко или конфигурирование - предполагают действия и знания, выходящие ДАЛЕКО за описанные пределы - отнюдь.

     
  • 3.37, xaxaxa (?), 16:53, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • –4 +/
    ты хочещ чтобы йутубчик к железу доступ имел?молодеееец
     
     
  • 4.57, Аноним (-), 18:59, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ты хочещ чтобы йутубчик к железу доступ имел?

    Он и так имеет доступ к железу - к монитору. Если кроме него будет еще и видеодекодер - это наверное не так уж страшно.

     
  • 4.59, Аноним (-), 19:06, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Стесняюсь спросить - вам браузер картинки через либастрал передает или прямо в /dev/crystal_ball выводит?
     
     
  • 5.84, Lain_13 (ok), 14:40, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то /dev/crystal_ball это тоже «железо».
     
  • 3.58, Аноним (-), 19:00, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть ещё один нюанс. С видеосистемой тоже негладко. Например на OS X

    Например в OS X OpenGL реализован в такое сpaное гoвно, что его делает НА ТОМ ЖЕ ЖЕЛЕЗЕ опенсорсная MESA.

     
     
  • 4.75, soarin (ok), 04:06, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не то самое, но да, более медленное, но к тебе энергосбережения это совсем не относится.
     

  • 1.12, devl547 (ok), 14:54, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >Эксперимент с CPU Intel позволил на 40 процентов снизить энергопотребление в Linux

    ...в режиме простоя.

    Насколько я понимаю, тот же эффект достигался вручную:

    /etc/udev/rules.d/hd_power_save.rules
    ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"

     
  • 1.17, Аноним (-), 15:12, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    О чем можно говорить?... Когда даже управление частотами реализовано не полностью. В Windows 1.15 > 1.2 > .. Linux даже не в курсе что есть режим с 1.15 Ггц, показывает только 1.2 и выше. Разгон происходит обрывками.... Называется "все реализовано"
     
     
  • 2.67, Аноним (-), 22:55, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я тебя удивлю дорогой спец, управление частотой и электропитанием это  ACPI  и ты можешь его патчить, если то что в железе тебя не устраивает. Хотя нет, ты не можешь.
     
  • 2.69, Аноним (-), 01:53, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Большая часть таких проблем называется мы забили на стандарты - лишь бы рабо... большой текст свёрнут, показать
     
     
  • 3.71, Perl_Jam (?), 03:42, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    вы абсолютно правы. к сожалению.
     
     
  • 4.90, клоуны (?), 13:17, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Думаешь? Если бы всё было так просто, достаточно было прикинуться Windows и всё бы заработало. Но всё сложнее: под Линукс это НЕ РАБОТАЕТ, а иногда даже аппаратуру портит, а под Windows работает. И разработчик железа не будет разбираться кто и где в ядре накосячил.
     
     
  • 5.93, Andrey Mitrofanov (?), 15:33, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Думаешь? Если бы всё было так просто, достаточно было прикинуться Windows и
    > всё бы заработало. Но всё сложнее: под Линукс это НЕ РАБОТАЕТ,

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

    > а иногда даже аппаратуру портит, а под Windows работает. И разработчик
    > железа не будет разбираться кто и где в ядре накосячил.

    И стрелки там правильно и аргументированно переведены.

     
  • 5.94, plain5ence (ok), 16:46, 30/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пример порчи аппаратуры приведите, пожалуйста.

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

     
     
  • 6.100, Аноним (-), 04:17, 01/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Пример порчи аппаратуры приведите, пожалуйста.

    Тебе DSDT настроить чтоб у тебя cpu в буке на полной моще всегда работал? и в результате выгорел? или еще чего пожелаете?

     
  • 5.104, Аноним (-), 00:02, 02/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    fixed Ведь действительно, разработчики линукса такие недалекие и наивные - внача... большой текст свёрнут, показать
     
  • 3.101, Аноним (-), 04:21, 01/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сразу видно человека заводившего хакинтошь
     
  • 3.108, Анонимный Алкоголик (?), 22:02, 15/04/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > мы забили на стандарты  - лишь бы работало под виндой

    На самом деле: "мы специально долго трудились и забивали на стандарты, чтобы работало только под Вындой и не работало в Линукс" (но таки надорвались).

     

  • 1.20, Аноним (-), 15:34, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Проблемным также остаётся вопрос доведения всех доступных средств энергосбережения до пользователей. Компания Intel обеспечила в ядре поддержку всех возможностей управления питанием для своих систем, но данные возможности лежат мёртвым грузом и остаются неактивированными."

    Это факт, и не только в драйверах Intel. Юзерспейс и дефолты Linux требуют развития.

     
  • 1.22, Xasd (ok), 15:35, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > ложится на дистрибутивы, которые не спешат что-то менять и склоняются к использованию консервативных универсальных настроек

    всё правильно делают дистрибутивы.

    универсальность -- важнее парочки сохранённых Ватт.

    нам не нужна ситуация когда для каждой модели компьютера нужен индивидуальный дистрибутив (с индивидуальной подгонкой драйверов).

    а ситуация которая творится сейчас в сфере операционных систем для смартфонов -- просто абсурдна.

     
     
  • 2.48, Crazy Alex (ok), 17:53, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дистрибутив - не нужен. А вот индивидуальный конфиг - вполне. Тем более, что это суровая системщина с юзерспейсом пересекающаяся весьма слабо - так что эти конфиги дистрибутивам как раз совершенно ортогональны.
     
     
  • 3.86, Xasd (ok), 16:03, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну пусть так.. лиж бы только эти конфиги НЕ засовывали бы внутрь дистрибутивов (а выкладывали бы отдельно бы :))
     
     
  • 4.87, Crazy Alex (ok), 16:18, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да какая разница. Ну вон таскается же terminfo какой-нибудь. Так же и это можно таскать. Просто раз оно софту ортогонально - то заниматься созданием такого должен отдельный проект. А дистры потом, как обычно, его результаты опакетят и себе в репозитории положат.

    Впрочем, "как сделать удобное community-driven хранилище конфигураций" - тема отдельная и очень большая. И абсолютно непаханая.

     

  • 1.30, lybin (ok), 16:26, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Могу ошибаться, но утилита laptop-mode-tools решает проблему со сном SATA.
     
     
  • 2.40, какерспаниель (?), 17:01, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Сейчас в моде TLP.
     

  • 1.35, Аноним (-), 16:38, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А произвоительность на сколько процентов упала после снижения энергопотребления на 40%? На 60%?
     
     
  • 2.46, koblin (ok), 17:30, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    в режиме ожидания же
     

  • 1.39, xaxaxa (?), 16:59, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    нет ничего хуже процессоров с закрытыми фирмварями
     
     
  • 2.49, rob pike (?), 17:58, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тут как раз MIPS открыли
    http://linuxgizmos.com/imagination-to-release-open-mips-design-to-academia/
     
  • 2.53, Аноним (-), 18:21, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не в закрытых фирмварях, а наоборот. Написали же, Интел накодила в ядре все необходимое. Осталось дело за малым - кастомизировать профили для каждого из процессоров и оборудования. Рутинная работа, чем в опенсорсе не принято заниматься: удобные дефолты и предустановки
     
     
  • 3.60, Аноним (-), 19:15, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дело не в закрытых фирмварях, а наоборот. Написали же, Интел накодила в
    > ядре все необходимое. Осталось дело за малым - кастомизировать профили для
    > каждого из процессоров и оборудования. Рутинная работа, чем в опенсорсе не
    > принято заниматься: удобные дефолты и предустановки

    За весь опенсорс отвечаете, да?

     

  • 1.51, DmA (??), 18:19, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    может и в андроиде чего переделают, и тогда смартфоне на его базе поставят новый рекорд без розетки -два дня...
     
     
  • 2.61, demimurych (ok), 19:23, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    у меня при активном использовании (мессенджеры, интернет, почта, органайзер и т.д.) стандартная зарядка раз в четыре дня.
    подскажите куда мне обратится чтобы мне что-то подправили и было как у всех - один день?
     
     
  • 3.63, rob pike (?), 19:36, 28/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это не как у всех.
    Как у всех - это нафиг мессенджеры, интернет, почта, органайзер.
    Оставляем только телефон и СМС.
    Играем в игрушки каждую свободную секунду.
     

  • 1.62, Chromium (?), 19:32, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Они выключили процессор ?!?! :))))
     
  • 1.64, iZEN (ok), 20:32, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А, вот почему китайские роутеры не спят и их приходится выключать!
     
  • 1.68, Аноним (-), 22:58, 28/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Через одно место работающие ACPI это норма для производителей железа. Одни костыли костылями погоняют.
     
  • 1.83, Аноним (-), 10:44, 29/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Играю в игры в месенджерах не включая экран батареи хватает на восемь месяцев..
     
     
  • 2.85, Пыщь (?), 15:40, 29/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Играю в игры в месенджерах не включая экран батареи хватает на восемь
    > месяцев..

    Ну я с батареей КАМАЗа и не такой рекорд выдать смогу..

     

  • 1.96, Аноним (-), 18:30, 30/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Похожее поведение наблюдается и в Windows, но большинство производителей оборудования поставляют в данной ОС дополнительный AHCI-драйвер компании Intel, который активирует корректные политики энергопотребления.

    Я один вижу противоречие внутри этой фразы?

     
  • 1.99, Аноним (-), 02:56, 01/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Собственно, проблема с производителями железа не нова:
    http://jakobz.livejournal.com/244504.html
     
  • 1.106, Ilya Indigo (ok), 00:39, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как-то кроме отката, можно вернуть обратно kde4 на openSUSE Tumbleweed?
     
     
  • 2.107, Ilya Indigo (ok), 00:39, 21/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ой, темой ошибся.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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