broadcom вроде для текущих релизов дрова пилит, а вот интеловское видео, для которого ни на что старше 12.04 драйверов под Linux (и под последние Windows ) в природе не существует, мне попадалось.
Обычно при обновлении на более новую версию совместимость сохраняется, кроме совсем уж унылых железок, для которых производитель собирал блоб для конкретной старой версии ядра.
Вот тут то, что 100% должно работать: https://certification.ubuntu.com/certification/desktop/ Но этот список далеко не полный. Надёжнее поискать в гугле "<laptop_model> linux problem hardware OR battery OR video OR hibernate".
Есть linux-tools-generic-lts-xenial, зависящий от последнего linux-tools-<VERSION>-generic а в linux-common просто лежат обёртки, которые дёргают правильный для загруженного ядра бинарник.
Бинарник x86_energy_perf_policy принадлежит пакету linux-tools-common, но судя по выводу strace это обёртка, которая вызывает x86_energy_perf_policy из состава linux-tools-<VERSION>-generic для загруженного в данный момент ядра.
Соответственно, достаточно поставить linux-tools-generic (или например linux-tools-generic-lts-xenial, если ядро от xenial используется в другом релизе), по зависимостям всегда будет прилетать linux-tools-common и linux-tools-<VERSION>-generic для новой версии ядра.
К сожалению установку linux-tools придётся делать каждый раз после обновления ядра, но это не сложно запомнить, что после того, как прилетит свежее ядро, нужно доставить ещё и эти сопутствующие стабильности работы компоненты.
Достаточно поставить linux-tools-generic, он всегда зависит от последней версии. Или, если используется ядро от другого релиза Ubuntu, то соответствующий этому ядру пакет, например linux-tools-generic-lts-xenial
Неформальная часть общения так же важна, как и общение по рабочим моментам.
Почему все это повторяют, как мантру? В коллективах, где я работал и работаю, у меня были тёплые неформальные отношения с одной частью коллег, и сухие рабочие отношения(привет/пока/лови таску в багртекере) с другой их частью. И по моему опыту на эффективность совместной работы это не влияет вообще никак.
Да, и bash прекрасен именнно как максимально простой и лаконичный клей между всеми этими программами: foo | bar | baz > result. Представьте себе то же самое на питоне: import subprocess as sp; p=sp.Popen("foo", stdout=sp.PIPE); sp.communicate(.... Ну это же просто застрелиться.
(ba)sh работает под любой *nix системой и достаточно хорош, чтобы альтернативы не развивались за ненадобностью. Не идеален, а именно достаточно хорош для 99% задач.
Хотя я бы, например, с удовольствием использовал что-нибудь лаконичное как bash, но при этом с нормальной работой с массивами и функциями, что-нибудь вроде специального диалекта питона.
до сих пор нет попыток прикрутить вместо этого ископаемого монстра нормальный современный интерпретируемый язык программирования
Shell изначально развивался как средство быстрой интеграции программ в командной строке, и в этом плане он до сих пор удобнее всех альтернатив. Задачи типа "взять последние 5000 строчек лога, отобрать с типом POST и http status 500, выбрать IP, отсортировать по частоте встречаемости" или "заменить в конфиге все example.com на example.net, протестировать корректность конфига, если ок — перезапустить сервис" на баше делаются почти не думая, быстро и лаконично.
Ну и про legacy забывать не стоит, "просто взять и сделать дистрибутив целиком без bash" — это огромное количество человеко-лет на переписывание всех скриптов, используемых всеми программами, и дальнейшее сопровождение.
советское воспитание — "работу надо любить, и делать её хорошо"
Ну конечно, любовь к своему делу — исключительно монополия советского воспитания, больше такого нигде не было. Я, правда, почему-то много таких людей знаю, из моего выросшего при бездушном капитализме поколения.
> если чешется с левой стороны тела, то зуд можно облегчить, посмотрев в зеркало и почесав соответствующее место на правой стороне тела, и наоборот
А это на самом деле очень полезное наблюдение. Например, можно как-нибудь приспособить например к лечению хронических болей, обусловленных не поражием локальных нервов, а привычным паттерном в мозгу.
Закончил в 2003, астрономии не было. Насколько я знаю, у знакомых ребят закончивших другие воронежские школы такого тоже не преподавали. А жаль, думаю было бы интересно.
Следилок за пользователями не ставлю по принципиальным соображениям, а например комментарии через disqus у меня прекрасно работают. Github pages не изменяет содержимое страницы, что jekyll сгенерил — то и будет показано.
Мне как раз не понравилось, что при перетаскивании issue по колонкам в Project её состояние никак не меняется и настроить это нельзя. Перетащил из "In progress" в "Ready" — а она как была open, так и осталась. В итоге получается просто красивая тасовалка карточек. Надеюсь, потом прикрутят
broadcom вроде для текущих релизов дрова пилит, а вот интеловское видео, для которого ни на что старше 12.04 драйверов под Linux (и под последние Windows ) в природе не существует, мне попадалось.
Обычно при обновлении на более новую версию совместимость сохраняется, кроме совсем уж унылых железок, для которых производитель собирал блоб для конкретной старой версии ядра.
Вот тут то, что 100% должно работать: https://certification.ubuntu.com/certification/desktop/ Но этот список далеко не полный. Надёжнее поискать в гугле "<laptop_model> linux problem hardware OR battery OR video OR hibernate".
Есть
linux-tools-generic-lts-xenial, зависящий от последнегоlinux-tools-<VERSION>-genericа вlinux-commonпросто лежат обёртки, которые дёргают правильный для загруженного ядра бинарник.Достаточно смотреть на совместимость с Linux не после, а до выбора ноута. Несколько снижает широту выбора, зато всё работает из коробки.
Бинарник
x86_energy_perf_policyпринадлежит пакетуlinux-tools-common, но судя по выводу strace это обёртка, которая вызываетx86_energy_perf_policyиз составаlinux-tools-<VERSION>-genericдля загруженного в данный момент ядра.Соответственно, достаточно поставить
linux-tools-generic(или напримерlinux-tools-generic-lts-xenial, если ядро от xenial используется в другом релизе), по зависимостям всегда будет прилетатьlinux-tools-commonиlinux-tools-<VERSION>-genericдля новой версии ядра.Достаточно поставить
linux-tools-generic, он всегда зависит от последней версии. Или, если используется ядро от другого релиза Ubuntu, то соответствующий этому ядру пакет, напримерlinux-tools-generic-lts-xenialПочему все это повторяют, как мантру? В коллективах, где я работал и работаю, у меня были тёплые неформальные отношения с одной частью коллег, и сухие рабочие отношения(привет/пока/лови таску в багртекере) с другой их частью. И по моему опыту на эффективность совместной работы это не влияет вообще никак.
Я знаю, годная софтина. Смайлик в конце намекал на несерьёзность сообщения, но судя по минусам шутка не удалась.
SCO OpenServer не развивается с 2009 года, и сама компания обанкротилась, так что возможно вам пора обновиться :)
Работают сидя на холодной лестнице? :)
Хм, интересно, надо пощупать. Спасибо за подсказку
Да, и bash прекрасен именнно как максимально простой и лаконичный клей между всеми этими программами:
foo | bar | baz > result. Представьте себе то же самое на питоне:import subprocess as sp; p=sp.Popen("foo", stdout=sp.PIPE); sp.communicate(.... Ну это же просто застрелиться.(ba)sh работает под любой *nix системой и достаточно хорош, чтобы альтернативы не развивались за ненадобностью. Не идеален, а именно достаточно хорош для 99% задач.
Хотя я бы, например, с удовольствием использовал что-нибудь лаконичное как bash, но при этом с нормальной работой с массивами и функциями, что-нибудь вроде специального диалекта питона.
Shell изначально развивался как средство быстрой интеграции программ в командной строке, и в этом плане он до сих пор удобнее всех альтернатив. Задачи типа "взять последние 5000 строчек лога, отобрать с типом POST и http status 500, выбрать IP, отсортировать по частоте встречаемости" или "заменить в конфиге все example.com на example.net, протестировать корректность конфига, если ок — перезапустить сервис" на баше делаются почти не думая, быстро и лаконично.
Ну и про legacy забывать не стоит, "просто взять и сделать дистрибутив целиком без bash" — это огромное количество человеко-лет на переписывание всех скриптов, используемых всеми программами, и дальнейшее сопровождение.
З.Ы. Минусуют ИМХО зря, вопрос вполне нормальный.
Ну конечно, любовь к своему делу — исключительно монополия советского воспитания, больше такого нигде не было. Я, правда, почему-то много таких людей знаю, из моего выросшего при бездушном капитализме поколения.
А это на самом деле очень полезное наблюдение. Например, можно как-нибудь приспособить например к лечению хронических болей, обусловленных не поражием локальных нервов, а привычным паттерном в мозгу.
Следилок за пользователями не ставлю по принципиальным соображениям, а например комментарии через disqus у меня прекрасно работают. Github pages не изменяет содержимое страницы, что jekyll сгенерил — то и будет показано.
Мне как раз не понравилось, что при перетаскивании issue по колонкам в Project её состояние никак не меняется и настроить это нельзя. Перетащил из "In progress" в "Ready" — а она как была open, так и осталась. В итоге получается просто красивая тасовалка карточек. Надеюсь, потом прикрутят