Ну я же не просто так написал «на статью», а не на опубликованные результаты.
Только это не поможет опубликовать эту же статью в Open Access даже в другой верстке. Можно написать другую статью с теми же результатами и опубликовать в открытом доступе ее, но не оригинальный текст/графику.
> Я так понимаю, за вымя взяли сотрудников РАН и иже с ним?
Нет. Никто из причастных пока не понимает кто, кого и за что взял, так как правила в этой области по своей сути не менялись много лет (формы документов да, менялись).
Если в организации процедура получения этих актов поставлена нормально, то чистое время оформления этого акта определяется по большей части геометрическими размерами организации, так как люди, чьи подписи необходимы могут работать в разных корпусах.
> А прогон статей через первый отдел — это не попытка «засекретить»? Тогда что?
Вот честно говоря, я не знаю, что нужно такое в области фундаментальных исследований наисследовать, чтобы попасть на проверку не во внутреннюю комиссию, а аж в целый первый отдел. Может быть Вы меня просветите, раз утверждаете, что все статьи проходят через первый отдел?
Вы поступали в бакалавриат?
Если да, то у Вас было две отсрочки, а не одна.
Там такая вещь.
Если специалист — отсрочка на время обучения. Если после этого поступить в аспирантуру, то дается отсрочка по аспирантуре. Если в магистратуру, то отсрочка не дается (второе высшее не дает отсрочки).
Если бакалавр — отсрочка на время обучения. Если после этого поступить в магистратуру, то дается вторая отсрочка на время обучения в магистратуре (магистратура после бакалавриата не считается вторым высшим).
А вот в аспирантуру можно поступать сколько угодно раз и каждый раз будет новая отсрочка.
> так вот это что-то и оборачивается… Просто надо стараться изолировать код приложения (бизнес логика и т.д.)…
Так вот это что-то может быть нашим приложением. Boost очень низкоуровневая штука, чуть выше чем стандартная библиотека языка по сути. А как можно эффективно и со смыслом изолировать бизнес-логику, например, от контейнеров я не знаю.
Конечно, если под библиотеками понимать что-то более высокоуровневое, например, Qt для GUI, то в этом случае отделять бизнес-логику от собственно GUI вполне понятно как и необходимо.
> так что нам не составляет труда завернуть то что нам нужно в интерфейс
Чтобы не быть голословным, предложите, пожалуйста, вариант оберток для любой библиотеки из Boost. А потом, скажите, что Вы будете делать, когда после стабилизации и усовершенствования библиотека из Boost попадет в стандарт. Будете поддерживать обертки поверх стандарта (но зачем)? Или с печальным видом избавляться от них переходя обратно на API, который был практически изначально?
> Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос
Я выбрал тот язык, который для моих задач подходит наиболее хорошо. Скажу даже больше, где-то рядом все еще живее всех живых Fortran (и приносит разработчикам компиляторов денег не меньше чем С++, кстати).
> стараются использовать ссылки на репозитории, сабмодули и прочее.
Перечитайте, пожалуйста, всю ветку. Возможно, тогда Вы увидите, что я про это практически с самого начала говорю.
> выгоднее использовать средства аля Docker
И об этом я тоже писал чуть выше…
К сожалению еще не для всех продуктивных задач докер подходит, но работы в этом отношении идут и перспективы меня радуют.
> Нет, просто
См. выше про фреймворки, которые тоже библиотеки по сути. Завернуть фреймворк в обертку — это по сути написать свой.
> И вот вы сначала перепрыгнули
Смотрим начало этой ветки:
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.
> Мне кажется это забота авторов библиотек.
Клиенты не к авторам библиотеки придут, если у них что-то сломается, а к Вам.
> Я стараюсь не использовать трэш,
> Не используйте библиотеки не практикующие семвер,
Интересно Вы разработчиков стандарта С++ сейчас обозвали…
К сведению, среди разработчиков Boost есть немало разработчиков стандарта С++.
> закрываю это оберткой
> оборачивайте все нестабильное
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Посмотрите, как собираются RHEL или SLE и сколько патчей там есть к поставляемым библиотекам и приложениям. Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
Если только так, значит Вам не критична стабильность API/ABI используемых библиотек, раз Вы можете позволить себе постоянно переходить на новые версии без бекпортирования исправлений и патчинга багов.
fork-patch-pull-request — это хорошо и правильно, но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами и Вам придется все делать руками для своей версии.
P.S. Я если что не про Web и php сейчас, а про более общий случай.
На мой взгляд интересная заметка автора библиотеки SObjectizer о SVN, нелюбви к нему и степени владения инструментом тех, кто его не любит: http://eao197.blogspot.ru/2015/09/progflame-svn.html
Случаев, когда реально терялся компилятор или ОС я что-то припомнить не могу. С библиотеками же такое происходит и люди видимо с этим сталкивались. Даже если теряется не сама библиотека, может исчезнуть из апстрима ее старая версия, которая для тестов старой версии ПО потребуется или еще для чего-то подобного.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
Люди готовые работать кем угодно от безысходности вряд ли быстро уйдут из компании даже в случае постоянных переработок и перегрузок. Думаю, это была одна из решающих причин найма этой девушки, а не круглая сумма лишь позволила увидеть эту безысходность…
Почему такой вывод. Формулировка «столько мне требуется для оплаты и проживания в месяц», говорит о том, что цель только прожить этот месяц. Из ответа не видно желания копить деньги на какую либо глобальную цель (например, на отпуск или хобби) или хотя бы на создание собственной финансовой подушки безопасности (куда могла бы пойти сумма округления).
> Ну судя по вашей логике, нужно все сразу.
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
> Просто вы не улавливаете мою иронию.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Скажите, пожалуйста, Вы читать умеете?
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Исчезновение библиотек я видел (например, поищите исходники PathScale и библиотек, которые они выкладывали на гитхаб и которые потом исчезли). Исчезновение всего линукса слишком маловероятно. Это во первых.
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
Так в том то и дело, что храню!
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.
Да, признаю, что я изначально высказался слишком категорично.
Только это не поможет опубликовать эту же статью в Open Access даже в другой верстке. Можно написать другую статью с теми же результатами и опубликовать в открытом доступе ее, но не оригинальный текст/графику.
Нет. Никто из причастных пока не понимает кто, кого и за что взял, так как правила в этой области по своей сути не менялись много лет (формы документов да, менялись).
Если в организации процедура получения этих актов поставлена нормально, то чистое время оформления этого акта определяется по большей части геометрическими размерами организации, так как люди, чьи подписи необходимы могут работать в разных корпусах.
Что же касается реплик господина Kalobok.
> Просто для сравнения, как это делается у цивилизованных людей: публикации по результатам исследований, выполненных с участием бюджетных денег, должны выкладываться в открытый доступ.
Большинство рейтинговых журналов за возможность открытой публикации статьи требует заплатить немаленькую сумму. А если статья будет только в журнале по подписке — то все бесплатно.
Кроме того, по Вашей ссылке очень занятная надпись есть: «Copyright © 2013 Elsevier Inc. All rights reserved.» Права на статью не у авторов исследования, не у научной организации, а у Издательства этой публикации!
> А прогон статей через первый отдел — это не попытка «засекретить»? Тогда что?
Вот честно говоря, я не знаю, что нужно такое в области фундаментальных исследований наисследовать, чтобы попасть на проверку не во внутреннюю комиссию, а аж в целый первый отдел. Может быть Вы меня просветите, раз утверждаете, что все статьи проходят через первый отдел?
Если да, то у Вас было две отсрочки, а не одна.
Там такая вещь.
Если специалист — отсрочка на время обучения. Если после этого поступить в аспирантуру, то дается отсрочка по аспирантуре. Если в магистратуру, то отсрочка не дается (второе высшее не дает отсрочки).
Если бакалавр — отсрочка на время обучения. Если после этого поступить в магистратуру, то дается вторая отсрочка на время обучения в магистратуре (магистратура после бакалавриата не считается вторым высшим).
А вот в аспирантуру можно поступать сколько угодно раз и каждый раз будет новая отсрочка.
А в чем это выражается?
И, скажите, пожалуйста, какие настройки Ваших 10GE карточек Вы используете?
Так вот это что-то может быть нашим приложением. Boost очень низкоуровневая штука, чуть выше чем стандартная библиотека языка по сути. А как можно эффективно и со смыслом изолировать бизнес-логику, например, от контейнеров я не знаю.
Конечно, если под библиотеками понимать что-то более высокоуровневое, например, Qt для GUI, то в этом случае отделять бизнес-логику от собственно GUI вполне понятно как и необходимо.
Чтобы не быть голословным, предложите, пожалуйста, вариант оберток для любой библиотеки из Boost. А потом, скажите, что Вы будете делать, когда после стабилизации и усовершенствования библиотека из Boost попадет в стандарт. Будете поддерживать обертки поверх стандарта (но зачем)? Или с печальным видом избавляться от них переходя обратно на API, который был практически изначально?
> Вы же выбрали язык, где нет нормального менеджера пакетов, потому там царит хаос
Я выбрал тот язык, который для моих задач подходит наиболее хорошо. Скажу даже больше, где-то рядом все еще живее всех живых Fortran (и приносит разработчикам компиляторов денег не меньше чем С++, кстати).
> стараются использовать ссылки на репозитории, сабмодули и прочее.
Перечитайте, пожалуйста, всю ветку. Возможно, тогда Вы увидите, что я про это практически с самого начала говорю.
> выгоднее использовать средства аля Docker
И об этом я тоже писал чуть выше…
К сожалению еще не для всех продуктивных задач докер подходит, но работы в этом отношении идут и перспективы меня радуют.
См. выше про фреймворки, которые тоже библиотеки по сути. Завернуть фреймворк в обертку — это по сути написать свой.
> И вот вы сначала перепрыгнули
Смотрим начало этой ветки:
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Вы знаете компиляторы для PHP? Я нет (HHVM не совсем то). И далее по ветке.
Клиенты не к авторам библиотеки придут, если у них что-то сломается, а к Вам.
> Я стараюсь не использовать трэш,
> Не используйте библиотеки не практикующие семвер,
Интересно Вы разработчиков стандарта С++ сейчас обозвали…
К сведению, среди разработчиков Boost есть немало разработчиков стандарта С++.
> закрываю это оберткой
> оборачивайте все нестабильное
Ну то есть полностью перепроектировать и переписать используемую библиотеку.
Посмотрите, как собираются RHEL или SLE и сколько патчей там есть к поставляемым библиотекам и приложениям. Даже если совместимость необходимо поддерживать не 10 лет, а всего год, то применяемые ими методики бекпортирования и багфиксинга придется применять и вам…
fork-patch-pull-request — это хорошо и правильно, но исправления войдут только в новую версию, которая может быть несовместима с используемой Вами и Вам придется все делать руками для своей версии.
P.S. Я если что не про Web и php сейчас, а про более общий случай.
> Народ использует систему версионного контроля как резервное хранилище.
А почему версии библиотек не должны отслеживаться системами версионного контроля?
Наверное даже спрошу так, почему версия библиотеки в Вашем понимании — это только строка вида 1.2.3?
Вы никогда не патчили библиотеки, не бекпортировали в них изменения из аптрима без обновления всей библиотеки для сохранения ABI/API? По всем этим причинам для меня версии библиотек это не только цифры, но и весь ее код, который должен как минимум логически храниться или быть доступным в репозитории проекта.
Почему такой вывод. Формулировка «столько мне требуется для оплаты и проживания в месяц», говорит о том, что цель только прожить этот месяц. Из ответа не видно желания копить деньги на какую либо глобальную цель (например, на отпуск или хобби) или хотя бы на создание собственной финансовой подушки безопасности (куда могла бы пойти сумма округления).
Ну раз все сразу, то в случае одновременного исчезновения Intel, Microsoft, GNU FSF и Apple, я думаю мне нужно будет искать другую отрасль (скорее всего земледелие), а не думать о том, что будет с моими проектами.
С библиотеками же все проще. Наглядный пример такого исчезновения я Вам привел (с гитхаба кстати).
> А представьте как будет удобно, если вы зальете в проект сразу весь iso-образ ОСи с накатанным на нее проектом и всеми зависимости. Клац одну кнопку и у вас готовый к работе сервер )
И это тоже есть. Все готовые образы виртуальных машин и докер-контейнеры сложены в файловом репозитории. Да, можно довести до одного клика, но в условиях множественных окружений это не имеет смысла на машине разработчика, а на билд-сервере все собирается в один клик на всех окружениях, там это имеет смысл.
> У вас composer перерабатывает и вы не хотите платить ему сверхурочные?
У меня очень ограниченный composer, так как Web-интерфейсы занимают меньшую часть моего времени.
Но даже в случае с composer я предпочитаю не перерабатывать сам и упрощать сервисные задачи. Лишние N Мб зависимостей в репозитории меня при этом не пугают, тем более, что их обновления идут в отдельных коммитах и не замусоривают историю.
Это не похоже на иронию. Это похоже исключительно на глупость, уж простите меня за резкость.
> При отсутствии библиотеки вам нужно будет переписать часть проекта, а при отсутствии интерпретатора/компилятора — весь проект. Так где же тут слабая связь?
При отсутствии, например, Boost проект будет проще переписать с нуля или написать свой аналог буста.
А что касается компиляторов, то какого из 5 разных от 5 разных вендоров? Или всех сразу?
> Что мешает сложить туда же ваши зависимости?
Удобство использования. Один git clone/svn checkout и с проектом можно работать, а с composer придется выполнять дополнительные действия.
Для защиты от проблем с линуксом и интернетом у меня линуксы сложены в отдельный репозиторий на файловом сервере. Прочитайте уже перевод слово репозиторий, чтобы перестать ассоциировать его исключительно с системами управления версиями.
Еще раз повторюсь, что в проект имеет смысл складывать сильно связанные компоненты. Слабо связанные имеет смысл хранить, но не в проекте. Тот факт, что свой проект, который я сейчас подразумеваю собирается более чем в 30 окружениях, то каждое отдельное окружение слабо связано с проектом.
Библиотека же может использоваться только конкретной протестированной версии, так как ABI-совместимость и все такое — это сильно связанная компонента.
> github.com/pathscale?
Там есть исходники компилятора, который они выкладывали?
Оно было здесь: http://www.path64.org/ и https://github.com/path64, но исчезло и сылки с path64.org теперь ведут в никуда (например, github.com/path64/compiler).
Во вторых, мой софт использует конкретную версию конкретной библиотеки, ее имеет смысл положить рядом. Компилируется же он в трех десятках окружений гарантированно и я не знаю в скольки еще линуксах скорее всего. Их не имеет смысла держать совсем рядом, при этом, как я уже писал выше, все компоненты окружений и сборки сборочных виртуальных машин аккуратно сложены в отдельном каталоге на файловом сервере.
Не путайте техническое разбиение инфраструктуры на репозитории, сабмодули и прочее с организационной стороной. С организационной точки зрения в моем репозитории есть и компиляторы.