Опубликован текст ГОСТ на СПО

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

На работе агитировать не получается, но Вам скажу: dcvs помогает решать многие проблемы и быстро находить ошибки.
Бумага рулит, особенно когда доказать что-то нужно, но чтобы поддержка проекта не превращалась в ад, диаграммы состояний, к примеру, менее затратно редактировать в электронном виде.

Я ничего не понял.

кроме юзеров, есть и разбирающиеся личности. уверен, что их мнение было бы ценным.

Этот ГОСТ писал наверняка человек недалёкого ума. ГОСТт ни о чём и не отражает суть СПО.

- вот такие требования: «Инфраструктура разработки и использования СПО должна включать в себя изолированную среду сборки программных пакетов (средства получения из исходного кода компьютерных программ бинарных файлов, непосредственно загружаемых в ЭВМ) и иные средства коллективной разработки».

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

Как я понял из этих цитат (по ссылке не ходил пока), начиная с момента принятия этого ГОСТа пути госструктур и многих разработчиков становятся абсолютно параллельными. М-да, «отсекают всё лишнее»...

Инфраструктура разработки и использования СПО должна включать в себя изолированную среду сборки программных пакетов

А как же Open Build Service? Тоже в пролёте?

Нафига тогда ГОСТ на СПО такой лепить, когда можно для всего ПО сделать?

Бардак =\ Начали за здравие...

Хм, боюсь, что в мелочах, но определения СПО в этом ГОСТе не стыкуются, например, со Столлмановским

п.3.6

использовать программу для ЭВМ в любых, не запрещенных законом

целях;

оговорка насчёт не запрещённых законом целях точно не входит в GPL. Смысл не в том, что GPL якобы разрешает нарушать закон (ничего такого нет), а в том, что нарушение (других) законов не является автоматически нарушением лицензии.

Но это мелкий штришок.

А вот п.4.1.1

СПО создается и применяется в целях формирования такого рынка,

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

Это что-то вообще даже не знаю, что это такое. Я смысла не понял совсем.

Но в целом, в ГОСТ повторено определение свободы (четырёх свобод) от Столлмана. Даже сделано примечание, что эффективно это всё если нет зависимости от товарных знаков.

И всё бы ничего, если бы этим и ограничились. Можно было бы, в целом, приветствовать наличие такого стандарта. Но вот далее, «Остапа понесло», и в п. 4.2 выдвинуты требования к инфраструктуре разработки и использования свободного программного обеспечения.

В принципе, в этих требованиях легко узнать общепринятые в мире СПО средства организации разработки многих проектов, в том числе дистрибутивов Linux.

Неясно только, с чего вдруг они стали обязательными и даже какое они имеют отношение к СПО? Особенно в части _использования_

систему контроля программ для ЭВМ, обеспечивающую

учет и реализацию прав на их использование, а также повторное использование компьютерных программ и их компонентов;

То есть, это что, для применения СПО на предприятии по замыслу разработчиков ГОСТ, надо городить систему учета лицензий на ЭВМ?!

- сбор и хранение разработок СПО, в том числе созданных за счет

бюджетных средств Российской Федерации, а также учет и реализацию прав на их использование;

Что-то мне начинает казаться, что дело попахивает тем, что начнут требовать учёт СПО и прав на использование.

Может, конечно, напрасно, но что-то тут возможно не додуманно.

Намекаете, что у дракона 2 головы?

К сожалению, ГОСТ Р 54593-2011 введённый впервые и вступающий в силу с 1 января 2012 г. не был размещён на официальном сайте Федерального агенства по техническому регулированию и метрологии непосредственно после утверждения Приказом № 718-ст от 6 декабря 2011 г. Текст стандарта должен быть опубликован не позднее, чем через месяц после его утверждения. Таким образом, публикация 6 января 2012 г. стандарта вступившего в силу с 1 января 2012 г. является соответствующей регламенту.

Читаешь, и вроде понятно - тут колёсы, там - насосы, но отчего то не покидает чувство, что тебя на^Wобманули.

Они там похоже путаются:

4.3 Сборочная среда свободного программного обеспечения

4.3.1

СПО использует принципы открытых систем, которые предполагают применение: - открытой сборочной среды,

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

Они просто сделали кучу из потока мыслей. Могли бы подумать и разнести на несколько отдельных стандартов.

А вот демонстрацию сборки в изолированной среде для какой нибудь Налоговой или Централизованной бухгалтерии я хотел бы увидеть на практике!

к стати. а почему это всё должно выглядеть как ГОСТ? почему бы этот документ не был выпущен как рекомендация или RFC?

В общем, моё мнение по этому ГОСТ. У него есть плюсы и минусы.

Плюсы: Введено на уровне ГОСТ, в общем-то, правильное определение того, что такое СПО.

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

Это что-то вообще даже не знаю, что это такое. Я смысла не понял совсем.

Это такой особый язык :) Суть фразы, как я её понимаю, сводится к освобождению рынка от vendor lock-in. Т.е. поставщиком СПО может быть любой, и если этот любой не является производителем СПО, это не должно ему мешать выполнять коммерческую работу по модификации и разворачивании и поддержке СПО.

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

Но вместо того, чтобы чётко оговорить именно это, они пустились в описание какого-то пакетного менеджера.

почему бы этот документ не был выпущен как рекомендация или RFC?

...юридический статус которых...? :)

Намекаете, что у дракона 2 головы?

Стараюсь обходиться без намёков :)

прощайте, Python, Lisp, Java и прочие, из кого нельзя получить «бинарных файлов, непосредственно загружаемых в ЭВМ»?

Думаю, что нет. Под программным пакетом в стандарте понимается пакет репозитория (deb, rpm и т.п.), см. пп. 3.19-3.21. Под средой сборки понимается собственно ОС, в которой можно из исходников собрать программные пакеты (п. 3.13). При этом среда, в которой набор репозиториев заранее ограничен (например, стандартные репы системы + возможно (?) репы разработчика программного продукта) называется изолированной (п. 3.15). Сделано это, похоже, для того, чтобы пакет с программой гарантированно мог установиться, не требуя левых репозиториев для разрешения зависимостей (типа убунтовских PPA). При этом под определение бинарного пакета (п. 3.20) подпадают, по сути, все не-src-пакеты.

В пункте 4.2.1 перечисляются требования к программной инфраструктуре: средства сборки программ и пакетов (т.е. всякие gcc, automake, autoconf, make, cmake, dpkg-buildpackage и т.д., и т.п.); наличие единого репозитория пакетов; пакетный менеджер (но, похоже, с функциями контроля лицензий на проприетарные программы); наличие главного багтрекера для решения проблем; последнее, правда, не расшифровал :)

Так что пока я никакой паники не вижу. Просто в ГОСТе описаны требования к готовой к широкому внедрению операционке [на базе Linux]. А вот винда этому ГОСТу ни капельки не соответствует :)

Вроде стандартизировать хотели нац. ОС, а про POSIX ни слова или надо было грепать ПОСИКС через iconv?

Суть фразы, как я её понимаю, сводится к освобождению рынка от vendor lock-in. Т.е. поставщиком СПО может быть любой, и если этот любой не является производителем СПО, это не должно ему мешать выполнять коммерческую работу по модификации и разворачивании и поддержке СПО.

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

...юридический статус которых...? :)

юридический статус RCF - не мешает им быть одними из главных документов в интернете.

так лучше бы этому нашему RFC с неким абстрактным определением СПО придали некий юридический статус, чем заколачивать неписанные законы фрисофтваре в граните ГОСТа.

да и вообще, СПО, фрисофтваре, для многих - это почти религия. Как можно стандартизировать религию? я с трудом себе это представляю.

создаётся впечатление, что разработчики всяких официальных бумаг специально избегают нормального языка, заменяя его каким-то жутким бюрократическим канцеляритом

В стране с раздутым бюрократическим аппаратом иначе и быть не может.

Неясно только, с чего вдруг они стали обязательными и даже какое они имеют отношение к СПО? Особенно в части _использования_

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

Да, каждая отдельная прикладная программа, хоть и открытая, должна также соответствовать данным требованиям. Иначе ведь разработчик может дать тупо бинарник, а исходники предоставить в заведомо невменяемом состоянии, из которых без специальных усилий и/или сторонних пакетов и библиотек собрать программу не получится. А так, используемая стандартная система должна быть обеспечена стандартными средствами компиляции и сборки пакетов и разработчики обязаны будут ими пользоваться, не?

Как можно стандартизировать религию?

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

Многие алгоритмы пишу на листке бумаги. Систему контроля версий не имею.

Для тебя имхо это будет значить всего лишь, что тебя по ГОСТ не стандартизируют

Он (ГОСТ) жеж теперь в требованиях каждого тендера будет прописан.

А разве плохо, что на тендерах наколенных поделок не будет у которых ни багзиллы ни поддержки нет?

а вот ещё такой момент: для ГОСТа должны указываться только константы, то есть то, что государство обязательно контролирует. как государство будет контролировать СПО? как оно будет контролировать Линуса Торвальдса, Ричарда М. Сталлмана и других?

для ГОСТа должны указываться только константы, то есть то, что государство обязательно контролирует

Это где написано?

Импортировать данных кадров к нам

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

А что не так? Да, разработчик должен подтвердить, что его программа должна собраться, используя только библиотеки и программы из стандартных, заранее оговоренных, репозиториев. Или он должен иметь право линковаться со всякими нестандартными нестабильными пакетами из репозитория Vasya Pupkin's PPA? А потом Вася пересоберёт пакет - и у всех всё рухнет.

Продавать за отдельные деньги :)

Не, с юридической точки зрения текстовый файл тоже бинарный.

троичные вообще не очень прижились...


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


я так понимаю, изолированная сборочная среда и прочее - это исковерканный пересказ этого пункта, + указание, что программа, для работы качающая проприетарную библиотеку - не СПО.

главный подвох - обязательность поддержки. Понятно, что поддержку может оказывать не автор, а производитель дистрибутива, так что здесь «наколенным поделкам» ничего не грозит, а вот может-ли по ГОСТу админ считать самого себя ответственным за поддержку СПО в своей частной конторе или таки обязательно покупать?

Государство приняло решение о внедрении свободных операционок, оно, по сути, - заказчик.

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

Иначе ведь разработчик может дать тупо бинарник, а исходники предоставить в заведомо невменяемом состоянии, из которых без специальных усилий и/или сторонних пакетов и библиотек собрать программу не получится.

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

А так получилось что-то неясное. Допустим я сделал СПО - программу в одну строчку на Perl ;-) Что я собственно, по этому ГОСТ теперь должен сделать, чтобы её куда-то официально передать или чтобы кто-то ей воспользовался?

А что не так?

Не так путаница в ГОСТ или то, что выглядит такой путаницей. То речь идёт про изолированную среду, то потом упоминается, что для СПО среда открытая.

Введено на уровне ГОСТ, в общем-то, правильное определение того, что такое СПО.

Неправильно. Это не «введено на уровне ГОСТ», это «в этом ГОСТе под СПО подразумевают [далее определение]».

Этот ГОСТ на самом деле НЕ ОПИСЫВАЕТ ЧТО ТАКОЕ СПО, не обязателен к применению и так далее. Он является является всего лишь некоторым набором требований к СПО, перечисленными в одном официальном документе. Это как тушеная говядина - есть китайская тушеная говядина. И есть российская тушеная говядина. И среди последней есть подгруппа - тушеная говядина, соответствующая ГОСТ ХХХХ. И только у последней есть шанс «попасть на госслужбу» в армию и т.п.

Основная задача обсуждаемого ГОСТа - чтобы всякие «органы», «компании», «учреждения» и прочие ХЕЗ Рога&Копыта при выставлении могли написать «соответствует ГОСТу такому то» (это и описывается в предложении «предназначен для применения в ...»)

Что это значит на самом деле:

1. кое-кто слил «разработчикам ГОСТа» информацию о готовящемся крупном, ОЧЕНЬ крупном тендере (новый год, новые бабки выделены, можно начинать пилить) на который будут выставлены короткие сроки (порядка двух-трех месяцев).

2. оные «разработчики ГОСТа», с целью отсечь конкурентов быстренько описали СВОЮ инфраструктуру (включая изолированную от всех разработчиков билд-ферму, VCS и трекер)

В результате, в тендере будет выдвинуто требование на «пакет СПО, соответствующего ГОСТ ****». Тендер уйдет нужным людям, те откатят 90%, на оставшиеся купят меринов и лексусов для любовниц и на сдачу с них наймут студентов, которые (естественно!) завалят проект и выдадут говно, которое в следующем году решат снова «заменить» и сделают второй попил.

То речь идёт про изолированную среду, то потом упоминается, что для СПО среда открытая.

Открытая среда - среда, в которой используются открытые стандарты и программы с открытыми исходниками.

Изолированная среда - среда, в которой доступный набор пакетов заранее оговорен.

В чём противоречие? Это ведь ортогональные понятия: среда может быть открытой, но не изолированной, может быть изолированной, но проприетарной, а может быть и открытой, и изолированной.

2. оные «разработчики ГОСТа», с целью отсечь конкурентов быстренько описали СВОЮ инфраструктуру (включая изолированную от всех разработчиков билд-ферму, VCS и трекер)

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

Тендер уйдет нужным людям, те откатят 90%, на оставшиеся купят меринов и лексусов для любовниц

Любовницы обойдутся. Надо и о себе подумать в кои-то веки.

Прочитал тред. С учётом того, как этот ГОСТ планируется использовать - всё написано правильно. Нужны и исходники, и среда для сборки, и поддержка. А как иначе?

Но вроде при первом прочтении я не заметил в описании чего-то очень специфичного в инфраструктуре разработки

это может быть не один производитель дистрибутива против остальных,
а групповые интересы производителей дистрибутивов против против мелких интеграторов/сисадминов, самостоятельно устанавливающих готовый CentOS/Fedorу или Debian/Ubuntу.

А как же Open Build Service? Тоже в пролёте?
С чего бы вдруг? Прикладываете сам Open Build Service с сорцам (а они доступны) - и, вроде бы, порядок. Разве нет?

может-ли по ГОСТу админ считать самого себя ответственным за поддержку СПО в своей частной конторе или таки обязательно покупать?

может. Тут мне кажется, больше будет вопрос о том, обязан ли поставивший СПО предоставлять поддержку. Вообще-то «да, обязан» я считаю правильным, но подвох-то где-то должен же быть?

Не вижу где именно.

ГОСТ нужен для прохождения тендера. В принципе ситуацию «Вот VDEL/KORK, который поствил RedHat/CentOS/Slackware и вот тулчейн, сорцы и поддержка» для госконторы или корпорации, где все-таки первично добыть нефть/запустить поезд/переключить святофор я считаю более нормальной, чем «вот админ, ему 20 лет, он бородат и студент, сделал нам за грант нечто на базе СПО о котором мы читали в журнале».

да, перечитал 1.0 и сабжевый документ. был неправ - извиняюсь. с данным гостом согласен и не усматриваю в нём попытку навязать своё мнение обществу

однако!

документ составлен с грамматическими, оформительскими и, в некоторых местах, лёгкими смысловыми ошибками.

также, вызывает смущение, что процесс сборки, описанного в данном ГОСТе дистрибутива, не упоминает LSB, а, опять таки, неточно копирует её. в связи с чем, считаю данный ГОСТ не готовым к принятию и требующим доработки.

документ составлен с грамматическими, оформительскими и, в некоторых местах, лёгкими смысловыми ошибками.

Увы, да.

Уже обсудили зачем это нужно? Я так и не понял. Я так же не понимаю чем, с точки зрения ГОСТ, отличается свободное ПО от несвободного? И что есть свобода по ГОСТу?

Вообще бред делить ПО на свободное и несвободное в техдоках подобного рода. Это на 90% политический вопрос. Неужели при смене лицензии на ПО (скажем, при покупке в случае если двойное лицензирование) придётся и ГОСТы менять? Тупняк.