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

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

Профиль
Фотография
Опции
Опции
О себе
Bizdelnick не указал(а) ничего о себе.
Личная информация
Bizdelnick
grammatikführer
33 от роду
Мужской
Место жительства не указано
Дата рождения: Апр-11-1984
Интересы
Нет данных
Другая информация
Операционная система: Debian GNU/Linux
JID: nebotanik@jabber.ru
Город: Санкт-Петербург
Статистика
Регистрация: 11-February 08
Просмотров профиля: 196170*
Последнее посещение: Вчера, в 18:58
Часовой пояс: Apr 29 2017, в 02:48
12320 сообщений (3.66 за день)
Контактная информация
AIM Нет данных
Yahoo Нет данных
ICQ Нет данных
MSN Нет данных
Contact E-mail скрыт
* Просмотры профиля обновляются каждый час

Bizdelnick

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


Темы
Сообщения
Друзья
Содержимое
29 Mar 2017
Мне никогда не нравились сборочные системы, позволяющие жёстко привязаться к конкретной версии какой-то зависимости. Наверное, одной из первых таких, и точно одной из самых популярных является Maven. И вот свежая новость о том, к чему это приводит. TL;DR: исправленная уязвимость в библиотеке приводит к тому, что все проекты, где забыли поднять версию зависимости, остаются уязвимыми. Если таким образом уязвимость распространяется рекурсивно на другие библиотеки и фреймворки, в итоге она попадает в программы, зависящие от уязвимой библиотеки только опосредованно, для разработчиков которых может вообще оказаться полной неожиданностью, что данная уязвимость может иметь к ним какое-то отношение. Итог — куча дырявого софта, использующегося повсеместно, в данном случае — 2600 только открытых проектов. От взлома пострадало, в частности, муниципальное транспортное агентство Сан-Франциско — год спустя после обнародования информации об уязвимости.
Вот так вот, дорогие любители maven/pip/node/godep/cargo/что-там-вы-используете.
26 Mar 2017
https://bugzilla.mozilla.org/show_bug.cgi?id=1247056
https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
Прелестно. Теперь не осталось ни одного браузера, в котором бы всё работало, можно было бы отключить шпионские фичи, и который не был бы собран с дырявым вебкитом.
24 Mar 2017
Сегодня внезапно psi-plus отказался соединяться с некоторыми серверами, в том числе гугловскими, заявляя, что не доверяет сертификатам, потому что они якобы самоподписанные. При этом к jabber.ru подключается. Проверил сертификаты openssl'ем, цепочки в порядке. Последнее обновление было таким:
Код
Start-Date: 2017-03-24  06:42:46
Commandline: /usr/bin/unattended-upgrade
Upgrade: python-samba:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), winbind:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba-dsdb-modules:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), libnss-winbind:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba-common-bin:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba-libs:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), smbclient:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), libpam-winbind:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), libwbclient0:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba-vfs-modules:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), samba-common:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4), libsmbclient:amd64 (4.2.14+dfsg-0+deb8u2, 4.2.14+dfsg-0+deb8u4)
End-Date: 2017-03-24  06:43:14
Тут всё связано только с самбой. Пакет ca-certificates не обновлялся с декабря. В чём может быть дело? Кто-нибудь ещё такое наблюдает?
15 Feb 2017
На сайте «Российская общественная инициатива» началось голосование по предложению об открытии исходных кодов нового программного обеспечения, разработка которого оплачивается из бюджетных средств, на условиях свободных лицензий. Если инициатива наберёт в течение года 100000 голосов «за», она поступит на рассмотрение экспертной комиссии федерального уровня.
По сути инициатива близка к нормам, действующим с 2016 года в США и Болгарии, но является более всеобъемлющей. В Болгарии открываются только разработки, связанные с системой «электронного правительства», а в США пока запущена только пилотная программа по открытию кодов, в рамках которой публикуется в обязательном порядке не менее 20% новых разработок.

Что конкретно предлагается
Предложение не сводится к простой публикации исходных кодов, которая сама по себе вряд ли дала бы заметный положительный эффект. Оно включает также поддержание публичной инфраструктуры разработки и подготовку регламентов для разработчиков, которые способствовали бы формированию устойчивого сообщества (если, конечно, найдётся достаточное количество заинтересованных лиц).
Публичная инфраструктура должна включать в себя систему контроля версий, систему отслеживания ошибок, а также систему автоматического тестирования и рецензирования предложенных изменений. На первый взгляд может показаться, что поддержание такой инфраструктуры существенно увеличит нагрузку на разработчиков, однако следует учитывать два нюанса. Во-первых, в достаточно крупных проектах все элементы такой инфраструктуры как правило уже присутствуют, хотя и не являются публичными. Затраты на поддержание публичной инфраструктуры немногим выше, чем на поддержание закрытой, если вообще отличаются (вряд ли стоит ждать очень высоких нагрузок, но и про возможность DDoS-атак забывать не следует). Во-вторых, ничто не мешает воспользоваться одной из многочисленных площадок, предоставляющих такую инфраструктуру как SaaS, в том числе бесплатно для открытых пректов (GitHub, GitLab и т. п.).
Регламенты для разработчиков не должны позволять оставлять без внимания тех, кто хочет тем или иным способом принять участие в разработке, и может стать активным членом сообщества. Это подразумевает реакцию на сообщения об ошибках в разумные сроки (в зависимости от важности ошибки), рецензирование предложенных изменений и принятие аргументированных решений об их принятии или отклонении.
В инициативе также идёт речь о необходимости подготовки новой редакции стандарта ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение. Общие положения». Очевидно, что при реализации инициативы без отсылок к нему не обойтись, а он содержит ряд существенных недоработок. Изначально этот стандарт разработан небольшой группой специалистов за закрытыми дверями в рамках работы по «национальной программной платформе» и описывает ровно то, что они пытались продать — дистрибутив GNU/Linux с сопутствующей инфраструктурой. Отмечаются два основных момента, требующих обязательного исправления. Первый касается определения самого базового понятия — исходного кода. В стандарте под ним понимается «компьютерная программа в текстовом виде на каком-либо языке программирования», а под такое определение подходит код, подвергшийся различным преобразованиям: обфусцированный, минифицированный, сгенерированный из представления на более высокоуровневом языке или транслированный на другой язык. В качестве более удачного варианта предлагается определение, позаимствованное из текста GNU GPL, согласно которому исходный код — это форма произведения, являющаяся предпочтительной для внесения изменений. Второй момент связан с разделом, описывающим инфраструктуру разработки ПО, а точнее с тем, что именно об инфраструктуре разработки в нём нет ни слова, поскольку авторы стандарта занимались не разработкой, а интеграцией, упаковкой и распространением готового ПО. В данный раздел предлагается включить описание инфраструктуры, упоминавшейся выше.

Зачем всё это
В качестве главного аргумента в пользу инициативы приводится возможность снижения стоимости разработки за счёт эффективного повторного использования кода. На данный момент разработчики вынуждены повторять одну и ту же работу, реализуя стандартизированные в России алгоритмы и протоколы. В качестве примера можно упомянуть пресловутые ГОСТовские криптоалгоритмы. Стимула делиться своими наработками ни у кого нет, в результате каждый продолжает использовать свою реализацию, зачастую не отличающуюся высоким качеством, содержащую многочисленные ошибки и уязвимости. В долгосрочной перспективе более выгодным было бы иметь небольшое число свободных реализаций, доступных для независимого аудита и открытых к приёму исправлений. Это бы не только снизило стоимость разработки приложений, но и повысило качество кода (разумеется, при вовлечении достаточно большого числа разработчиков — помните закон Линуса?).
Нередки также ситуации, когда в бюджетных учреждениях для собственных нужд разрабатываются небольшие «наколенные» программы. Они могли бы представлять интерес и для других учреждений того же профиля, но об их существовании просто не знают, и способа их распространения не предусмотрено. Совместное использование и совместная доработка таких программ обошлись бы в масштабах страны намного дешевле, а качество их повысилось бы.
Другой, не упоминающийся в тексте инициативы, положительный эффект — возможность частным лицам и организациям безвозмездно пользоваться программным обеспечением, разработку которого они уже оплатили своими налогами. Возможно, доля разрабатываемого для государства софта, который мог бы представлять интерес широкому кругу лиц, сравнительно невелика, но она есть.
Ну и, конечно, нельзя забывать о таком аспекте, как повышение прозрачности разработки, то есть возможности общественного контроля расходования бюджетных средств. В публично доступной системе контроля версий можно без труда оценить как объём проделанной работы, так и то, кем конкретно она выполнялась. Это сильно затруднит необоснованное завышение цен на разработку, а также формирование цепочек субподрядчиков.

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


P. S. Для голосования на сайте РОИ необходимо пройти аутентификацию через ЕСИА — единую систему идентификации и аутентификации сайта Госуслуг. Для новых учётных записей требуется подтверждение личности в одном из центров обслуживания пользователей.
31 Jan 2017
Дано: ноутбук Dell, на который была предустановлена Ubuntu 14.04. Из неё были выпилены Unity и делловская шпиварь (надеюсь, вся), поставлен MATE, система обновлена до 16.04. Средствами MATE настроен комфортный уровень яркости подсветки 75% при работе от батареи. Однако примерно раз в две минуты яркость сбрасывается до 25%. Поскольку работаю в основном от сети, это не сильно беспокоит, но всё-таки достало. Помогите найти, кто это делает. Обнаружил установленный tlp, но он вроде как яркость не трогает, оставляя это DE. Кто ещё это может быть? Или это глюк MATE?
Просмотры


23 Apr 2017 - 22:30


17 Apr 2017 - 14:32


9 Apr 2017 - 21:29


5 Apr 2017 - 14:04


25 Mar 2017 - 18:35


Друзья
Друзей нет.
RSS Текстовая версия Сейчас: 29th April 2017 - в 02:48




Rating@Mail.ru