Прошло 1,5 года с тех пор как я покинул линукс, в это время я много странствовал - сначала 2-3 месяца сидел на маке, потом год на старой доброй венде, даже фряху пробовал прости господи, но вот я снова решил попробовать линукс, выбрал недавно вышедший Debian (с него и пишу), установка прошла нормально как всегда, разве что установщик ругался что фирмварь для сетевухи отсутствовал, но это пустяки, поставил позже. Дальше решил проверить, а много ли изменилось с тех времен, когда я 1,5 года назад юзал линукс, а вот и ответ - это всё-тот же старый, добрый линукс с 12309, тормозной анимацией KDE и глючной панелью KDE (сменить KDE не предлагать). В принципе, я особо и не надеялся что что-то изменилось, но надежда умирает последней. Тред создавался не ради унижения линукса, а ради помощи. Помогите пожалуйста побороть хотя бы 12309 (твики там всякие накидайте, советы, и.т.д), не хочется мне покидать линукс, ой как не хочется. Пробовал следовать советам shimon'а, но не очень-то и помогло: со строкой

vm.overcommit_memory = 2

 vm.overcommit_ratio = 80

vm.dirty_ratio = 10
vm.dirty_background_ratio = 8

В течение целого месяца Microsoft пыталась донести до аудитории все положительные стороны своей новой консоли Xbox One. Увы, то, что корпорация считала плюсами (встроенная DRM-защита, ограничения на одалживание игр и регулярные онлайн-проверки), для всех остальных представлялось очевидными минусами. Удивительно, но Microsoft решила сделать шаг назад и переосмыслить свою политику в отношении Xbox One.

Как стало известно, отныне новая консоль не будет требовать ежедневного подключения к Интернету для того, чтобы играть в одиночные игры. Подключиться к Сети, фактически, необходимо лишь один раз, в момент первого запуска Xbox One. После этого пользователи смогут запускать с дисков любые игры, не заботясь о своем подключении. Консоль можно будет спокойно взять, к примеру, на дачу, не испытав при этом никаких трудностей. Игры, загруженные в сервисе Xbox Live, также можно будет запускать в оффлайн-режиме. Само собой, для того, чтобы играть в сетевые игры и пользоваться облачными сервисами Xbox One, вам придется иметь стабильное подключение.

Перепродажа, одалживание, дарение и аренда дисков отныне тоже разрешены. Никаких ограничений. Захотели дать диск другу? Пожалуйста. В этом вопросе все будет точно так же, как и на Xbox 360. Помимо этого, Microsoft также избавляется от региональных ограничений на Xbox One.

Что же вызвало такие резкие перемены? Само собой, реакция игроков на предыдущие заявления Microsoft. Дон Мэттрик сказал, что корпорация прочитала множество комментариев и внимательно изучила отзывы потенциальных покупателей. В итоге изначальный план пришлось выбросить на свалку.

«Еще раз спасибо вам за ваши прямые отзывы. Наша команда продолжает выслушивать их, готовясь представить вам замечательный продукт в конце этого года», – заявил Мэттрик. Пруф

Как стало известно, компания Microsoft тайно сообщала спецслужбам данные об ещё не исправленных 0-day уязвимостях в Windows и Skype для их устранения до появления официальных обновлений и возможного проведения атак на компьютеры и организации слежки за другими государствами и различными компаниями.

Долгое время циркулировали слухи о наличии специальных точек входа позволяющим удалённо проникать в продукты Microsoft. Теперь поступили подтверждения, что спецслужбы США имеют доступ ко всем 0-day уязвимостям в редмондской компании задолго до их устранения, таким образом позволяя себе без особых усилий проникать на интересующий их компьютер.
Опеннет

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

Разработчики пользовательского окружения Cinnamon, в рамках которого развивается форк оболочки GNOME Shell и оконного менеджера Mutter, нацеленный на предоставление окружения в классическом стиле GNOME 2, но основанного на технологиях GNOME 3 и поддерживающего удачные элементы взаимодействия из GNOME Shell, рассказали о планах по прекращению зависимости от выпусков GNOME в следующей версии Cinnamon 2.0.

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

Например, Cinnamon 1.6 был основан на GNOME 3.6, что мешало переходу на GNOME 3.8, поддержка которого появилась только спустя более месяца в Cinnamon 1.8. Таким образом, дистрибутивы сразу перешедшие на GNOME 3.8, вынуждены были прекратить поддержку пакетов с Cinnamon или поддерживать дублирующиеся пакеты с GNOME 3.6, а дистрибутивы решившие отложить переход на GNOME 3.8 лишились возможности использования новой версии Cinnamon 1.8.

Для выхода из сложившегося тупика разработчики Cinnamon решили начиная с версии 2.0 перейти к поставке полностью обособленного окружения, не пересекающегося с GNOME. Технически Cinnamon по прежнему будет основываться на компонентах GNOME, но эти компоненты будут поставляться как периодически синхронизируемый форк GNOME, не связанный внешними зависимостями с GNOME. Cinnamon 2.0 ожидается осенью и войдёт в состав дистрибутива Linux Mint 16, который будет построен на пакетной базе Ubuntu 13.10.
Опеннет

Ричард Хьюз, создатель проекта PackageKit, опубликовал задачи, рассмотренные на совещании, посвящённом модернизации системы управления пакетами в Fedora Linux. В частности, пакетный менеджер YUM признан устаревшим и ему на смену скоро придёт система DNF, в рамках которой развивается форк YUM 3.4, переведённый на использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey с реализацией SAT solver. В отличие от YUM новый пакетный менеджер отличается заметным увеличением скорости работы, низким потреблением памяти, предоставлением API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.
Опеннет

Ларс Вирзениус (Lars Wirzenius), один из первых мэйнтенеров Debian GNU/Linux, вовлечённый в развитие Linux с первых дней существования проекта, и Расс Олбери (Russ Allbery), отвечающий за сопровождение ряда подсистем Debian, выступили с предложением по изменению подхода к поддержанию репозитория Debian Testing. Для того чтобы избежать многомесячных заморозок репозитория, не допускающих внесения обновлений, предлагается поддерживать Debian Testing в состоянии постоянно готовым к релизу, т.е. не допускать нахождения незакрытых ошибок, помеченных как блокирующих релиз.

В процессе подготовки Wheezy стадия заморозки продолжалась 10 месяцев и потребовала исправления около 700 блокирующих релиз ошибок, что по мнению авторов предложения недопустимо долго и неэффективно. В качестве максимально допустимого времени нахождения Testing в состоянии заморозки называется 2 месяца. Для увеличения качества репозитория testing также предлагается более активно использовать средства автоматизированного тестирования и методы непрерывной интеграции. В итоге удастся не только сократить время подготовки релиза, но и повысить актуальность репозитория Testing, сделав его более пригодным для непосредственного использования.

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

Изначальное блокирование проблемных пакетов в Testing позволит возвести исправление важных проблем в ряд высокоприоритетных задач, которые не могут быть отложены, что увеличит степень ответственности мэйнтейнеров пакетов и усилит их вовлечение в подготовку новых выпусков. При подобном подходе для окончательной стабилизации может быть достаточно заморозки на несколько недель. Для ускорения доведения релиза до готовности также предлагается сформировать набор эталонных установочных комплектов пакетов (почтовый сервер, рабочая станция, web-сервер и т.п.), рассматривая их как первичные критерии стабильности релиза и допуская наличие несущественных ошибок в сторонних пакетах.
Опеннет

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и выдал интересные подробности о процессе разработки ядра NT. Своим сообщением он хотел подтвердить тезис о том, что ядро неэффективно и во многом уступает по производительности другим ОС: см. оригинальное сообщение (автор удалил его, испугавшись резких формулировок) и копию.

Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразиться на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.

В Microsoft не существует программы по систематическому улучшению производительности Windows. Во времена Windows XP компания начала уделять большое внимание безопасности, потому что с этим обнаружились серьёзные проблемы. Однако на производительность никто не обращал и не обращает особого внимание.

Ещё одна проблема в ухудшении ситуации с производительностью ОС — в утечке самых талантливых кадров. Google и другие компании Кремниевой долины активно охотятся за одаренными программистами и не стесняются переманивать их из других компаний. Из-за текучки кадров новые разработчики предпочитают реализовывать новые функции вместо оптимизации старых. Именно в этом причина появления PowerShell: многие хотели улучшить cmd.exe, но не имели возможности.

В качестве конкретных примеров разработчик называет следующее:

«Нам нельзя трогать именованные каналы. Лучше добавим %INTERNAL_NOTIFICATION_SYSTEM%! И пусть она будет несовместима с почти всеми другими именованными примитивами NT.

Мы не можем показывать %INTERNAL_NOTIFICATION_SYSTEM% остальному миру, потому что не хотим заниматься бумажной работой и терять продажи, ведь сейчас публично доступны только интерфейса Win32 APIs эпохи 90-х.

Мы не можем трогать DCOM. Так что создадим ещё один %C#_REMOTING_FLAVOR_OF_THE_WEEK%!

XNA. Что тут ещё сказать?

Зачем кому-то нужен формат архивирования с поддержкой файлов больше 2 ГБ?

Давайте поддерживать символьные ссылки, но убедимся, что никто не сможет их использовать, так что нас не обвинят в уязвимости безопасности. (Отлично! Теперь мы выглядим мудрыми и ответственными!)

Нельзя трогать Source Depot, так что давайте вместе хакнем SDX (Secure Document Exchange)!

Нельзя трогать SDX, так что давайте притворяться в течение четырёх релизов, что мы переходим на TFS (Team Foundation Server), а сами ничего не будем менять!

Господи, код NTFS — это багровый роман ужасов, написанный под опиумом в средневековье, где используются глобальные рекурсивные блокировки и контроль потока со структурной обработкой исключений (SEH). Давайте вместо неё напишем ReFs. (И да, начнем с копипаста исходников NTFS и удаления половины функциональности! Теперь добавим контрольные суммы, потому что контрольные суммы это круто, и с контрольными суммами мы почти так же круты, как ZFS, верно? И вообще, кому нужны квоты?)

Мы вообще не в силах реализовать поддержку C11, а шаблоны с переменным числом аргументов слишком сложны, чтобы внедрить их за год. (Но смотрите, мы превратили «^» в оператор указателя с подсчитанными ссылок! Ой, а что такое подсчёт ссылок?)».

Осторожно, хабр!

Компания Coverity, развивающая инструментарий для автоматического анализа кода на предмет наличия проблем безопасности и ошибок опубликовала отчёт с результатами изучения 450 млн строк кода, охватывающих 118 наиболее активно разрабатываемых открытых проектов и 256 проприетарных продуктов.

В среднем уровень дефектов в открытом и закрытом коде оказался примерно на одном уровне - 0.69 против 0.68 ошибок на 1000 строк кода, что значительно выше требований промышленных стандартов качества, в которых допускается 1 ошибка на 1000 строк кода. В проектах размером от 500 тысяч до 1 млн строк кода открытое ПО почти в два раза опередило проприетарное ПО по качеству, показав коэффициент наличия ошибок 0.44 против 0.98. Для проектов до 100 тысяч строк кода данные показатели составили 0.4 и 0.51, от 100 до 500 тысяч - 0.60 и 0.66. В проектах, размером более 1 млн строк кода более высокое качество наблюдается в проприетарном ПО - коэффициент ошибок в открытом ПО составил 0.75, а в проприетарном - 0.66.

Анализ качества ядра Linux показал, что в выпущенных за 2012 год версиях ядра Linux 3.2-3.7 было зафиксировано 5803 дефектов, при этом уже исправлено 5170 проблем. В 2011 году число дефектов для ядер 2.6.38-3.1 составило 2331, но исправлено было только 1283 проблем. Средний коэффициент наличия ошибок во всех подсистемах ядра составил 0.66 (от 0.32 до 0.9, в зависимости от подсистемы ядра), в то время как 5 лет назад данный коэффициент превышал граничный показатель в 1 ошибку на 1000 строк кода. В новых версиях ядра число ошибок уменьшается, например в ядре 3.8 коэффициент наличия ошибок составляет 0.59.
Опеннет.

Например в FHS черным по белому написано что низзя, а в документации к ядру наоборот в пример приводят. Кому верить-то?

Мэтью Гаррет, один из разработчиков ядра Linux, последнее время занимающийся обеспечением загрузки Linux на системах с UEFI, опубликовал результаты экспериментов с ноутбуками Samsung, на которых проявляется проблема с UEFI-прошивкой, приводящая к дальнейшей неработоспособности устройства. Проблема наблюдается на моделях ноутбуков Samsung 300E5C, NP700Z5C, NP700Z7C и 530U3C при попытке загрузки Linux с использованием UEFI или при выполнении некоторых специфичных операций с UEFI в других ОС, в том числе в Windows 8.

Было выяснено, что проблема проявляется только в случаях, когда память для переменных UEFI заполнена более чем наполовину. В частности, причины проблем кроются в ошибке сборщика мусора UEFI. При удалении UEFI-переменной, она не очищается сразу, а лишь помечается удалённой. Чистка же производится в момент инициализации во время загрузки, через запуск реализованного в прошивке сборщика мусора. Если свободного места недостаточно, сборщик мусора зависает, что приводит к невозможности в дальнейшем загрузить систему без очистки Flash-памяти в сервисном центре. Когда свободной памяти UEFI достаточно (более 50%), устройства сохраняют нормальную работоспособность. Используя данную особенность, Мэтью подготовил патч для ядра Linux, недопускающий заполнения UEFI-памяти более чем наполовину.

Опеннет
P.S В UEFI еще и сборщик мусора есть? о_О

На состоявшемся несколько часов назад заседании комитета по техническому развитию Ubuntu утверждено решение по сокращению времени поддержки промежуточных выпусков Ubuntu c 18 до 9 месяцев. Время поддержки LTS-выпусков оставлено неизменным. Таким образом, обновления с устранением проблем безопасности для не LTS-релизов будут выпускаться в течение трёх месяцев после выхода следующего выпуска.

При 18-месячном цикле поддержки промежуточных выпусков приходилось поддерживать одновременно 4 выпуска Ubuntu, что отнимало достаточно много ресурсов. По мнению разработчиков 18-месячный цикл поддержки избыточен, так как промежуточные выпуски в основном востребованы пользователями, стремящимися получить наиболее свежий набор программ и достаточно оперативно переходящими на следующий выпуск после его доступности. Для таких пользователей вполне достаточно выпускать обновления только в течение трёх месяцев после релиза. Для тех, кто отдаёт предпочтение стабильности и не спешит совершать переход на новую версию рекомендуется использовать LTS-выпуски, выходящие раз в два года и поддерживаемые 5 лет.

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

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

Ъ:

The first part of today’s headline is probably obvious to many of you. KDE will be moving on from Xorg to Wayland. And considering Gnome’s aggressive plans to move to it, this may happen sooner rather than later. KDE & Gnome having a mutual interest in Wayland is great, and we can’t wait to reap the benefits of it. But it seems that one technology — one that’s synonymous with KDE — will likely not be making the transition.

!Ъ

Комитет по техническому развитию Ubuntu (Ubuntu Tech Board) утвердил на состоявшемся на днях совещании придание сборке Ubuntu с десктоп-окружением GNOME статуса официального ответвления от Ubuntu. Изначально сборка Ubuntu с десктоп-окружением GNOME 3 была представлена летом прошлого года и распространялась под именем Gnomebuntu, но имела статус неофициального ответвления, развиваемого энтузиастами вне инфраструктуры Ubuntu.

При установке новой сборки из коробки предоставляется пользовательское окружение, сформированное в соответствии с канонами проекта GNOME и укомплектованное приложениями GNOME, такими как оболочка GNOME Shell, менеджер входа GDM, немодифицированный файловый менеджер Nautilus, браузер Epiphany, музыкальный проигрыватель Rhythmbox, текстовый процессор Abiword, табличый процессор Gnumeric, почтовый клиент Evolution, менеджер фотографий Shotwell, а также подборка приложений из состава GNOME 3.

Сообщается, что первая бета-версия Ubuntu GNOME 13.04 не будет выпущена на этой неделе вместе с бета-выпуском Ubuntu, но финальную бета-версию Ubuntu GNOME планируется выпустить в конце месяца. Кроме того, в ближайшие недели планируется наладить процесс формирования и тестирования ежедневных сборок. Финальный релиз Ubuntu GNOME выйдет одновременно с релизом Ubuntu 13.04, но будет поставляться с GNOME 3.6, так как не остаётся времени для интеграции в релиз ожидаемого 27 марта выпуска GNOME 3.8. Тем не менее, пользователям будет предоставлена возможность обновления до GNOME 3.8, для чего будет подготовлен соответствующий набор пакето, который будет распространяться через PPA-репозиторий gnome3-team

опеннет

Итак, пришло время менять свой TN. Выбор пал на три модели ASUS, но на оф.сайте почему-то не написано глянцевые они или матовые, в гугле тоже разные сайты пишут по разному. Прошу владельцев (если такие тут есть) моделей: ASUS VS239HR, ASUS VG23AH, ASUS VG27AH отписаться по данному вопросу.

Subj. Вот я так и не могу придумать что ставить себе на аву - ничего в голову не лезет + я практически ко всему равнодушен (не фанатею ни от чего), так что ставить всякие туксы и окошки не вариант.

Поставил я этот Vmware Player, попробовать его. Создал виртуальную машину, настроил параметры, хотел было запустить.. но выскочила такая фиговиина:

This virtual machine is configured to run with 8 CPUs, but VMware Player supports only up to 4 CPUs. The virtual machine cannot be powered on.

хотя в документации к Vmware Player написано:

Player supports up to eight-way virtual Symmetric Multiprocessing (SMP) for guest operating systems running on multiprocessor host machines.

Читал в интернете, добавлял в конфиг виртуальной машины всякие maxcpus= «8» и maxcores= «8» нихрена не помогает. Какого хрена в доках написано одно, а на деле совсем другое? За то что в доках написано одно, а в самой программе совершенно другое, разрабов надо кастрировать, ящитаю.

Несколько энтузиастов из Фонда СПО, один из которых был одет в маску антилопы Гну, символа движения GNU, устроили раздачу дисков с полностью свободным дистрибутивом Trisquel GNU/Linux прямо в специализированном магазине Microsoft в городе Бостон (США). В октябре похожая акция была проведена во время уличной презентации Windows 8, но теперь энтузиасты пошли дальше и устроили акцию прямо в помещении магазина во время проведения работниками Microsoft сессии 'Tech for Tots', нацеленной на знакомство детей с компьютерными технологиями.

Кроме бесплатной раздачи дисков с советом попробовать СПО в праздничные дни, пользователям раздавались листовки с пояснением ограничений, с которыми они столкнутся при переходе на Windows 8. В частности, рассказано о порочности практики привязки пользователя к одному вендору, запрете модификации программной начинки собственного компьютера и рисках, связанных с безопасностью и сохранением частной информации. Сотрудники магазина вначале отнеслись к происходящему как к развлечению, но в конечном итоге вызвали охрану, которая попросила прекратить мероприятие.
Опеннет

subj.

Копипаст с опеннета:
Разработчики дистрибутива Fedora Linux в пятый раз перенесли дату выхода тестовой версии Fedora 18. Перенос бета-версии приведёт к сдвигу и всех других этапов подготовки нового выпуска. Таким образом релиз Fedora 18 выйдет не 6 ноября, как было намечено изначально, а 11 декабря. В качестве мотива задержки выхода называется неготовность fedup, нового инструментария для обновления дистрибутива, а также наличие некоторых блокирующих бета-выпуск проблем в инсталляторе Anaconda.

Полная функциональность системы обновления и установки является обязательным критерием, необходимым для перехода Fedora 18 на стадию заморозки бета-выпуска. Кроме того, оперативному устранению возникших проблем мешает необходимость вовремя завершить работу над подготовкой очередного выпуска RHEL (Red Hat Enterprise Linux), в подготовку которого вовлечены разработчики Anaconda, трудоустроенные в Red Hat.

Тем временем, Леннарт Поттеринг (Lennart Poettering) развернул в списке рассылки разработчиков Fedora Linux обсуждение предложения по использованию по умолчанию подсистемы журналирования событий Journal, интегрированную в системный менеджер systemd. Journal планируется активировать в качестве основной системы ведения логов, которая заменит собой rsyslog. Напомним, что изначально Journal предлагалось внедрить вместо rsyslog в Fedora 18, но данное предложение было отклонено. В качестве причин, мешающих полному переходу на Journal упоминается потеря некоторой привычной функциональности syslog и необходимость обеспечить совместимость с существующими системами мониторинга и анализа логов.

Обсуждение зародилось в продолжении дискуссии о добавлении в число зависимостей для systemd начиная с версии 194 пакетов с реализацией HTTP-сервера (libmicrohttpd) и библиотеки работы с QR-кодами (qrencode-libs), необходимых для работы системы синхронизации логов. Реализация http-сервера используется только в сервисе systemd-journal-gatewayd.service, который в будущем планируется вынести в отдельный пакет. Генерация QR-кодов используется для упрощения сохранения ключей верификации логов.