Апатч передает привет
Пару дней назад у клиента "упал сайт", 4гб VDS(centOS), больше половины заняли логи(2,4гб).
"Поднял" сайт и начал читать лог. Апатч 6 лет писал что все хорошо и передавал привет!
GNU/Linux
1 030 постов
•
15 516 подписчиков
Прогресс в использовании ОС Redox на реальном оборудовании
Джереми Соллер (Jeremy Soller), основатель операционной системы Redox, написанной на языке Rust, рассказал об успешном использовании Redox на ноутбуке System76 Galaga Pro (Джереми Соллер работает в компании System76). Из уже полностью работоспособных компонентов отмечаются клавиатуры, тачпад, накопитель (NVMe) и Ethernet.
Эксперименты с Redox на ноутбуке уже позволили улучшить работу драйверов, добавить поддержку HiDPI в некоторые приложения и создать новые компоненты, такие как pkgar, упрощающие установку Redox с Live-образов. Среди задач, на которых теперь сфокусировано внимание упоминается достижение возможности самосборки системы (сборки Redox из окружения на базе Redox). Через несколько месяцев Соллер планирует на одном из компьютеров перейти к постоянной работе над Redox из рабочего окружения на базе Redox, после того как будут внесены некоторые доработки, связанные с компилятором rustc.
Применяемая в Redox концепция микроядра упрощает разработку драйверов, так как можно перекомпилировать и перезапускать подсистему, обеспечивающую функционирование драйверов, без остановки работы. Ожидается, что разработка в окружении на базе Redox позволит повысить эффективность портирования программ и решения проблем с поддержкой оборудования. Например, планируется довести до полноценного состояния USB-стек и добавить графические драйверы.
Напомним, что операционная система развивается в соответствии с философией Unix и заимствует некоторые идей из SeL4, Minix и Plan 9. Redox использует концепцию микроядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами, а вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. Все драйверы выполняются в пространстве пользователя в изолированных sandbox-окружениях. Для совместимости с существующими приложениями предоставляется специальная POSIX-прослойка, позволяющая запускать многие программы без портирования.
В системе применяется принцип "все есть URL". Например, для записи в лог может использоваться URL "log://", для взаимодействия между процессами "bus://", для сетевого взаимодействия "tcp://" и т.п. Модули, которые могут быть реализованы в форме драйверов, расширений ядра и пользовательских приложений, могут регистрировать свои обработчики URL, например, можно написать модуль обращения к портам ввода/вывода и привязать его к URL "port_io://", после чего можно использовать его для доступа к 60 порту через открытие URL "port_io://60". Наработки проекта распространяются под свободной лицензией MIT.
Пользовательское окружение в Redox построено на базе собственной графической оболочки Orbital (не путать с другой оболочной Orbital, использующей Qt и Wayland) и тулкита OrbTk, предоставляющего API, похожий на Flutter, React и Redux. В качестве web-браузера применяется Netsurf. Проектом также развивается собственный пакетный менеджер, набор стандартных утилит (binutils, coreutils, netutils, extrautils), командная оболочка ion, стандартная Си-библиотека relibc, vim-подобный текстовый редактор sodium, сетевой стек и файловая система TFS, развиваемая на основе идей ZFS (модульный вариант ZFS на языке Rust). Конфигурация задаётся на языке Toml.
Показать полностью
2
Нужен совет красноглазый, для начинающего
Примерно с год назад я таки соскочил с винды дьявольской на линух прекрасный. И жил, и радовался, и песни пел хвалебные. И иногда обновления скачивал не вникая нихуя. Но, не так давно, мне пришлось сменить тырнет провайдера и теперь скорость слегка снизилась (всё-таки у воздуха электропроводность ниже чем у оптического кабеля). И загрузка кучи Гб обновлений стала занимать заметное время. Памак-манагер, который собсно и занимается загрузкой и установкой, конечно же даёт мне выбор --- что обновить, а что не нужно. Но делает он это несколько неуклюже.
Синенькая кнопочка "обнобить" означает, что данная обнова будет загружена, а беленькая, соответственно нет. Чтобы отказаться от огроменной кучи не очень нужных мне обновлений,я должен каждую синюю кнопочку сделать беленькой. А их там сотни, тысячи, мильярды. А я ленивый как попугай Кеша. К тому же легко запутаться.
Так собственно вот в чём вопрос — как мне установить только то, что мне хочется, без обновления всего? В самом памаке я не нашёл такой кнопки.
Он обновляет либо всё по умолчанию, либо я должен своими родными пальчиками отключить ненужные мне обновы. А это тяжело и муторно. А мне не пятнадцать лет. Я когда на второй этаж поднимаюсь --- два перекура делаю. В лифте.
Короче, как мне ставить нужные обновы? Куда копать, сюрпризы, подводные камни?
Я знаю о существовании терминала, но я линух ставил не для того, чтобы в командной строке сидеть — это я и в винде мог делать круглосуточно).
В идеале все синенькие кнопочки должны быть беленькими, что бы я сам их жмакал.
Спасибо за полезные советы, да и за бесполезные тоже)
ПС ебучий робот автоматом добавляет тег "мат", поэтому, чтобы тег зря не пропадал я напишу — админы, вы пизданулсь совсем?
Показать полностью
2
Обновлены планы по поставке 32-разрядных библиотек в Ubuntu 20.04
Стив Лангашек (Steve Langasek) из компании Canonical обобщил результаты обсуждения с сообществом списка библиотек для архитектуры i386, которые планируется поставлять в прослойке для обеспечения сосвместимости с 32-разрядными приложениями в Ubuntu 20.04 "Focal Fossa". Из более чем 30 тысяч исходных пакетов выбрано около 1700, для которых будет продолжено формирование 32-разрядных сборок для архитектуры i386.
В основном в список вошли библиотеки, используемые в ещё находящихся в обиходе 32-разрядных приложениях, а также связанные с этими библиотеками зависимости. Кроме того, для библиотек из списка планируется сохранить используемые для тестов зависимости, но использовать их для кросс-тестирования i386-сборок библиотек в 64-разрядном системном окружении x86_64, моделируя, таким образом, окружение, которое будет применяться в реальных условиях.
По сравнению с набором 32-разрядных библиотек, поставлявшихся в Ubuntu 19.10, в состав Ubuntu 20.04 дополнительно будут включены библиотеки:
freeglut3
gstreamer1.0-plugins-base
libd3dadapter9-mesa
libgpm2
libosmesa6
libtbb2
libv4l-0
libva-glx2
va-driver-all
vdpau-driver-all
Но при этом из набора будут исключены устаревшие пакеты, которые в Ubuntu 20.04 перестанут собираться и для актуальных архитектур (привязанные к версиям пакеты, такие как libperl5.28 и libssl1.0.0, будут заменены на более новые):
gcc-8-base
libhogweed4
libnettle6
libperl5.28
libsensors4
libssl1.0.0
libhogweed4
libigdgmm5
libllvm8
libmysqlclient20
libnettle6
libtxc-dxtn-s2tc0
libvpx5
libx265-165
wine-devel-i386
wine-stable-i386
Напомним, что изначально компания Canonical намеревалась полностью прекратить сборку пакетов для архитектуры i386 (в том числе отказаться от формирования библиотек multiarch, необходимых для запуска 32-разрядных приложений в 64-разрядном окружении), но пересмотрела своё решение после изучения замечаний, высказанных разработчиками Wine и игровых платформ. В качестве компромисса было решено обеспечить сборку и поставку отдельного набора 32-разрядных пакетов с библиотеками, необходимыми для продолжения работы устаревших программ, остающихся только в 32-разрядном виде или требующих 32-разрядных библиотек.
В качестве причины прекращения поддержки архитектуры i386 упоминается невозможность сопровождения пакетов на уровне других поддерживаемых в Ubuntu архитектур, например из-за недоступности для 32-разрядных систем последних наработок в области повышения безопасности и защиты от фундаментальных уязвимостей типа Spectre. Поддержание пакетной базы для i386 требует больших ресурсов на разработку и контроль качества, которые не оправдывают себя из-за незначительной пользовательской базы (число систем i386 оценивается в 1% от общего числа установленных систем).
Показать полностью
Выпуск GNU Mes 0.21, инструментария для самодостаточной сборки дистрибутивов
Представлен выпуск инструментария GNU Mes 0.21, обеспечивающего процесс бутстрэппинга (bootstrap) для GCC. Инструментарий решает задачу верифицированной начальной сборки компилятора в дистрибутивах, разрывая цепочку цикличной пересборки (для сборки компилятора требуются исполняемые файлы уже собранного компилятора).
В GNU Mes предлагается самодостаточный (self-hosting) интерпретатор для языка Scheme, написанный на языке Си, и простейший компилятор для языка Си (MesCC), написанный на языке Scheme. Оба компонента взаимособираемы. Scheme-интерпретатор даёт возможность собрать Си-компилятор MesCC, который затем позволяет собрать урезанную версию компилятора TinуCC (tcc), возможностей которого уже достаточно для сборки GCC.
В новом выпуске появилась возможность частичного (Reduced Binary Seed) бутстрэппинга дистрибутива Guix с использованием командной оболочки Gash (Guile as Shell) вместо bash и Gash Core Utils вместо coreutils, grep, sed, gzip, make, awk и tar, используя только компоненты на языке Scheme. В новой версии также подготовлен пакет с Mes для Debian GNU/Linux.
В следующих выпусках ожидается появление поддержки бутстрэппинга для NixOS, возможность использования dietlibc и uClibc для бутстрэппинга GNU (bash, binutils, gcc, tar), поддержка архитектуры ARM, дистрибутива Debian и ядра GNU Hurd, возможность компиляции Mes.c с использованием M2-Planet.
RIPE выделил последний свободный блок IPv4
Региональный интернет-регистратор RIPE NCC, занимающийся распределением IP-адресов на территории Европы, Средней и Центральной Азии, объявил о распределении последнего доступного блока адресов IPv4. В 2012 году RIPE приступил к распределению последнего /8 блока адресов (около 17 млн. адресов) и сократил максимальный размер выделяемой подсети до /22 (1024 адресов). Вчера был выделен последний блок /22 и свободных адресов IPv4 у RIPE не осталось.
Подсети IPv4 отныне будут выделяться исключительно из пула возвращаемых блоков адресов, который пополняется за счёт закрывшихся организаций, владевших IPv4-адресами, добровольной передачи неиспользуемых блоков или изъятия подсетей после закрытия учётных записей LIR-ов. Адреса из пула возвращаемых блоков будут выдаваться в порядке очереди блоками, не превышающими 256 (/24) адресов. Заявки на помещение в очередь принимаются только от LIR-ов, ранее не получавших IPv4-адреса (сейчас в очереди 11 LIR-ов).
Отмечается, что потребность в IPv4 у операторов исчисляется миллионами адресов. Активное внедрение трансляторов адресов (CG-NAT) и возникший последние годы рынок перепродажи IPv4-адресов, являются лишь временными компромиссами, не решающими глобальной проблемы с нехваткой адресов IPv4. Без широкомасштабного внедрения IPv6 рост глобальной сети может быть ограничен не техническими проблемами или отсутствием инвестиций, а банальной нехваткой уникальных сетевых идентификаторов.
По данным, основанным на статистике запросов к сервисам Google, доля IPv6 приближается к 30%, при том, что год назад этот показатель составлял 21%, а два года назад - 18%. Наиболее высокая степень применения IPv6 отмечается в Бельгии (49.8%), Германии (44%), Греции (43%), Малазии (39%), Индии (38%), Франции (35%), США (35%). В России число пользователей IPv6 оценивается в 4.26%, Украине - 2.13%, Республике Беларусь - 0.03%, Казахстане - 0.02%.
По статистике от компании Cisco, доля маршрутизируемых префиксов IPv6 составляет 33.54%. Число пользователей IPv6 в отчётах Cisco примерно соответствует статистике Google, но дополнительно приводятся сведения о степени внедрения IPv6 в инфраструктуре операторов. В Бельгии доля внедрения IPv6 составляет 63%, Германии - 60%, Греции - 58%, Малазии - 56%, Индии - 52%, Франции - 54%, США - 50%. В России степень внедрения IPv6 находится на уровне 23%, Украине - 19%, Республике Беларусь - 22%, Казахстане - 17%.
Среди наиболее активно применяющих IPv6 сетевых операторов выделяются T-Mobile USA - степень внедрения IPv6 95%, RELIANCE JIO INFOCOMM - 90%, Verizon Wireless - 85%, AT&T Wireless - 78%, Comcast - 71%. Число сайтов из рейтинга Alexa Top 1000, доступных напрямую через IPv6, составляет 23.7%.
Показать полностью
2
Компания Mozilla опубликовала финансовый отчёт за 2018 год
Компания Mozilla опубликовала финансовый отчет за 2018 год. В 2018 году доходы Mozilla уменьшились на 112 млн долларов и составили 450 млн долларов, в то время как в 2017 году компания Mozilla заработала 562 млн долларов, в 2016 году - 520 млн долларов, в 2015 - 421 млн долларов, в 2014 - 329 млн долларов, в 2013 - 314 млн, 2012 - 311 млн.
429 млн из 450 млн получены благодаря отчислениям за использование поисковых систем (Baidu, DuckDuckGo, Google, Yahoo, Bing, Yandex), сотрудничеству с различными сервисами (Cliqz, Amazon, eBay) и размещению контекстных рекламных блоков на стартовой странице. В 2017 году размер подобных отчислений составил 539 млн. 6.3 млн долларов составили пожертвования, что на 100 тысяч меньше, чем в 2017 году. Объём средств, вложенных в инвестиции в 2018 году составил 368 млн долларов (в 2017 году 414 млн, в 2016 году - 329 млн, в 2015 году - 227 млн, в 2014 году - 137 млн).
Среди затрат доминируют расходы на разработку (277 млн долларов в 2018 против 259 млн в 2017 году, в режиме полного рабочего дня трудоустроено более 1000 сотрудников), поддержку сервисов (33.4 млн долларов в 2018 против 20.7 млн в 2017), маркетинг (53 млн долларов в 2018 против 66 млн в 2017) и административные расходы (86 млн долларов в 2018 и 74 млн в 2017). 4.8 млн долларов потрачено на выплату грантов (в 2017 году - 5.4 млн). Общая сумма затрат составила 451 млн долларов (в 2017 году - 421.8, в 2016 году - 360.6, в 2015 году - 337.7, в 2014 - 317.8, в 2013 - 295 млн, в 2012 - 145.4 млн). Размер активов на начало года - 514 млн долларов, на конец года - 523 млн долларов.
Показать полностью
В uBlock Origin добавлена защита от нового метода отслеживания, манипулирующего именами в DNS
Пользователи uBlock Origin заметили применение рекламными сетями и системами web-аналитики новой техники отслеживания перемещений и подстановки рекламных блоков, которая не блокируется в uBlock Origin и других дополнениях для отсеивания нежелательного контента.
Суть метода в том, что владельцы сайтов, желающие разместить код для отслеживания или показа рекламы, создают в DNS отдельный поддомен, ссылающийся на сервер рекламной сети или web-аналитики (например, создаётся CNAME-запись f7ds.liberation.fr, указывающая на сервер трекинга liberation.eulerian.net). Таким образом, рекламный код формально загружается с того же первичного домена, что и сайт, и поэтому не подвергается блокировке. Имя для поддомена выбирается в форме случайного идентификатора, что затрудняет блокировку по маске, так как связываемый с рекламной сетью поддомен трудно отличить от поддоменов для загрузки других локальных ресурсов страницы.
Разработчик uBlock Origin предложил использовать резолвинг имени в DNS для определения связанного через CNAME хоста. Метод реализован в выпуске uBlock Origin 1.24.2 для Firefox. Для активации проверки в расширенных настройках следует установить значение cnameAliasList в "*", в этом случае все проверки по чёрным спискам будут дублироваться и для имён, определяемых через CNAME. При установке обновления потребуется предоставить полномочия для получения сведений из DNS.
Для Chrome проверка CNAME не может быть добавлена, так как API dns.resolve() доступен только для дополнений в Firefox и не поддерживается в Chrome. С точки зрения производительности определение CNAME не должно привести к появлению дополнительных накладных расходов, кроме трат процессорных ресурсов на повторное применение правил для другого имени, так как при обращении к ресурсу браузер уже выполнил резолвинг и значение должно быть прокешировано. Метод защиты может быть обойдён при помощи прямой привязки имени к IP без применения CNAME, но такой подход усложняет сопровождение (в случае смены IP-адреса рекламной сети нужно будет добиться изменения данных на всех DNS-серверах издателей) и может быть обойдён через создание чёрного списка IP-адресов трекеров.
Показать полностью