Rating@Mail.ru
IPB
Etersoft - from Windows to Linux
Etersoft
решения для перехода
с Windows на Linux
Дружественные сайты: alv.me и Rus-Linux.net

Здравствуйте, гость ( Вход | Регистрация ) Поиск · 

Профиль
Фотография
Опции
Опции
О себе
diesel не указал(а) ничего о себе.
Личная информация
diesel
33 от роду
Мужской
Место жительства не указано
Дата рождения: Фев-23-1984
Интересы
Нет данных
Другая информация
Операционная система: OS X, openSuSE, ROSA, Debian
JID: muaddeep at gmail
Город: Одесса, Украина
Статистика
Регистрация: 22-February 06
Просмотров профиля: 99749*
Последнее посещение: 27th September 2013 - в 00:39
Часовой пояс: Dec 18 2017, в 18:42
5989 сообщений (1.39 за день)
Контактная информация
AIM Нет данных
Yahoo Нет данных
ICQ Нет данных
MSN Нет данных
* Просмотры профиля обновляются каждый час

diesel

Модераторы разделов


Темы
Сообщения
Друзья
Содержимое
15 Jun 2012
Цитата
Эрик Реймонд (Eric S. Raymond), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО, написавший в свое время известное эссе "Собор и Базар", представил в своём блоге программные тезисы на тему вреда от использования закрытого ПО. Представляем изложение его мыслей.

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

Задавая вопрос "когда правильно а когда неправильно использовать закрытое ПО?" мы должны трактовать его точно также как трактуем любой другой этический вопрос, то есть сначала чётко определить, каких именно губительных и вредных последствий мы хотим избежать, а затем путём рассуждений перейти от избежания вреда к минималистскому правилу, которое бы как можно меньше ограничивало возможность выбора. Не важно, насколько человеку интересна или не интересна данная тема, в любом случае большинство согласится, что закрытое ПО для микроволновки или лифта приносит гораздо менее беспокойства, чем операционная система с закрытыми исходниками. Игры с закрытыми исходниками гораздо менее беспокоят, чем текстовый процессор с закрытыми исходниками. Любое закрытое ПО, используемое для общения между людьми, вызывает беспокойство в частности о том, что его авторы могут использовать свою привилегированное положение для шпионажа или введения цензуры. За всем этим стоят вполне очевидные порождающие шаблоны, но чтобы их обсудить, необходимо сначала рассмотреть категории вреда от использования закрытого ПО.

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

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

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

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

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

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

Вооружившись этими тезисами, давайте рассмотрим случаи из жизни.

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

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

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

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

Единственный вывод, который можно из всего этого сделать, звучит так: противопоставлять что-то закрытому ПО, а также отказываться его использовать нужно в прямой пропорции ко вреду, который он наносит. Звучит просто и очевидно, так ? Но тем не менее, некоторые личности, (их мы не назовём, но укажем инициалы - Р, М и С), настаивают на том, что подобная позиция неэтична и беспринципна вплоть до роковых последствий. И эти личности выглядят абсолютно похожими на тех, кто удвоил усилия, но забыл о первоначальной цели. Но, действительно, наша "мягкотелая", "беспринципная" норма описывает в том числе и реальное поведение в том числе и тех, кто фанатично проповедует о дьявольской сути закрытого ПО. Но разве кто-то, даже среди самых стойких проповедников "свободного ПО", хотя бы пальцем пошевелил, чтобы ликвидировать закрытые прошивки для лифтов? Этого не происходит. Настольное ПО и мобильные ОС - вот их цели, и это логично соответствует нашим выводам, ведь это ПО гораздо более важно. И поэтому мы прагматично возвращаемся к сопоставительной оценке последствий вреда от закрытого ПО, даже если фанатики сами себе в этом и не признаются.

Имея на руках вышеуказанный анализ, мы в итоге приходим к заключению, которое вряд ли кого-то удивит: самые большие усилия по сопротивлению закрытому ПО необходимо оказывать на поле закрытого настольного ПО и закрытых мобильных операционных систем, поскольку именно от них исходит наиболее серьёзный вред и наиболее высокий положительный внешний эффект привязки. Мы можем расслабиться и не беспокоиться насчёт того, на каком ПО работают микроволновые печи и лифты. Нам нужно продвигать открытое ПО на домашние маршрутизаторы, поскольку они управляются всё более и более сложным и функциональным ПО. И если мы иногда поиграем в Angry Birds, Civilization или World of Warcraft, то это не станет актом ужасного лицемерия.

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

статья на OpenNet
оригинал
Как известно скоро грядет выход Windows 8, и "security boot" (о чем не так давно говорили). Matthew Garrett из Fedora поделился планами дистрибутива, на этот счет. Скорее всего Fedora напишет свой мини-загрузщик, который будет подписан в Microsoft за $99, равно как подписанным будет ядро и загружаемые модули(что накладывает некоторые ограничения).

Помимо всего прочего сборка собственных ядер, и дистрибутивов, перед собирающими открывает весьма странные перспективы:

Цитата
A lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
(с) Matthew Garrett

Как-то это все начинает напоминать Apple iPhone, когда за возможность писать/распростанять софт за теми же подписями надо идти в Apple. "jailbreak for PC" не за горами?
На выходных игрался с установкой Mandriva(и некоторых других дистрибутивов), на свой Air. Возможно, уважаемой публике будет интересно. Описание процесса первоначальной установки можно прочитать вот тут. Комментарии, пожелания и так далее приветствуются. Продолжение истории я думаю будет.
Вроде не первое апреля. Так что наверное правда

Цитата
Кей Сайверс (Kay Sievers), один из создателей подсистемы udev, объявил о решении по слиянию проектов udev и systemd в единое дерево исходных текстов. Все функции обслуживания устройств в директории /dev и обработка операций подключения и отключения внешних устройств, которые ранее выполняла подсистема udev, отныне будут непосредственно интегрированы в системный менеджер systemd.

Отдельно отмечается, что для дистрибутивов, которые не желают использовать systemd, будет обеспечена возможность использования и сборки udev, независимо от остальных частей systemd. Возможность обособленного использования udev заявлена как официально поддерживаемая функция. Опасения того, что в будущем udev невозможно будет использовать без systemd необоснованы, так как обособленный udev необходим для формирования образов initrd, не содержащих компонентов systemd. Целостность libudev API и совместимость udev из состава systemd с другими системами инициализации будет сохранена на протяжении длительного времени.

Таким образом, интеграция udev и systemd в основном приведёт к упрощению процесса разработки обоих проектов, которые во многом взаимосвязаны и развиваются по сути одной командой разработчиков. Слияние позволит избежать дублирования кода и сократит число зависимостей при сборке. Для дистрибутивов все изменения сведутся к тому, что для сборки udev придется использовать архив с кодом systemd, а не отдельный архив udev. После слияния systemd продолжит нумерацию версий udev, т.е. после 45 выпуска сразу будет представлена версия 184.

Новость на ОпенНете
Оригинал
18 Mar 2012
Цитата
Представляю Вашему вниманию мой перевод статьи разработчика ядра Linux Инго Молнара (Ingo Molnar), размещенной в двух частях на его странице в G+. Статья вызвала горячее обсуждение на зарубежных тематических новостных площадках, и, на мой взгляд, заслуживает Вашего внимания.

Удивительно, но главным недостатком дистрибутивов Linux для настольных ПК является их недостаточная свобода.

Помните, сколько уязвимостей и проблем с качеством Linux-систем было найдено в последнее время, в частности моими коллегами Linas Vepstas, Jon Masters, Linus Torvalds и многими другими, и информация, с которая я знакомился в обсуждениях, привела меня к выводу, что разработчики свободного ПО просто не осознают, в какую бездну провалились.

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

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

А как поступают остальные (большей частью не являющиеся свободными) конкуренты? Они движутся в прямо противоположном направлении: Apple/iOS и Google/Android имеют только около ста тесно интегрированных системных пакетов, которым уделяется огромное внимание и с которым работают как с одним целым проектом. Эти системы документируются и развиваются в десятки раз интенсивнее, чем это происходит с десятками тысяч пакетов в рамках каждого дистрибутива Linux. И гораздо легче задокументировать 10 миллионов строк кода, чем тысячи миллионов.

Для обеспечения должного разнообразия приложений на площадках Apple Store и Google Play сторонним разработчикам открывается полный доступ к внутренней структуре всей платформы и ведётся контроль над внедрением в систему дополнительных приложений. Как результат, большинство новых приложений добавляются с задержкой лишь в несколько дней (в пределе - несколько недель), а их обновления - в несколько часов (в редких случаях - нескольких дней), в общем, весь процесс происходит настолько быстро, насколько быстро над этим сам работает каждый проект. К тому же для iOS/Android нет практически никаких ограничений и препятствий для приложений, стремящихся попасть на официальные площадки по распространению - они попадают туда почти автоматически.

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

В итоге платформы iOS и Android способны поддерживать и управлять десятами тысяч приложений, число которых в перспективе легко может дорасти до миллиона.

(Да, мы все знаем случаи, когда Apple или Google банили те или иные приложения. Не слушайте, что они при этом говорят, а обращайте внимание вот на что: обе площадки содержат сотни тысяч приложений, и с точки зрения пользователей являются полностью открытыми системами распространения.)

Системы управления пакетами в Linux неплохи для задач корпоративного сектора (также имеющего иерархическую структуру и использующего централизованное планирование), но настольные Linux-дистрибутивы перестали расти уже 10 лет назад на отметке в тысячу пакетов...

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

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

То есть, для исправления текущей ситуации с Linux-дистрибутивами нам нужно полностью пересмотреть модель распространения ПО: уйти от церковного строя к рыночной системе. Конкретнее, понадобится учесть следующие технологические нюансы:

Необходимость принудительного использования безопасной "песочницы" для запуска приложений как на уровне пользователя, так и на уровне ядра. Сегодня установка нового пакета из репозитория - это компромисс и выбор из серии "все или ничего" в плане общей безопасности системы. Пользователи должны быть свободны в своём желании получать и запускать даже непроверенный код.
Плоская модель зависимостей пакетов (то есть, обновление одного пакета не должно принудительно заставлять обновлять другие (дублирование содержимого может быть устранено на другом уровне системы, например, на уровне файловой системы).
Гарантированная совместимость ABI с новыми версиями основной системы (то есть, при установке пакета он будет гарантированно работать в дальнейшем, не требуя от пользователя обновлений). Пользователи должны быть свободны от пресса необходимости постоянного обновления большей части дистрибутива.
Узловая сеть для увеличения пропускной способности каналов. Пользователи должны быть свободными от тяжеловесных и развесистых зависимостей приложений.
Криптографическая защищённость данных, а также наличие обзоров и официальных пометок о безопасности и достоверности приложения. Этим достигается важный пункт в системной безопасности: необходимые сертификаты для установки ПО понадобятся для корпоративного сервера так же, как сейчас для обычного пользователя, пожелавшего опробовать новую игру на смартфоне. Такое устройство системы распространения ПО позволит пользователям либо присоединиться к выбору большинства (положившись тем самым на количество установок), либо прислушаться к специалистам (и при выборе пакета исходить из авторитетного мнения экспертов), а также смешивать оба этих подхода.
На мой взгляд, Android маркет активно приближается к описанной модели функционирования, за исключением наличия узловой сети для загрузки пакетов и структурированной системы репутации приложений, к тому же Android, разумеется, никак не относится к свободному ПО.

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

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


Новость на LOR'е
Источник
Просмотры


12 Nov 2017 - 13:25


31 Jul 2017 - 16:17


25 Jan 2017 - 13:54
t.t


27 Dec 2016 - 0:09


13 Oct 2016 - 23:41


Друзья

117 сообщений
3rd November 2008 - в 23:12

133 сообщений
11th January 2012 - в 23:02
Просмотр всех друзей
RSS Текстовая версия Сейчас: 18th December 2017 - в 19:42




Rating@Mail.ru