LINUX.ORG.RU

Вышел GuixSD-0.10

 , , ,


0

3

29 марта 2016 года выпушена новая версия GuixSD — 0.10

Изменения:

  • «Пересадочный» (grafting) механизм применения обновлений безопасности исправлен и теперь считается работоспособным
  • Пакеты в бинарном виде теперь скачиваются по HTTPS и с быстрейшего зеркала
  • Большее количество пакетов теперь собираются бит-в-бит. Среди них glibc, Perl, пакеты Emacs'а и пакеты Python'а. Больше подробностей смотри по ссылке «Подробности»
  • Добавлен GNOME
  • Добавлено 639 пакетов, примерно столько же обновлено. Обновление пакетов теперь гораздо проще благодаря importer'ам и auto-updater'ам
  • Множество исправлений, улучшений документации и плюшек для Emacs'а

    GuixSD — операционная система с пакетным менеджером Guix, официально поддерживается FSF.
    Guix — функциональный пакетный менеджер с множеством уникальных свойств.

    В отличие от NixOS в GuixSD для настройки системы используется Guile (реализация Scheme — одного из диалектов Lisp'а).

>>> Подробности

★★★★★

Проверено: fallout4all ()

Ответ на: Если да, но нет от Camel

Re: Если да, но нет

Затем что появился стабильный vasyan-app1.0.2(3, 4 и т.д.). Было бы логичнее, если бы nix и guix(раз они заявляют что dependency hell не пройдет) или же разворачивали все необходимое в один каталог с приложением, или же для общих файлов был один каталог типа /store/share-files

anonymous ()
Ответ на: Re: Если да, но нет от anonymous

Пусть цветут все цветы

Затем что появился стабильный vasyan-app1.0.2(3, 4 и т.д.).

Это ни в коей мере не делает необходимым удаление /store/asfasfas90f-vasyan-app1.0.1, потому что vasyan-app1.0.2 будет стоять в /store/dfkjdfkdj-vasyan-app1.0.2 и никаким образом не будет вмешиваться в работу vasyan-app1.0.1 и всех кто от него зависит. Если parashad зависит от vasyan-app, то parashad собирается с указанием на конкретную версию vasyan-app (например asfasfas90f-vasyan-app1.0.1). Если после этого поставить vasyan-app1.0.2, то можно пересобрать parashad и получить

/store/cviciass-parashad
/store/ibiasdki-parashad

Оба будут работоспособными. Если у нас не прописано, что мы обязательно хотим сохранить тот parashad, который лежит в cviciass, то сборщик мусора удалит старый vasyan-app и parashad, потому что они оба не нужны. Если же parashad не заработал с новым vasyan-app, то можно прописать, что нам нужна именно эта старая версия parashad, тогда сборщик мусора не удалит старый parashad и старый vasyan-app. Guix гарантирует что parashad будет работать так же как и раньше, а не хуже или лучше.

Было бы логичнее, если бы nix и guix(раз они заявляют что dependency hell не пройдет) или же разворачивали все необходимое в один каталог с приложением, или же для общих файлов был один каталог типа /store/share-files

Ничуть не логичнее.

Camel ★★★★★ ()
Последнее исправление: Camel (всего исправлений: 1)
Ответ на: Пусть цветут все цветы от Camel

Re: Пусть цветут все цветы

Ничуть не логичнее.

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

PC-BSD (операционная система на базе FreeBSD) справляется с dependency hell путём размещения пакетов и зависимостей в самодостаточные директории-контейнеры, избегая таким образом повреждения системных библиотек при обновлениях или иных их изменениях. Система PC-BSD использует «PBI» (Push Button Installer) как основной пакетный менеджер.

Почему-то думал что в NixOS и GuixSD сделали так же. В убунте тоже будут пилить что-то подобное.

anonymous ()
Ответ на: Re: Пусть цветут все цветы от anonymous

Не лучше

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

Нет, не лучше.

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

путём размещения пакетов и зависимостей в самодостаточные директории-контейнеры

То есть в каждую директорию кладётся и программа и все зависимости? Это же практически статическая линковка.

Camel ★★★★★ ()
Последнее исправление: Camel (всего исправлений: 1)
Ответ на: Не лучше от Camel

Re: Не лучше

Во-первых, от такого разделения нет никакой пользы.

Обоснуй подробнее.

То есть в каждую директорию кладётся и программа и все зависимости? Это же практически статическая линковка.

Не знаю, не пользовался. Однако думается мне, что это весьма удобно и схоже с контейнерами(не зря же они обрели такую большую популярность).

И все таки почему в NixOS и GuixSD нету ада зависимостей, библиотеки то используют общие?

P.S. В профиле у тебя написано, что ты ипользуешь NixOS.

anonymous ()
Ответ на: Re: Не лучше от anonymous

Обоснование

Обоснуй подробнее.

Если бы от этого была бы какая-то польза, то её можно было бы заметить. А раз её нельзя заметить, значит пользы нет.

Один и тот же пакет может содержать в себе и собственные бинарники и библиотеки, которыми он пользуется сам, но разрешает пользоваться и другим. Стоит ли его помещать в /shared ? А если его библиотеками фактически никто кроме него не пользуется, то стоит ли перемещать в /shared или оставить в /store?

Однако думается мне, что это весьма удобно и схоже с контейнерами(не зря же они обрели такую большую популярность).

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

Guix во многом решает те же проблемы что и контейнеры, но делает это лучше и экономнее.

Camel ★★★★★ ()
Ответ на: Обоснование от Camel

Re: Обоснование

А если его библиотеками фактически никто кроме него не пользуется, то стоит ли перемещать в /shared или оставить в /store?

Тоже об этом думал, тоже правильно. А если нам например очень необходимо удалить /store/sdgfsdgsdg-vasyanapp1.0.1, бибилиотеки которого использует /store/dgsdgsdgkl-jigurda12.0, vasyanapp таки удалится? Если да, то как тогда с библиолеками, которые использует jigurda12.0?

целыми виртуалками, потому что только так удалось разрулить зависимости

Хоть даже так, потому что этот зоопарк уже всех достал.

Guix во многом решает те же проблемы что и контейнеры, но делает это лучше и экономнее.

Почему его тогда или NixOS мало кто использует?

anonymous ()
Ответ на: Re: Не лучше от anonymous

Поправил

В профиле у тебя написано, что ты ипользуешь NixOS.

Спасибо за напоминание, поправил.

Camel ★★★★★ ()
Ответ на: Re: Обоснование от anonymous

Сборщик джигурды

А если нам например очень необходимо удалить /store/sdgfsdgsdg-vasyanapp1.0.1, бибилиотеки которого использует /store/dgsdgsdgkl-jigurda12.0, vasyanapp таки удалится? Если да, то как тогда с библиолеками, которые использует jigurda12.0?

Что значит «нам очень необходимо удалить vasyan-app1.0.1»? Зачем нам его удалять? Если вы хотите пользоваться vasyan-app1.0.2, то просто поставьте vasyan-app1.0.2 и пользуйтесь, vasyan-app1.0.1 от этого не сломается. И jigurda12.0 тоже не сломается, потому что продолжит исползовать библиотеки из vasyan-app1.0.1.

Почему его тогда или GuixSD мало кто использует?

Инертность мышления, раз. Сложности с портированием ПО низкого качества и всяких грязных трюков, два. Все привыкли собирать deb'ы для Ubunt'ы хер знает как, не считаясь с зависимостями, потому что ряд пакетов «есть всегда» и т.п. В общем от Ubunt'ы и прочих ждут определённого поведения не задумываясь почему оно должно быть таким и может ли оно в каких-то случаях быть другим. Guix этого не позволяет, хочешь поставить программу (новую, написав для неё scm) — аккуратно вписывай все зависимости, не впишешь — не соберётся. Но вот если однажды вписал, то соберётся всегда, в отличие от Ubunt'ы, где после неудачной установки находишь на StackOverflow решение в духе «нужно почистить кеш, снести libvasyan-ssl и поставить libvasyan-tls, после этого повторить установку».

Camel ★★★★★ ()
Ответ на: Сборщик джигурды от Camel

Re: Сборщик джигурды

Что значит «нам очень необходимо удалить vasyan-app1.0.1»? Зачем нам его удалять?

Необходимо и все, мало ли. Удалили vasyanapp1.0.1 и сборщик мусора все почистил и нету больше его, как быть тогда с jigurda12.0, который использует либу vasyanapp1.0.1 ?

Все привыкли собирать deb'ы для Ubunt'ы хер знает как, не считаясь с зависимостями, потому что ряд пакетов «есть всегда» и т.п.

Не только убунта, но и почти все остальные дистры. А убунта переходит на snappy, где эту проблему решат(надеюсь). Во всех дистрах давно уже пора так сделать.

anonymous ()
Ответ на: Сборщик джигурды от Camel

В общем от Ubunt'ы и прочих ждут определённого поведения не задумываясь почему оно должно быть таким и может ли оно в каких-то случаях быть другим

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

Deleted ()
Ответ на: Re: Сборщик джигурды от anonymous

Разборщик джигурды

Необходимо и все, мало ли. Удалили vasyanapp1.0.1 и сборщик мусора все почистил и нету больше его, как быть тогда с jigurda12.0, который использует либу vasyanapp1.0.1 ?

Знач так, не «удалили», а пометили «этот пакет мне, пользователю, больше не нужен». Если этот пакет больше никому не нужен, то сборщик мусора его удалит. Но мы знаем, что jigurda12.0 использует vasyan-app1.0.1, поэтому не удалит.

Если же запустить sudo rm -rf /store/19sksd2-vasyan-app1.0.1, то чего же ты хочешь от Guix'а?

А убунта переходит на snappy, где эту проблему решат(надеюсь).

snap это практически setup.exe. Будут в Ubunt'е пакеты в /Program\ Files/. Дожили. Ubuntu это лучший Windows.

Camel ★★★★★ ()
Ответ на: комментарий от Deleted

Нежелательно беспокоиться

А разработчикам прикладного софта нежелательно беспокоиться о состоянии ОС, в которой их софт будет работать.

Не понял, как это разработчики могут не беспокоиться о состоянии ОС, в которой их софт будет работать?

Package: vasyan-app
Depends: ruby

И посрать, что работает только на ruby-2, а на ruby-1.9.3 не работает.

Camel ★★★★★ ()
Ответ на: Нежелательно беспокоиться от Camel

Не понял, как это разработчики могут не беспокоиться о состоянии ОС, в которой их софт будет работать?

Потому что это не их забота.

Deleted ()
Ответ на: комментарий от Deleted

Работа-работа, перейди на Федота

Потому что это не их забота.

Мне кажется мы с вами не понимаем друг друга, говорим о разных вещах.

Я выше привёл пример control-файла вымышленного пакета. Как вы считаете, разработчик vasyan-app ведёт себя нормально, или это его обязанность прописать Depends: ruby (>= 2.0)?

Camel ★★★★★ ()
Ответ на: Работа-работа, перейди на Федота от Camel

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

Deleted ()
Ответ на: комментарий от Deleted

Manyamiroque

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

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

Вылейзайте из своего манямирка, где разработчики это примадонны, вокруг которых скачут ментейнеры, админы и тестировщики.

Camel ★★★★★ ()
Ответ на: Разборщик джигурды от Camel

Re: Разборщик джигурды

snap это практически setup.exe

И чем же это плохо? Поясни, только без фанатизма.

В такое случае ведроидовский apk тоже аналог setup.exe

anonymous ()
Ответ на: Manyamiroque от Camel

А вы тут при чём вообще?

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.