Ян Шилган (Jan Šilhan), лидер разработчиков пакетного менеджера DNF, который недавно пришёл на смену Yum в дистрибутиве Fedora, рассказал (http://dnf.baseurl.org/2016/02/24/dnf-into-c-initiative-started/) об инициативе по переработке DNF на языке Си. Изначально, Yum был написан целиком на языке Python, в то время как наиболее требовательные к производительности низкоуровневые функции DNF были вынесены в отдельные Си-библиотеки hawkey, librepo, libsolv и libcomps. В рамках новой инициативы планируется переписать на Си остающиеся на Python высокоуровневые компонеты DNF.
Версия на языке Си развивается в рамках проекта libhif (https://github.com/rpm-software-management/libhif), в котором постепенно создаётся библиотека, предоставляющая функции с базовой функциональностью типового пакетного менеджера. В libhif задействованы уже применяемые в DNF библиотеки librepo (https://github.com/rpm-software-management/librepo) (работа с репозиториями) и hawkey (https://github.com/rpm-software-management/hawkey) (обвязка над libsolv для разрешения зависимостей). Начиная с выпуска 0.7.0 библиотека hawkey вольётся в состав libhif и станет неделимым целым. Слияние libhif и hawkey позволит скрыть некоторые нестабильные вызовы API системы разрешения зависимостей, предложив вместо них более универсальные высокоуровневые вызовы. Обвязки для языка Python будут сохранены в неизменном виде, что позволит сохранить возможность обращения к старым вызовам через биндинги python2-hawkey и python3-hawkey.Предоставляемый в libhif высокоуровневый API для работы с пакетами будет учитывать такие особенности, как загрузка метаданных с зеркал, расчёт зависимостей, выполнение транзакций RPM, разбор конфигурации репозиториев, проверка цифровых подписей и другие типовые возможности, которые ранее реализовывались в каждом пакетном менеджере самостоятельно.
В будущем libhif сможет использоваться как фреймворк для построения пакетных менеджеров, например, кроме DNF новую библиотеку планируется задействовать в PackageKit, что позволит унифицировать разные реализации. Перевод DNF и PackageKit на единую основу даст возможность совместного использования данных систем, избавит от наблюдаемых несовместимостей и позволит использовать одни и те же метаданные. Ожидается, что libhif со встроенным hawkey будет поставляться в дистрибутиве начиная с выпуска Fedora 25.URL: http://dnf.baseurl.org/2016/02/24/dnf-into-c-initiative-started/
Новость: https://www.opennet.ru/opennews/art.shtml?num=43939
вангую появление нового пласта багов, когда систему можно будет саботировать поддельными специально сформированными пакетами с ПО (или без него)..
> вангую появление нового пласта багов, когда систему можно будет саботировать поддельными > специально сформированными пакетами с ПО (или без него)..Любую систему можно "саботировать поддельными специально сформированными пакетами с ПО". Для этого и придумали подписывание пакетов.
КЭП.
Учитывая, что пакетный менеджер без тени сомнения творит в системе от имени рута все то, что прописал создатель пакета - вообще непонятно, зачем пакеты "подделывать и специально сформировывать".
Я думаю большинство мантейнеров продадут свое честное имя за $100000. И любой дистрибутив может получить бекдор.
> продадут свое честное имя за $100000Фигня. Вангую, что ни один в основной репе не продастся за так мало. Вот в rpmfusion может можно будет найти.
Честное имя - может быть, но внедрение бэкдоров - это уголовно наказуемое деяние. Тут не только потерей репутации пахнет.
Хотя, конечно, небольшие программные ошибки... но, собственно, при чем же тут тогда именно мантейнеры?
> Хотя, конечно, небольшие программные ошибки... но, собственно, при чем же тут тогда
> именно мантейнеры?Притом, когда включили маленький и безобидный патчик...
> Я думаю большинство мантейнеров продадут свое честное имя за $100000. И любой
> дистрибутив может получить бекдор.Прикинул за сколько сам продашь и для верности умножил на 1000?
Это как-то связано с С?
Пакеты и так подписываются ЭЦП. Если даже и предположить, что у кого-то будут приватные ключи и доступ к репам, то такие сложности никому не нужны, что бы поиметь твой локалхост: тебе патч бармина прям в post-install хук встроят и все.
Верно, тут поможет только ассемблер, там и пласты пожиже и баги пожирнее, главное не останавливать на достигнутом.И вообще надо Лёника для консультаций привлечь, может быть вариант с ассемблером позволит себя легко интегрировать в Пульсик поверх СистемДешечки.
> вангую появление нового пласта багов, когда систему можно будет саботировать поддельными
> специально сформированными пакетами с ПО (или без него)..Пакеты ставятся от рута и там скрипты можно выполнять. Специально сформированный пакет может хоть rm -rf / сделать. Поэтому до начала установки нормальные пакетные менеджеры цифровую подпись проверяют.
Ну и правильно, прототипирование на языках высокого уровня, рабочая лошадь уже на более мощных языках.
Весь вопрос в том, почему Си а не Cython? (не путать с cpython)
Потому что тогда придется баги править, а не заниматься ИБД.
> Ну и правильно, прототипирование на языках высокого уровня, рабочая лошадь уже на
> более мощных языках.Так и запишем: RedHat 10 лет прототипировали пакетный менеджер.
На сколько же по разным путям идут убунту и федора...
Что конкретно вы имеете ввиду?
В Ubuntu свой центр приложений на Python заменять на гномовский на Си
> В Ubuntu свой центр приложений на Python заменять на гномовский на Сиapt и dpkg не получится переписать с питона на си, они изначально на си++
Какие-то странные метания, вон у дебияна dpkg пакеты жуёт по полчаса и ничего, хотя apt летает, а тут вроде и yum быстрым был, а за каким-то хреном его переписать решили.
>dpkg пакеты жуёт по полчаса и ничего, хотя apt летаетНо как?
написан в спокойные девяностые, вот и работает спокойно, не торопясь
> написан в спокойные девяностые, вот и работает спокойно, не торопясьОднако ж apt скачивает пакет и отдает его dpkg. Эффект плацебо комментаторам не жмет?
Основная причина заменя yum на dnf в том, что yum на python 2 и это мешает перевести дистрибутив на python3.
Основная причина в том, что создатель yum погиб в аварии.
Фактор автобуса равный 1 это плохо.
> вон у дебияна dpkg пакеты жуёт по полчасаОтсыпите вашего дебияна?
Начинается. Давайте перейдем с yum на новый днф, который мы написали с нуля, теперь давайте пенрепишем днф с нуля еще раз.
Dnf не было написан с нуля, он основан на Yum 3.4 созданный для развития некоторых новых идей, таких как использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey.
В таком ключе это нормальное, поступательное развитие.
Кстати, yum то работает и работает вполне быстро, хз зачем его менять.
Он на пайтоне написан, а это мешает делать маленькие контейнеры для облаков.
Чем бы дитя не тешилось, лишь бы zypper не использовало.
А что не так с zypper?
Он имеет ввиду, что zypper самый лучший пакетный менеджер, но в федоре совершают ошибку, что изобретают любые костыли, придумывают что угодно, только бы не взять и адаптировать zypper под Федору. Я, кстати, полностью с этим согласен. Zypper реально самый быстрый пакетный менеджер, он работает со скоростью молнии. Ни apt, ни dnf, ни кто-либо другой не работает с такой скоростью. Чистый С рулит, вообщем. При этом я молчу уже про кучу встроенных супер удобных алиасов, которые состоят всего из двух букв. Очень удобно. Что-то, а zypper реально одна из самых лучших частей OpenSUSE дистрибов, несмотря на общее падение качества.
Самый быстрый арчевский pacman)
Он разве не с исходными кодами работает? Я к своему стыду, кстати, так и не смог его осилить. Даже в Manjaro. Так что за него сказать не могу. А по удобству и функциям не уступает ли он zypper? С какой скоростью он скачивает файлы? Zypper у меня всегда качает на пределе пропускной способности подключения к сети Интернет. Apt и dnf всегда медленнее.
С бинарниками. Что в нем осилять то? Обычный пакетный менеджер
Всегда по максимуму выжимает из сети
Блин ну ппц, какой интернет какое зеркало так и будет и качать, при чем тут пакетный менеджер? Также в pacman можете выбрать чем и как качать в конфиге, сколько потоков и т.п. curl wget aria2c еще другие?
APT даже на российских и любые даже самых быстрых зеркалах никогда не сравнится с zypper. А DNF, возможно такой медленный из-за зеркал, но я не уверен в этом.
> Он разве не с исходными кодами работает? Я к своему стыду, кстати,
> так и не смог его осилить. Даже в Manjaro. Так что
> за него сказать не могу. А по удобству и функциям не
> уступает ли он zypper? С какой скоростью он скачивает файлы? Zypper
> у меня всегда качает на пределе пропускной способности подключения к сети
> Интернет. Apt и dnf всегда медленнее.Это в Демьяне его зоопарк инструментов управления пакетами можно поначалу не осиливать. Да нет, и там нельзя, я с нуля за пару недель освоился. А pacman, он один на всё про всё, ключи все хорошо структурированы и разделены по категориям. Чего там можно не осиливать? Может это ты не pacman, а просто саму shell не осиливаешь? :)
> Это в Демьяне его зоопарк инструментов управления пакетами можно поначалу не осиливать.
> Да нет, и там нельзя, я с нуля за пару недель
> освоился. А pacman, он один на всё про всё, ключи все
> хорошо структурированы и разделены по категориям. Чего там можно не осиливать?
> Может это ты не pacman, а просто саму shell не осиливаешь?
> :)Что такое Демьян? Дебиан?
По поводу освоения пакмана. Я то ли репы не понял как подключать, то ли ещё что-то гугление ни к чему ни привело. Ну я и плюнул на это дело.
Гугление не привело тебя на Arch Wiki!? Это через какое же место нужно было гуглить? А вообще, Arch Wiki - это сборник наиисчерпывающей официальной документации по Arch, на который нужно приходить не с гугла, а сразу с официального сайта, если уж ты ставишь Арч. Чудак ты.
https://wiki.archlinux.org/
> Гугление не привело тебя на Arch Wiki!? Это через какое же место
> нужно было гуглить? А вообще, Arch Wiki - это сборник наиисчерпывающей
> официальной документации по Arch, на который нужно приходить не с гугла,
> а сразу с официального сайта, если уж ты ставишь Арч. Чудак
> ты.
> https://wiki.archlinux.org/Прошу вас не не упоминать всякие места. Я смотрел и оф сайт, хотя сначала и не знал, что Manjaro базируется на Arch. Но я так и не смог осилить установку пакета со стороннего репо. Насколько я помню, пакман давал мне отбой на попытки установки со стороннего репо. Как разблокировать такую установку, я не знал. Осилить так и не смог. Вот и забросил. Может, вернусь как-нибудь.
> Самый быстрый арчевский pacman)Этот комментарий относится и к комментатору выше: в пакетном менеджере главное не то за сколько соберет, скачает пакет, а удобство, функциональность и стабильность. А на скорость скачивания и сборки играют другие факторы. Либо совсем кривые руки разработчика пакетного менеджера либо не возможность изменить как и чем скачивать из сети.
Согласен. В этот как раз Zypper очень хорош. APT у меня с сторонними ppa часто ломал пакеты, с zypper даже с парой десяткой сторонних реп никаких проблем не испытываю. Я уже не говорю про удобство работы с OpenBuild Service, особенно радует момент, что я могу установить любой пакет через графический интерфейс с OpenSUSE 13.1, 13.2, Tumbleweed на Leap 42.1, причем со сторонних реп. А это нереально удобно. Даже ppa не сравнится.
> APT у меня с сторонними ppa часто ломал пакетыэто вообще как?
>> APT у меня с сторонними ppa часто ломал пакеты
> это вообще как?Это когда появляются битые пакеты, которые никак не убрать. И старые тоже вернуть не получается.
Не осилил apt и ругаешься. apt-get позволят откатить и удалить все пакеты установленные из ppa.
> Не осилил apt и ругаешься. apt-get позволят откатить и удалить все пакеты
> установленные из ppa.И как же это сделать? Около 3-х разных запросов на эту тему в гугл делал, в документации ничего такого нет. dnf легко откат позволяет делать, либо последнюю транзакцию можно отменить, либо любую по номеру. В апте это не нашел, только через синаптик научился это делать.
Может я слегка ошибся, это делает не apt-get, а утилита ppa-purge.
Утилита отключает репозиторий и откатывает все обновленные оттуда пакеты.
Например:
sudo apt-get install ppa-purge
sudo ppa-purge ppa:neon1ks/xenial
> Может я слегка ошибся, это делает не apt-get, а утилита ppa-purge.
> Утилита отключает репозиторий и откатывает все обновленные оттуда пакеты.
> Например:
> sudo apt-get install ppa-purge
> sudo ppa-purge ppa:neon1ks/xenialТо есть надо стороннюю утилиту ставить? Спасибо за инструкцию, конечно, но тормозной dnf в Fedora может такое из коробки делать.
"Но есть один нюанс". Пакет с битыми install|remove скриптами наглухо затыкает apt, так что наличием ppa-purge нужно озаботиться ДО развлечений с ppa.
> "Но есть один нюанс". Пакет с битыми install|remove скриптами наглухо затыкает apt,
> так что наличием ppa-purge нужно озаботиться ДО развлечений с ppa.А что, сборочница даже устанавливаемость пакетов не тестирует?
Молодой человек, не подключайте левые ppa!
Хотя бы до тех пор, пока apt не освоите...
> Молодой человек, не подключайте левые ppa!
> Хотя бы до тех пор, пока apt не освоите...Если APT надо освавать, то с dnf и zypper таких проблем нет без всяких лишних умозатрат. По простоте использования они явно лучше. Но это лично мои впечатления, конечно.
В том то дело, что пакман очень функционален, в отличии от апта(zypper не пробовал) он может локальные пакеты ставить и зависимости разруливает шикарно, можно посмотреть список неиспользованых пакетов и тд. Реально дофига возможностей.
> В том то дело, что пакман очень функционален, в отличии от апта(zypper
> не пробовал) он может локальные пакеты ставить и зависимости разруливает шикарно,
> можно посмотреть список неиспользованых пакетов и тд. Реально дофига возможностей.в отличии от апта...
- он может локальные пакеты ставить
- зависимости разруливает шикарно
- можно посмотреть список неиспользованых пакетовНу да... куда уж отсталому apt'у и dpkg... Там-то все по старинке... И зависимости вручную, и пакеты только оттуда, откуда партия сказала, и неиспользуемые пакеты посмотреть нельзя...
Вы мне сейчас хотите рассказать что apt это не умеет? Да вы издеваетесь?
zypper или ракман аналог dnf provides /path/to/file умеют?
Слышь, ракмэн, сначала объясни, что есть твоё "dnf provides" тем, кто твоего любимого пакетного менеджера отродясь в глаза не видел и увидеть в будущем так же не испытывает никакого желания. Но гуглить то я умею, да. То есть, это, как я понял, узнать какому пакету принадлежит файл? "Ракман" такое умеет с пелёнок:
pacman -Qo /путь/к/файлу/имя_файла
А так вообще сходи почитай
https://wiki.archlinux.org/index.php/Pacman_(%D0%A...)#.D0.97.D0.B0.D0.BF.D1.80.D0.BE.D1.81.D1.8B_.D0.BA_.D0.B1.D0.B0.D0.B7.D0.B0.D0.BC_.D0.B4.D0.B0.D0.BD.D0.BD.D1.8B.D1.85_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.BE.D0.B2
Читать то ты умеешь, ракмэн?
Я отвечу, хоть и не мне:
dnf provides ищет файл (не обязательно полный путь, можно вроде и рег. выражения использовать), который НЕ установлен. Т.е. этой командой можно найти файл/библиотеку и т.п. в пакетном репозитарии, а не по факту установки пакета.То, что вы привели - это rpm -qf /path/to/file.
Дорогой раконенависник, коллега чуть выше уже описал суть. От себя добавлю, что dnf provides ищет все варианты в репах, причём может искать не только по файлам, но и по pkgconfig(<название>) и по секции Provides в rpm-spec. Хз, как описать что оно делает, в кратце, если есть альтернативы какому либо пакету, например есть штатный libyaz в репах centos, есть libyaz5 в сторонних репах, пакеты между собой не совместимы. Но в libyaz5 прописано, что он Provides: libyaz.И ты такой yum provides libyaz.
А он тебе:
libyaz-x.y.z
libyaz5-x.y.zИ всё это без костылей, благодаря нормальной архитектуре.
# zypper what-provides smtpdaemon
...
С | Имя | Заключение | Тип
--+-----------+-----------------------------------------------------------------------------+------
i | exim | The mail transfer agent, a replacement for sendmail | пакет
| opensmtpd | Free implementation of the server-side SMTP protocol as defined by RFC 5321 | пакет
| postfix | Postfix Mail Transport Agent | пакет
| sendmail | A widely used Mail Transport Agent (MTA) | пакет
| ssmtp | Extremely simple MTA to get mail off the system to a Mailhub | пакет
А! Да! pkgconfig и либы тоже умеет.# zypper wp libstdc++.so.6
...
С | Имя | Заключение | Тип
--+------------+---------------------------------+------
| libstdc++ | GNU Standard C++ Library | пакет
i | libstdc++6 | The standard C++ shared library | пакет# zypper wp 'pkgconfig(openssl)'
...
С | Имя | Заключение | Тип
--+---------------+--------------------------------------------------------------+------
| openssl-devel | Files for development of applications which will use OpenSSL | пакет
zypper se --provides libsomething
> zypper what-provides /usr/bin/zypper...
С | Имя | Заключение | Тип
--+--------+------------------------------------------------------------------------------+------
i | zypper | Менеджер программного обеспечения для командной строки, использующий libzypp | пакет
Понятно. Значит, не с той стороны воспринял исходное сообщение.
где качество упало?
Говорят, не такой стабильный, да и с новым железом плохо дружит. Я вот сдуру купил видеокарту GTX 750 Ti, так вот мучаюсь теперь страшно. Свободные драйверы хоть как-то работают с ней только начиная с ядра 4.2(на практике проверено, и то, только один дистриб, Kubuntu 14.04.4), а проприетарные тоже методом практики приходится проверять, что очень неудбоно. Вот поставил я OpenSUSE Leap 42.1 на свой ПК(Core 2 Quad Q6600 2,83 GHz(под разгоном), 4 Gb DDR2, GTX 750 Ti). Логин не проходит. Вводишь пароль, сбрасывается изображение на экране и снова спрашивает пароль. Ввожу Ctrl+Alt+F1(или F2 на конце, разницы не заметил), стартх не работает, старткде тоже. Пришлось фотографировать инструкции установки проприетарных дров через рабочюю убунту. Попробовал, не помогло. И обновление всех пакетов до последних версий тоже. Вот и что мне теперь делать? Проще расстаться, но я чисто из принципа хочу дойти до победного.
> Говорят, не такой стабильный, да и с новым железом плохо дружит. Я
> вот сдуру купил видеокарту GTX 750 Ti, так вот мучаюсь теперь
> страшно. Свободные драйверы хоть как-то работают с ней только начиная с
> ядра 4.2(на практике проверено, и то, только один дистриб, Kubuntu 14.04.4),
> а проприетарные тоже методом практики приходится проверять, что очень неудбоно.Для Дебиана и бубунты есть такая вещь, smxi (и sgfxi в этом наборе заведует установкой видедров).
>> Говорят, не такой стабильный, да и с новым железом плохо дружит. Я
>> вот сдуру купил видеокарту GTX 750 Ti, так вот мучаюсь теперь
>> страшно. Свободные драйверы хоть как-то работают с ней только начиная с
>> ядра 4.2(на практике проверено, и то, только один дистриб, Kubuntu 14.04.4),
>> а проприетарные тоже методом практики приходится проверять, что очень неудбоно.
> Для Дебиана и бубунты есть такая вещь, smxi (и sgfxi в этом
> наборе заведует установкой видедров).Самое интересное, что Kubuntu 14.04.3 и .4 обладают намного большей совместимостью с моей видео, чем версия 15.10. Её у меня даже установить иногда не получается. А когда получается, таже история с логином. Не входит, сбрасывает картинку и снова просит пароль.
Надо проверять ~/.xsession-errors.
Если графический логин появился, дело точно не в карте :))скорей всего где-то конфиги и пути к Xsession слетели.
> Если графический логин появился, дело точно не в карте :))
> скорей всего где-то конфиги и пути к Xsession слетели.Проблема в том, что на других компьютерах такой проблемы нет. С тем же самым ISO. На других ПК графика Fermi(GT 610) и Intel HD Graphics 4400.
Подтверждаю, есть такая проблема, именно с этой картой. Мой выход - я поставил убунту. Чего намудрили в кубунте, без понятия. Убунта работает отлично, с проприетарными дровами.
Такое бывает когда пользователь в группы необходимые не вбит.
> Такое бывает когда пользователь в группы необходимые не вбит.Интересная мысль. Как это сделать вручную? wheel как я понимаю, здесь ни при чем. Не могли бы поразвернутей и подробней ответить, пожалуйста? А то я новичок в Linux.
https://wiki.archlinux.org/index.php/Users_and_groups_%...
> Он имеет ввиду, что zypper самый лучший пакетный менеджер, но в федоре
> совершают ошибку, что изобретают любые костыли, придумывают что угодно, только бы
> не взять и адаптировать zypper под Федору. Я, кстати, полностью с
> этим согласен. Zypper реально самый быстрый пакетный менеджер, он работает со
> скоростью молнии. Ни apt, ни dnf, ни кто-либо другой не работает
> с такой скоростью. Чистый С рулит, вообщем.Там плюсы.
pkgsrc + pkgin в помощь
костылей посоздают и радуются
>переписать на Си
>высокоуровневые компонетыНо зачем?
>>переписать на Си
>>высокоуровневые компонеты
> Но зачем?Пожизненное трудоустройство. С автором yum-а сработало ж, вроде.
Рядом висят три новости о уязвимостях связанных с переполнением буфера. Может спонсор АНБ?
Больше сегфолтов, хороших и разных!)
Почему именно С? Работа с UTF через задницу, чтение метаданных через задницу, безопасность через все тоже, быстродействие для обертки нафиг не нужно. Есть же куча компилируемых безопасных языков, там rust/golang/D/etc
Cython ещё есть, даже переписывать ничего не надо.
> Cython ещё есть, даже переписывать ничего не надо.иди те уже пишите, а то только трындите.
Си это язык, который зависит от человека.
Если Вы работаете через задницу, то python ессно, Вам это простит. Си - никогда.
Если Вы нормально делаете - то у Вас нормально будет и на Си.
"Идеальный программист не устает, не ошибается и не существует."
>> Если Вы работаете через задницу, то python ессно, Вам это простит.Поясните. Если неправильно закодить алгоритм, то он и на питоне будет работать неправильно. Ошиблись в дизайне? Так динамические языки рефакторить потяжелее.
>> Если Вы нормально делаете - то у Вас нормально будет и на Си.Только в 2 раза дольше
[i]Если неправильно закодить алгоритм[/i] - я не хотел бы в рамках этой темы обсуждать алгоритмы решения тех или иных вещей. К началу реализации проекта уже должен быть сформирован более-менее ясный алгоритм решения той или иной задачи.
Вы опираетесь на суждение, что в решении наших задач мы заведомо идем неверным путем.
Нет. Мы не стремимся так делать и цена алгоритмических ошибок всегда высока.
[i]Только в 2 раза дольше[/i] - код может быть быстро написан, может быстро исполняться. Для многих платформ применение языка С чуть ли не единственный способ добиться адекватной работы.
Так что конкретно питон-то простит? :)
> Си это язык, который зависит от человека.
> Если Вы работаете через задницу, то python ессно, Вам это простит. Си
> - никогда.
> Если Вы нормально делаете - то у Вас нормально будет и на
> Си.Всегда "нравились" такие рассуждения. Сколь складно звучащие, столь и оторванные от реальности.
Если вы нормально работаете - у вас всегда будет высокая з/п
Если вы нормально играете на музыкальной инструменте - у вас всегда будет мировая популярность
Если вы нормально преступничаете - вас никогда не поймают
Что тут оторванного от реальности?
[i]Если вы нормально работаете - у вас всегда будет высокая з/п[/i] - если Вы нормально работаете, то у Вас будут нормальные результаты Вашей работы.
При чем тут ЗП? Зачем Вы вообще приплели сюда экономическую отдачу работы?
Если человек нормально вскопал огород у себя на даче, то у него будет высокая ЗП? Нет, у него будет нормально вскопанный огород.На мой взгляд, Вы довольно низко пали в своей системе оценки сущностей.
> Си это язык, который зависит от человека.
> Если Вы работаете через задницу, то python ессно, Вам это простит. Си
> - никогда.
> Если Вы нормально делаете - то у Вас нормально будет и на
> Си.Вон выше по треду написано как петон зависит от человека. Судя по каменту, человека убило автомобилем, и проект стало некому поддерживать, даже название поменяли. По вашей логике от сей жёсткие диски покроются ржавчиной изнутри?
Кстати да. Если им нужен быстрый старт и рантайм, куда больше подошёл бы Ocaml. У него, конечно, utf8 тоже через задницу, но строгий вывод типов не позволит ошибиться, как в Си, есть контроль границ массивов, есть объектная модель (хотя это может и не сильно большой плюс в данной задаче).
Они переписывают не на "просто C", а на C+glib. Так что не настолько все плохо будет. Впрочем, почти настолько.
Это ещё хуже. Чудовище из макросов.
> Почему именно С? Работа с UTF через задницу, чтение метаданных через задницу, безопасность через все тоже, быстродействие для обертки нафиг не нужно. Есть же куча компилируемых безопасных языков, там rust/golang/D/etcМожет потому, что C уже больше 40 лет живёт и не умирает, а ваша компания ещё из яслей не вышла и неизвестно выйдет ли (а D вообще уже лет 10 в яслях).
> Почему именно С? Работа с UTF через задницу,А что за проблема с UTF???
У си нет проблем с юникодом, там это просто последовательность байт. :-)
Благодаря такому наивному подходу спец. по безопасности Moxie Marlinspike выписал себе валидный SSL сертификат на *(весь интернет)
https://youtu.be/ibF36Yyeehw?t=33m5s
Использовать язык с нуль терминированными строками в эпоху utf - бег по минному полю.В эту же секунду сервера падают под CVE-2015-7547 (новый Heardbleed/shellshok)
http://www.ibtimes.co.uk/google-red-hat-discover-critical-dn...Наивность красит молодых девиц. Наивный мужчина синоним дурака.
В других языках - другие проблемы. Другие - не значит что они меньше какчеством и кокличеством :)
С другой стороны - материалы о команде писавшей для шаттлов на голом С есть в интернете, и метода их работы тоже там. Шаттлы критических проблем с софтом не имели ЕМНИП.
> Использовать язык с нуль терминированными строками в эпоху utf - бег по минному полю.utf есть разные, в UTF-8, самой распространенной из них, ситуация с null terminated string ничем не отличается от однобайтных. А в ее advanced форме такой проблемы вообще нет.
> Использовать язык с нуль терминированными строками в эпоху utf - бег по
> минному полю.В си нет строк. Ни нуль-терминированных, ни других. Прекращение разбора при натыкании на 0 это такое джентльменское соглашение. Поменять его сложно. Но в своих программах ты можешь использовать делать что-то другое. А вот системные api будут от тебя ожидать это в таком виде. Поэтому 0x00 нельзя например в имени файла использовать. Чисто технически не получится.
> Наивность красит молодых девиц. Наивный мужчина синоним дурака.
Как вы себя хорошо обгадили. Не понимаете как си работает, но мнение имеете?
>> Почему именно С? Работа с UTF через задницу,
> А что за проблема с UTF???Человек не отличает библиотеки для работы с кодировками от самого языка.
Да до чела вообще не доходит что в С строк вообще нет. В stdlib - есть.
Чел уже замыленным глазом смотрит на:
char *stroka_nah;
и думает - окаи, тут у нас строка ... а там указатель :)
>В будущем libhif сможет использоваться как фреймворк для построения пакетных менеджеровБольше пакетных менеджеров, больше!!!
Ключевой момент - вторая половина предложения, про packagekit. Федора сейчас gnome software активно развивает, рассчитывает на него в будущем. Oтношения используемого в нём packagekit с dnf - натуральный цирк с конями. В истории dnf поставленные через software пакеты не сохраняются, авторемув предлагает их всех удалить к чертям, если software апдейты скачал и предлагает установить, а ты через dnf апдейт запустишь, то он проигнорирует лежащие рядом пакеты и начнёт всё перекачивать, итд. А потом в это дело ещё и xdg-apps вклинятся, так что надо привести всё к единому основанию, пока совсем не обвалилось.
> В будущем libhif сможет использоваться как фреймворк для построения пакетных менеджеровну конечно же лучше пилить фреймворки для разработки приложений чем сами приложения.
Кто захочет писать о себе на linkedIn: "Разработчик HelloWorld-а"? А вот "Разработчик фреймворка для HelloWorld-ов" звучит гордо.
Ага, давайте еще на haskell потому что он awesome.
Что вы?! Awesome - это на Lua!
> Что вы?! Awesome - это на Lua!Я не свое мнение описывал, просто любят на хаскел еще переписывать многие, аргументируя именно так :)
Тайловый менеджер awesome написан на lua.
Что люди не придумают лишь бы не использовать apt.
ждём ебилдов
apt - УГ. Так что правильно придумывают.
Абсолютно согласен!
Но в линуксах всё равно лучше ничего нету, всё остальное просто ... вотЪ! :)
У всех есть свои недостатки, это факт. Но apt - это какой-то сборник недостатков. Начать можно от контроля зависимостей в dpkg, когда возникает необходимость пересборки на ровном месте из-за того, что зависимости прописываются по названиям пакетов, а не по библиотекам/файлам, как в рпм. Продолжить отсутствием транзакций и проверок на пересечение по файлам перед установкой. Закончить тем, что функции разбросаны по разным бинарникам, частично пересекающимся между собой.Dnf гораздо удобнее. Памяти он много жрёт, это да. Может поправят.
А вообще хотелось бы некий гибрид из dnf и emerge. За основу взять dnf/rpm, но с гентушным word-файлом с чётким списком вручную установленных пакетов, добавить туда мета-пакеты с юз-флагами, цветной вывод, но всё с бинарниками. И никаких рекоммендаций!
чудеса случаются)
Просто для общего развития, а что не так с yum? За 7 лет исплользования ни разу не было проблем с ним. Ну да, иногда бывает тупит, но учитывая, что работать с пакетами приходится не так часто - не критично. Python в отличие от того же perl, идет по дефолту в CentOS, так что ничего доставлять не надо.
Попробуй обновить старую систему в виртуалке/контейнере с 256 метров памяти. Будет большой сюрприз, за несколько часов он не пройдет стадию рассчета зависимостей. Собственно из-за этой его особенности в openvz сделали vzyum, который для обновления пакетов в контейнерах использовал yum на хосте.
Если же памяти хотя бы пару гигов или обновлять надо не больше десятка пакетов, то все нормально с yum.
Отличная новость.
Побольше бы нужных и востребованных проектов переписывали на C/C++ с иных языков.
Портировать проекты на C в 2016 году?
что тебе не непонятно? они под виртуалочки пилят
Или у yum есть таки фатальный недостаток ибо он написан не на с/с++/js/...? :DP.S.
реально чего не хватает, так это поиска файла онлайн в неустановленном пакете. Т.е. аналог yum provides только для поиска по всем подключенным репозитариям и всем пакетам, в том числе не установленным. Но такого вроде ни в одном пакетном менеджере нет.
При переписывании с питона на С фатальный недостаток всегда один: потребление процессора и памяти. Как по мне, так более чем достаточная причина.
> Портировать проекты на C в 2016 году?да, когда нужна кроссплатформенность и поддержка большого числа архитектур. Ибо завести проект на с++ под какой нить mips гораздо сложнее, имхо
> Попробуй обновить старую систему в виртуалке/контейнере с 256 метров памяти. Будет большой сюрприз, за несколько часов он не пройдет стадию рассчета зависимостей
ну разве что такие специфические юзкейсы.
> да, когда нужна кроссплатформенность и поддержка большого числа архитектур.чувак, это редхат, сколько там архитектур? какие платформы?
x86_64, Power, и z
>> да, когда нужна кроссплатформенность и поддержка большого числа архитектур.
> чувак, это редхат, сколько там архитектур? какие платформы?ну как минимум x86, x86-64, ppc, ppc64, s390x (z). В федоре также есть arm
Почему не Rust?
Пакетный менеджер. Для продакшна. На Rust, на котором ничего приличного ВООБЩЕ пока не написано. Оригинально, да.
Молодцы, чо. Чисто. Расово. Школота не поймет, конечно же, и будет метанировать лужи, как обычно.
почему не заимствовать пакман а не плодить велосипеды
Хорошая новость. А то DNF - не самый быстрый пакетный менеджер, тем кто имел дело с Arch Linux и его pacman - это давно известно. Ну и из-за использования python на самых дещёвых VPS-ках не всегда хватало памяти для запуска DNF(то же самое относится и к Yum) - приходилось останавливать мускуль и апачик, что-бы установить нужные пакеты. Надеюсь, переписанный на C DNF будет более экономно расходовать операвтиную память.
Там не чистый, а Glib. Так что они не велосипедят со строками.
А потом удивляются, откуда даже такие прикладные перделки полны багов - давайте, раскопайте стюардессу, напишите ещё стотыщ строк говнокода! Хоть от ассемблерных вставок отучились...
Почему бы не попробовать писать на Ди? Линукс-версия существует давно и не одна. Библиотека ДЛЯ ТАКИХ перделок вообще имеет всё, что можно! Чудны пингвинячие дети...