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
Просмотров профиля: 200565*
Последнее посещение: Вчера, в 21:23
Часовой пояс: Jun 28 2017, в 08:20
12476 сообщений (3.64 за день)
Контактная информация
AIM Нет данных
Yahoo Нет данных
ICQ Нет данных
MSN Нет данных
Contact E-mail скрыт
* Просмотры профиля обновляются каждый час

Bizdelnick

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


Темы
Сообщения
Друзья
Содержимое
10 May 2017
Вознамерился поставить Slackware64 14.2 на виртуалку, а именно на qemu/kvm с virtio-диском. Скачал исошник, загрузился — устройства /dev/vda нет, модули virtio* не подгружены. Пытаюсь загрузить вручную — получается только с virtio_input, а остальные не хотят. modprobe ругается на "Exec format error", insmod — на "Invalid module format". Пробовал распаковывать модули virtio*.ko.gz, но ничего не меняется. Нагуглились костыли типа пересобрать ядро со вкомпиленными драйверами, пересобрать initrd с ними или выдрать модули из пакета. Но — вот же они лежат, значит в initrd их уже засунули. Почему не цепляются-то?

Upd. Уточнение: virtio_input подгружается только через insmod, а через modprobe тоже не хочет, потому что тот пытается сперва загрузить проблемный virtio_ring.
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. Для голосования на сайте РОИ необходимо пройти аутентификацию через ЕСИА — единую систему идентификации и аутентификации сайта Госуслуг. Для новых учётных записей требуется подтверждение личности в одном из центров обслуживания пользователей.
Просмотры


10 Jun 2017 - 14:02


3 Jun 2017 - 0:51


26 May 2017 - 16:43


21 May 2017 - 19:15


23 Apr 2017 - 22:30


Друзья
Друзей нет.
RSS Текстовая версия Сейчас: 28th June 2017 - в 08:20




Rating@Mail.ru