DNF будет переписан на языке C

Наконец то. Можт догонит пакман по скорости хотя бы. По удобству и функционалу даже не надеемся...

anonymous> А цепепе - тот же Си, который, без Си, как уже говорилось, просто ++ :-)

Вообще-то он просто обратно совместим с C.

Я считаю что это нарушение правил, вот когда перепишут тогда и обсудим. Язабан.

Чем же плох C?

Да пусть уже возьмут пакетный менеджер из шлаки. Глядишь - и systemd выкинут.

Чем же плох C?

Слишком низкоуровневый для написания прикладного софта. Есть ниши в которых он блистает. И конкурентов у него в этих нишах нет. Но пакетный менеджер это не ядро. Это прикладной софт. Язык действительно высокого уровня дает возможность писать меньше кода и делать его понятнее. Поддержка упрощается, вход для новичков снижается.

special-k> Пока Canonical пилит не нужно, RedHat продолжает оптимизировать имеющееся.

Исправил. Не благодари.

Про systemd тоже так говорили, а закончилось тем что в Canonical выбросили всё напиленное непосильным трудом ибо пила оказалась коротковата напили хер знает чего и перешли на написанное в RH. Так что ты это, не рассказывай нам про пильщиков из Canonical.

Наркоманище же. Софт не является каким-то достоянием на века.

Upstart использовался в огромной кучи проектов, в том числе в федоре на протяжении нескольких лет. А так же он до сих пор живёт в том же RHEL 6. Вот такая вот пила...

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

Наверняка подлые редхатовцы внесут в формат РПМ-пакетов какие-нибудь патентованные ни с чем на свете не совместимые изменения, чтобы еще больше фрагментироваь экосистему линукс.

Yossarian> Как насчёт systemd на яве?

SystemD переписывать надо только на C#. И чтобы юниты были на C# же.

Ох. Прошу прощения, я уже спал :)

Weres> Слишком низкоуровневый для написания прикладного софта.

Для немалой части прикладного софта весь из себя «высокий уровень» необязателен. Тут скорее дело в том, насколько уметь языком пользоваться. Ну и если на то пошло, то есть язык постарее, чем C - бейсик. С чего же C ему предпочли? Бейсик ведь тотально высокоуровневый.

Про systemd тоже так говорили, а закончилось тем что в Canonical

Сказали: «Ну ок» - и покрутили у веска.

Пока Canonical пилит не нужно...

Пока гугл пилит не нужно...
Пока мс пилит не нужно...
Пока эйпл пилит не нужно...

RedHat продолжает оптимизировать имеющееся

говно.

Дополнил. Не благодари.

Это было бы прекрасно. Уязвимостей станет меньше.

1 супердорогом сервере с SSD

если для вас сервер с SSD супердорогой, у меня для вас плохие новости

Вообще-то он просто обратно совместим с C.

Т.е. существует ради C :-) И поэтому без C он гроша ломаного не стоит :-)

Слишком низкоуровневый для написания прикладного софта.

Git - прикладной софт, написанный на C :-) Git - самая распространённая, уважаемая, стабильная, быстрая и качественная VCS, де-факто стандарт :-)

Но пакетный менеджер это не ядро.

Git - это не ядро :-) Так что C - рулит :-)

Не полностью. С c99 совместимости полной ведь не было.

Вот зачем это все? Зачем было нужно изначально писать на питоне, если не существовало этих библиотечек (hawkey, librepo, libsolv и libcomps)?

И вот сейчас, когда они есть, продукт переписывают на С! Зачем? Какие выгоды? Просто бабла много?

anonymous> Т.е. существует ради C

Тогда OS/2 существовала ради Windows 3.x и MS-DOS. А GNU/Linux существует ради UNIX и без уже усопшего UNIX гроша ломаного не стоит. А Windows 7 без Windows XP ничего не стоит. И т.д.

Пока гугл открывает и закрывает сервисы, положив болт на пользователя.
Пока MS перерисовывает плитки и перепродает их.
Пока Apple просто работает, фикся баги и немного расширяясь.
RedHat так же «просто работает» и обеспечивает вышестоящим стабильные серверные системы.

Просто выносят обособленные части на Си. Думаю, полностью на 100% на Си не перепилят, общий управляющий код будет на том же Python.

Пока Canonical пилит не нужно, RedHat продолжает оптимизировать имеющееся ненужно?

машина находившаяся на тот момент в продакшене, была потеряна на продолжительное время

Если что, обновлял не я, а человек с прямыми руками.

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

Как будто бы рпм нужен кому-то ещё.

GNU/Linux существует ради UNIX и без уже усопшего UNIX гроша ломаного не стоит.

так С не усоп - вот в чем вопрос (-:

И это тоже по-большому счёту так, но не совсем корректная аналогия с C <--> C++ :-) Сравни, хотя бы, имена - OS/2, Windows, Linux, Unix - они все разные, по ним не скажешь о какой-то взаимосвязи. Теперь сравни C и C++ - ясно видно, что один является просто надмножеством другом, т.е. без подмножества смысла не имеет :-)

Анонимный аналитики делает выводы на основе названий. Дожили.

Анонимный аналитики делает выводы на основе названий. Дожили.

Именование - это целое искусство, да будет тебе известно :-)

Upstart использовался в огромной кучи проектов, в том числе в федоре

O rly?

Но зачем?

Язык действительно высокого уровня дает возможность писать меньше кода и делать его понятнее

Ну это всё теория, а на практике написанный на языке высокого уровня юм жутко медленный и имеет проблемы с отказостойчивостью. И dnf на сегодня не далеко от него ушёл. Приходится переписывать на си. Быть может, вместе с питоном и пионеры отпадут и исчезнет причина для топиков «dnf still is unuseable» в рассылке.

на практике написанный на языке высокого уровня юм жутко медленный

Эта «медленность» уже миллион раз объяснялась любовью к скачиванию и прочему вводу-выводу. Си в этой области не быстрее Python.

Это как же надо было издеваться над yum'ом, php и центосью, чтобы такого достичь?

В том то и дело что никак. Рядом стоял точно такой же стэйдж. На нём обновление днём ранее прошло штатно, без каких-либо проблем. Те же команды(спасибо истории) на проде привели к списку удалённых пакетов на 2 экрана. В общем, трагических последстви это не повлекло, так что было записано в раздел «смешные случаи».

Эта «медленность» уже миллион раз объяснялась любовью к скачиванию и прочему вводу-выводу. Си в этой области не быстрее Python.

Ну посоветуй Сысоеву переписать Nginx на Python :-) Или сам напиши сервер на Python, который будет не медленней, чем Nginx :-) Лол :-)

В общем, у меня emacs даже после autoremove не удалялся. Как я понял, некоторые пакеты с чего то помечались, как «установленные вручную».

[telepaten_mode]
При установке apt-get вывел список пакетов, которые будут установлены по зависимостям и предложил ещё кучку пакетов для улучшения. Вы выбрали что-то из них и поставили их тем самым в ручную. После удаления emacs и autoremove, удалились все пакеты, поставленные по зависимостям, а вот опциональные остались, т.к. apt-get не знает точно, для чего вы их ставили.
[/telepaten_mode]

Для Gentoo же сделали замену portage на C++ — paludis. Серьёзного прироста скорости получено не было. Быстродействие приложения не всегда упирается в язык. Я бы даже сказал, редко упирается в язык.

не прошло и 500 лет, а пакетным манагером в шапке можно будет пользоваться! прям как аптом, чудеса...

Я просто сделал:

apt-get install emacs

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

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

#sync && echo 3 > /proc/sys/vm/drop_caches
#time tar -cO /var/cache/yum/x86_64/20/ | cat > /dev/null
real    0m9.527s
user    0m0.061s
sys     0m2.302s

#time tar -cO /var/cache/yum/x86_64/20/ | cat > /dev/null
real    0m0.727s
user    0m0.029s
sys     0m1.073s

#sync && echo 3 > /proc/sys/vm/drop_caches
#time yum --cacheonly -y update
real    1m13.761s
user    0m3.844s
sys     0m1.101s
#time yum --cacheonly -y update
real    0m2.409s
user    0m2.172s
sys     0m0.205s

Врать не хорошо.

http://paste.debian.net/404730/

Судя по различиям в sys, тест некорректен.

Как многолетний пользователь федоры, скажу так: возмите уже apt-get, ёклмн.

Как анабиозник спрошу: а дельту к нему уже прикрутили?

Можт догонит пакман по скорости хотя бы. По удобству и функционалу даже не надеемся...

Пакман умеет поиск пакетов в репах по пути к файлу, по маскам, по pkgconfig(glib-2.0)?

А проверку пакетов на конфликты перед началом установки?

Я уж молчу, что он совсем недавно научился проверке по цифровой подписи.

Так о каком таком «функционале» ты нам тут вещаешь?

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

Кстати, к rpm дельта тоже не особо крепко прикручена, например нельзя создать дельтарпм для сколько-нибудь большого пакета (например, когда я в 800мб ufiai-data.rpm добавил файл на 2мб дельта просто не создавалась, молча).

Речь про Debian и Apt.

Хаха. Зато воспроизводится.

Пардон, сразу не понял.