На состоявшемся заседании комитета FESCo (Fedora Engineering Steering Committee), отвечающего за техническую часть разработки дистрибутива Fedora Linux, было утверждено решение (https://lists.fedoraproject.org/pipermail/devel/2013-October...) по переходу дистрибутива на использование (https://fedoraproject.org/wiki/Changes/Python_3_as_Default) Python 3 по умолчанию, начиная с выпуска Fedora 22. Среди ключевых последствий перехода на Python 3 отмечается задействование по умолчанию пакетного менеджера DNF, который заменит собой Yum, поддерживающий выполнение только с использованием Python 2.
Пакетный менеджер DNF (https://fedoraproject.org/wiki/Features/DNF) является ответвлением от Yum 3.4, в котором развивались некоторые новые идеи, такие как использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey (https://fedoraproject.org/wiki/Features/Hawkey). Для разрешения зависимостей в DNF задействован SAT solver, реализованный в библиотеке libsolv (https://github.com/openSUSE/libsolv) (hawkey выступает в роли надстройки над libsolv), созданной в рамках проекта openSUSE. Для обычного пользователя главными достоинствами DNF является заметно более высокая скорость работы и низкое потребление памяти. Для расширения функциональности DNF предоставляет фикисированный API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.URL: https://lists.fedoraproject.org/pipermail/devel/2013-October...
Новость: http://www.opennet.ru/opennews/art.shtml?num=38248
как-то познова-то..но всё равно хорошо :-)
>познова-тоПростите, ч-то?
Пазнавата
пазнаватильна
> ПазнаватаРазновидность стекловаты?
> Разновидность стекловаты?...по которой ползет удав^W питон.
На что только не идут люди, лишь бы не использовать zypper (c++, если чё)...
То что работает в паре недодистров никому не интересно. Интересно сделать что-то новое, интересен факт развития. В итоге всякие суси и прочие дистры первые возьмут заберут себе эти изменения, как было например с systemd.
> Интересно сделать что-то новое,Леннарт, залогинься.
>> Интересно сделать что-то новое,
> Леннарт, залогинься.Почему сразу Леннарт? Вон, одному финскому студенту тоже было интересно сделать что-то новое, похожее на миникс, но только свое. Не помню, как его звали, но вроде тоже на букву Л...
> звали, но вроде тоже на букву Л...Только он не писал его на бидоне.
Потому, что этот самый Бидон в то время сам только рождался. Поэтому Л. о нём банально не мог знать. А иначе как знать, как знать... ;)
В те времена был гейтовский бейсик и Л. про него знал=))
> Л. про него зналЛеннарт-то?
>> Л. про него знал
> Леннарт-то?Леннарт барсиками не пользуется. Только сишечка, только хардкор!
> Леннарт барсиками не пользуется. Только сишечка, только хардкор!Как ни странно, Торвальдс им тоже пользуется. Ну а что, нормальный ЯП для системных сущностей. Быстрый и портабельный. И в отличие от бидонистов не крушат совместимость все и вся с завидной периодичностью.
Скрипт писаный для бидона 2.4 нынче вообще фиг запустишь без танцев с бубном. А сишечка позволяет компильнуть сорец лохматого 1989 года, не переписывая полпрограммы.
> Скрипт писаный для бидона 2.4 нынче вообще фиг запустишь без танцев с бубном.Есть ложь, есть наглая ложь, и есть мнение анонимов про python :)
Все версии второго python обратно совместимы.
> Все версии второго python обратно совместимы.Наверное именно поэтому скрипт на питоне 2.4 валился в 2.7 с каким-то многоэтажным стэктрейсом.
>> Все версии второго python обратно совместимы.
> Наверное именно поэтому скрипт на питоне 2.4 валился в 2.7 с каким-то
> многоэтажным стэктрейсом.Этого быть не может. Ни первого, ни второго. :)
Единственное, что может на это влиять - это разные C-вставки в виде so-модулей. Когда собираемое gcc3, не собирается gcc4, по каким-то своим причинам, или из-за изменения в хидерах, или из-за изменения в чём угодно. Но это вопросы к gcc, а не к python.
Python-скрипты что для 2.4, что для 2.2, нормально выполняются в 2.7. Вероятно, есть какие-то ООООЧЕНЬ РЕЕЕДКИЕ исключения, но это явно не тот случай.
Давай уже скрипт, чтобы просто так не врать. :)
>>> Все версии второго python обратно совместимы.
>> Наверное именно поэтому скрипт на питоне 2.4 валился в 2.7 с каким-то
>> многоэтажным стэктрейсом.
> Этого быть не может. Ни первого, ни второго. :)Полной обратной совместимости нет ни в сях, ни в Питоне. Достаточно вспомнить запрет на строковые исключения в Python 2.6 или изменение типа аргументов и/или возвращаемых значений во многих функциях стандартной библиотеки Си на size_t.
Как уже говорилось, Питон куда моложе Си, поэтому проблем в этом плане у него больше. В первую очередь — в модулях, из-за нечаянных изменений, которые компилятор не в состоянии отследить — привет от динамической типизации.
> Единственное, что может на это влиять - это разные C-вставки в виде
> so-модулей. Когда собираемое gcc3, не собирается gcc4, по каким-то своим причинам,
> или из-за изменения в хидерах, или из-за изменения в чём угодно.
> Но это вопросы к gcc, а не к python.
> Python-скрипты что для 2.4, что для 2.2, нормально выполняются в 2.7. Вероятно,
> есть какие-то ООООЧЕНЬ РЕЕЕДКИЕ исключения, но это явно не тот случай.
> Давай уже скрипт, чтобы просто так не врать. :)Как человеку, который принимал непосредственное участие в выпиливании lang/python/2.5 из дерева портов OpenBSD и помнит километровые простыни патчей, чтобы заставить всё от него зависящее собираться _и_ работать под Python 2.7, мне очень смешно. Но лучше для подробностей даже не меня спросите (я в основном развлекался с kdebindings, это всё-таки специфичная штука), а, скажем, fgsch@.
> Потому, что этот самый Бидон в то время сам только рождался. Поэтому
> Л. о нём банально не мог знать. А иначе как знать, как знать... ;)Чушь не порите, а то дождётесь чушинальной юстиции...
И почитали бы торвальдсовскую книжку "Just for fun" -- там вполне ясно описано, почему он взялся писать ядро (и типун бы тут макроассемблер никак не заменил).
>Вон, одному финскому студенту тоже было интересно сделать что-то новое, похожее на миникс, но только свое.Вообще-то изначально он не собирался делать что-то похожее на миникс, ему было интересно разобраться с защищённым режимом i386. Сделать это можно только на ассемблере. Потом он сделал поверх этого терминал для доступа к компу в универе и реализовал доступ к файловой системе Minix. И только потом он подумал, что почти написал собственную ОС и решил реализовать для комплекта системные вызовы POSIX, постепенно проверяя уже написанное запуском программ из проекта GNU на своей ОС. Python тут вообще никаким боком не проканал бы.
Поэтому я и пользую deb-based, там как-то нет проблем с кривой питонятиной в пакетном менеджере.
> кривой питонятиной в пакетном менеджере.Пользователи Gentoo смотрят на вас с осуждением.
Нет, с завистью.
Я последнее время подумываю о смене своего домашнего компьютера (которому лет десять, наверное). Две причины меня на это сподвигают:
1. Слишком часто стали попадаться видеофайлы, на которые mplayer говорит "your system is too SLOW..." Взял за бутылку пива HD4850, стало существенно лучше, но всё равно бывает, и частота таких казусов возрастает со временем.
2. Тормозящий emerge, он зависимости считает настолько неспешно, что можно сходить попить чаю, покурить, и вернувшись смотреть дальше, как он тупит над расчётом депендансов.
> Тормозящий emerge, он зависимости считает настолько неспешно, что можно сходить попить чаю, покурить, и вернувшись смотреть дальше, как он тупит над расчётом депендансов.Ты бы еще на мобильном телефоне его запускал бы, ага.
>HD4850пользователь 9200 смотрит на вас с недоумением и жалостью
>>HD4850
> пользователь 9200 смотрит на вас с недоумением и жалостьюЧто, тоже за бутылку пива досталась?
Подарили
> 1. Слишком часто стали попадаться видеофайлы, на которые mplayer говорит "your system
> is too SLOW..." Взял за бутылку пива HD4850, стало существенно лучше,Поюзайте UVD-декодер. Надо:
1) свежее ядро, 3.10+ и возможно фирмвару GPU.
2) Свежую MESA, libg3dvl и libvdpau (библа vdpau и GPU-специфичные выноски).
3) Мплееру в config прописать что-то типа:
vo=vdpau,
vc=ffh264vdpau,ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,(внимание на запятые, это важно - запятая после записи позволяет fallback-ать на иные vo/vc если ваше видео не прожевалось железякой).
В результате многие видео грузят CPU процентов на 5, не более. Правда работает только для H.264/MP2/MP4. Насколько wmv и vc1 играется - хз, его у меня нет. VP8/9 оно не умеет.
> 2. Тормозящий emerge,
Как можно? "Бидон не тормозит!!!111"
>[оверквотинг удален]
> 1) свежее ядро, 3.10+ и возможно фирмвару GPU.
> 2) Свежую MESA, libg3dvl и libvdpau (библа vdpau и GPU-специфичные выноски).
> 3) Мплееру в config прописать что-то типа:
> vo=vdpau,
> vc=ffh264vdpau,ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,
> (внимание на запятые, это важно - запятая после записи позволяет fallback-ать на
> иные vo/vc если ваше видео не прожевалось железякой).
> В результате многие видео грузят CPU процентов на 5, не более. Правда
> работает только для H.264/MP2/MP4. Насколько wmv и vc1 играется - хз,
> его у меня нет. VP8/9 оно не умеет.Во-первых, спасибо за совет. Во-вторых, всё как выясняется, не так просто. Тот порнофайлик, которым я замерял производительность, увы, уже не тормозит -- видимо обновления mesa за последнее время, сыграли свою роль, теперь тот файлик кушает 35% CPU на всём своём протяжении. vdpau я давно использую, а вот все эти vc... Хрен знает почему, не работают. Я уж пересобрал ffmpeg, и mesa пересобрал (долго думал, откуда брать libg3dvl, выяснил что в mesa была такая либа, но в 9.2.1 нету, по-крайней мере промеж USE флагов не пробегает, и в /usr/lib64 не складывается, в сорцы ещё не заглядывал). Короче, надо лезть и читать что там да как, но ещё раз спасибо, за указанный путь.
> обновления mesa за последнее время, сыграли свою роль, теперь тот файлик
> кушает 35% CPU на всём своём протяжении.Ну а с VDPAU оно вообще считанные проценты CPU лопает (по крайней мере у меня это выглядит так).
> vdpau я давно использую,
При успешном использовании оного - mplayer пишет характерное инфо в консоль и нагрузка на проц - мизерная. Если у радеона DPM активирован - драйвер напишет в лог ядра что перешел на UVD-профиль. Еще можно утилитку vdpauinfo пнуть. Если VDPAU работает - утилитка покажет сведения о том что оно умеет. Так можно понять насколько VDPAU в системе вообще работает.
> а вот все эти vc... Хрен знает почему, не работают. Я
> уж пересобрал ffmpeg,С более-менее свежим ffmpeg VDPAU должен работать. В нем поддержка VDPAU уже давно есть. Как его собрать со поддержкой этого в генте - вам imho виднее.
> и mesa пересобрал (долго думал, откуда брать libg3dvl,
> выяснил что в mesa была такая либа, но в 9.2.1 нету,Это часть MESA. В MESA довески к либе vdpau собираются, с реализациями под конкретные GPU (libg3dvl - пакет с этими довесками в убунтовых так обозвали, я тут тупанул: в генте это если и есть то может называться иначе, если это уже как-то оформили). Если вы это будете сами mesa'у компилить - обратите внимание на размещение либ-довесков: libvdpau ищет довески в вполне характерном месте (IIRC что-то типа поддиректории vdpau/*.so в дире с либой vdpau). Если GPU-специфичных довесков там не окажется, кина не будет. Если нигде не накосячено, утилитка vdpauinfo успешно покажет информацию о VDPAU.
> по-крайней мере промеж USE флагов не пробегает, и в /usr/lib64 не
> складывается, в сорцы ещё не заглядывал).Ну если вы сами все это компилить полезли - уделите внимание раскладке библ довесков-плагинов к VDPAU. И да, это только в свежей MESA есть. В какой именно сие запилили для радеона - честно говоря я не помню. Но это было недавно.
> Короче, надо лезть и читать
> что там да как, но ещё раз спасибо, за указанный путь.Это слегонца WIP, т.к. для радеонов запилено без году неделю и не факт что считается окончательно стабильной фичой. Но работает. По факту все это стало работать где-то на момент выпуска 3.10...3.11 ядер линя, где были сделаны нужные для всего этого изменения, без которых драйвера не смогли бы юзеть UVD. Тогда же амдшники выложили более новые фирмвары для GPU. Где-то в те же времена и в MESA все это утолкали. Попало ли это в 9.2 - спросите что-нибудь попроще :). У меня давно MESA 10.0 (прототип). При том в убунте сие как-то сильно проще: достаточно oibaf-ppa подключить - там свежатина для желающих покамикадзить.
Насколько я понял, где-то на пути от mplayer'а до видяхи, не хватает поддержки h264, скорее всего в mesa. Надо ждать ебилдов для более свежей mesa. :)
> Насколько я понял, где-то на пути от mplayer'а до видяхи, не хватает поддержки h264,Звучит как-то странно. FFmpeg/mplayer без H.264 собирать по-моему никто в здравом уме не рискует. VDPAU его тоже умеет наверное с момента появления, или около того.
> скорее всего в mesa.
Ну да, скорее всего понадобится MESA 9.3 (теперь уже 10.0).
> Надо ждать ебилдов для более свежей mesa. :)
А у убунтушников уже дело на мази :P.
>Я последнее время подумываю о смене своего домашнего компьютера (которому лет десять, наверное).Сегодня emerge'ить на одноядерном процессоре? Ну это просто смешно. Об апгрейде машинки для этого надо было задуматься ещё года четыре назад.
Апгрейдить машинку только ради запуски поделок на бидоне ?
А софт вам папа Карло компилирует?
> А софт вам папа Карло компилирует?Нормальным людям его компилируют мейнтейнеры :)
> Нормальным людям его компилируют мейнтейнеры :)Ну вот как-то так и получается:
- Питон не тормозит!!!1111 (по версии фанатов питона).
- Гентушники яро упирают на оптимизацию....но машину апгрейдить им почему-то все-таки надо, при том с аргументом что 1 ядра - мало, etc :). Поравзели, понимаешь, террариум-компилферму.
> А софт вам папа Карло компилирует?Не, процессор компилирует. Но офисными пакетами я не пользуюсь, злые кеды с гномами всё равно огромный оверхед в моих руках. А то, что несмотря на это, обновление системы длится часов десять, меня как-то не сильно колышет, ибо система моя многозадачная и позволяет работать несмотря на параллельный процесс компиляции, который тихонько крутится себе в консоле. Производительность питона важнее, поскольку речь идёт об т.н. "интерактивной" работе.
> обновление системы длится часов десятьВот охота некоторым воздух отапливать своей билд-фермой...
> Производительность питона
...она где? Его дефолтная инкарнация - интерпретер галимый, со всеми вытекающими, как то - скорость в разы ниже компиляторов "сразу на старте". И то что его можно скомпилить в байткод - до лампочки, т.к. потом этот байткод опять же интерпретируется. А все потуги сделать компилер - не особо успешны и чаще всего реализуют урезанную версию языка. Вот как-то так питон и телепается уже много лет.
>> обновление системы длится часов десять
> Вот охота некоторым воздух отапливать своей билд-фермой...Вы хотите об этом поговорить?
>> Производительность питона
> ...она где? Его дефолтная инкарнация - интерпретер галимый, со всеми вытекающими, как
> то - скорость в разы ниже компиляторов "сразу на старте". И
> то что его можно скомпилить в байткод - до лампочки, т.к.
> потом этот байткод опять же интерпретируется. А все потуги сделать компилер
> - не особо успешны и чаще всего реализуют урезанную версию языка.
> Вот как-то так питон и телепается уже много лет.Зачем вы мне всё это рассказываете?
> Пользователи Gentoo смотрят на вас с осуждением.Видал я тут одного кадра. У него портажи сломались т.к. версия бидона не та. Хахаха, бидон даже там подгадить ухитряется.
В дебиане кривая плюсятина, что еще хуже. За поломанный pinning в apt-е вообще убивать надо. Его (pinning) как криво написали в 90-х, так до сих пор трогать боятся, чтобы оно еще больше не завоняло.
> В дебиане кривая плюсятина, что еще хуже.Оно по крайней мере работает и каши не просит. И не требует, б, 512М каждой виртуалке выдавать, "потому что иначе yumская питонятина всю память выжирает".
> так до сих пор трогать боятся, чтобы оно еще больше не завоняло.
Это вообще фича которую надо использовать реже чем стопкран в самолете.
>> В дебиане кривая плюсятина, что еще хуже.
> Оно по крайней мере работает и каши не просит. И не требует,
> б, 512М каждой виртуалке выдавать, "потому что иначе yumская питонятина всю
> память выжирает".Бяда бяда огорчение. а я свои приложения, да и не свои, запускал на p120/24/netbsd/python2.7 - и работало та таки, заразо.
Хоть сходи, не позорься, запусти ту же джангу, и посмотри, сколько памяти оно требует. И это джанго, питонный монстр!
> Бяда бяда огорчение. а я свои приложения, да и не свои, запускал
> на p120/24/netbsd/python2.7 - и работало та таки, заразо.Hello world может и будет работать, а пакетный манагер кладет VM по OOM как делать нефиг.
>> так до сих пор трогать боятся, чтобы оно еще больше не завоняло.
> Это вообще фича которую надо использовать реже чем стопкран в самолете.Без нее пакетным менеджером в дебиане пользоваться нереально. Потому что одним stable жив не будешь, а если вручную качать и ставить через dpkg, получится слака.
> Без нее пакетным менеджером в дебиане пользоваться нереально. Потому что одним
> stable жив не будешь, а если вручную качать и ставить через dpkg, получится слака.Ну так testing или sisyphus, в чём проблема-то?
> Ну так testing или sisyphus, в чём проблема-то?Проблема в том что консистентность и беспроблемность всего этого никто не гарантирует сколь-нибудь серьезно. И если кому-то допустим горит некую работу сделать, а тут в системе после обновления кирдык - это может быть совсем не в кассу...
>> Ну так testing или sisyphus, в чём проблема-то?
> Проблема в том что консистентность и беспроблемность всего этого никто не гарантирует
> сколь-нибудь серьезно.Консистентность гарантируется техническими средствами, в альте уже давно 0 unmets.
> И если кому-то допустим горит некую работу сделать, а тут в системе после
> обновления кирдык - это может быть совсем не в кассу...Вот только не надо тогда про убунту, да и про дебиан, кстати, тоже. Тут вон недавно коллега напоролся на невозможность поднять virtualbox (не буду перевирать, но там получился клин dkms и версий gcc, с которыми собирается и работает модуль и юзерспейс).
Когда горит работу делать -- не делайте обновления или делайте бэкапы/снапшоты корня. Вне зависимости от системы.
> Консистентность гарантируется техническими средствами, в альте уже давно 0 unmets.А еще автор программы может поменять ее несовместимо с старыми версиями и при обновлении все умрет. Что может быть очень некстати в системе от которой надо предсказуемую работу. Не вижу какие технические средства могут это обработать.
>> обновления кирдык - это может быть совсем не в кассу...
> Вот только не надо тогда про убунту, да и про дебиан, кстати,Именно между релизами - как правило ничего не отламывают. Разумеется, идеальных систем не бывает и какие-то исключения из правила найдутся. Но в целом по моему опыту - если заработало, то до следующего релиза как правило не отломается. А вот при использовании тестинга/анстейбла/кактамувасэтоназывается - вот это уже совсем не факт и система превращается в большой тестлаб, где никто никому ничего не обещал и даже не пытался.
> тоже. Тут вон недавно коллега напоролся на невозможность поднять virtualbox
> (не буду перевирать, но там получился клин dkms и версий gcc,
> с которыми собирается и работает модуль и юзерспейс).Про vbox ничего не скажу - не использую. Мне KVM хватает - оно часть ядра линукс и есть и без всяких прилуд от оракла, а фич qemu на пять vbox-ов хватит. ИМХО, основная проблема vbox-а - он довольно ортогонален линуксу в целом и его ядерный выносок - ни разу не майнлайн. Это хороший потенциал для грабель, как ни крути.
> Когда горит работу делать -- не делайте обновления или делайте бэкапы/снапшоты корня.
А оно мне надо - тратить время на костылестроение и потом рекавери?
> Вне зависимости от системы.Фокус в том что в убунтообразных как правило и без всего этого катит. Ну то-есть бэкапы это хорошо, но привязываться к моменту обновления - да ну нафиг. У меня как-то после обновлений ничего не отпадало. Не путать с апгрейдом версий дистра - вот там факапы могут быть. Но их момент заранее известен, ну и т.к. дебианский пакетный манагер штука довольно дypaкостойчивая - именно фатально что-то изломать там еще ухитриться надо.
> Не вижу какие технические средства могут это обработать.Сами же ниже процитировали.
>> Когда горит работу делать -- не делайте обновления или делайте бэкапы/снапшоты корня.
> А оно мне надо - тратить время на костылестроение и потом рекавери?Что неясно? Если работа неважна, то и бэкапы можно не делать. Если важна -- делать их надо. Другой вопрос, что применять хотелось бы пореже.
> Без нее пакетным менеджером в дебиане пользоваться нереально. Потому что одним stable
> жив не будешь,...поэтому я и пользую хубунту относительно свежую. Дебианщики с их суперстабильно законсервированными багами - на десктопа не очень просты в использовании, при всем уважении.
> 512М каждой виртуалке выдавать,моя смотрит на твоя с недоумением... т.к. у моя шаблон для виртуалок начинается 1Гx2cpu, даже для тестовых серверов. Экономим на спичках?
>> 512М каждой виртуалке выдавать,
> моя смотрит на твоя с недоумением... т.к. у моя шаблон
> для виртуалок начинается 1Гx2cpu, даже для тестовых серверов. Экономим на спичках?А теперь представь, что половину твоей виртуалки выжирает yum, когда ты его запускаешь.
>>> 512М каждой виртуалке выдавать,
>> моя смотрит на твоя с недоумением... т.к. у моя шаблон
>> для виртуалок начинается 1Гx2cpu, даже для тестовых серверов. Экономим на спичках?
> А теперь представь, что половину твоей виртуалки выжирает yum, когда ты его
> запускаешь.М-дэ.
В соседнем окне проскальзывают сообщения из разряда "залейте, плз, свежий снапшот пакетов для mips64". Собранный на собственно MIPS. При помощи фирменных опёнковского сборщика пакетов и pkg_add.
Это я молчу про VAX, где всё вышеперечисленное умещается в тридцать метров оперативки. Суммарно. Потому что иначе не взлетит.
В общем, чем больше я познаю линуксовые управлялки пакетами, тем больше нравятся все остальные...
> М-дэ.
> В соседнем окне проскальзывают сообщения из разряда "залейте, плз, свежий снапшот пакетов
> для mips64". Собранный на собственно MIPS. При помощи фирменных опёнковского сборщика
> пакетов и pkg_add.
> Это я молчу про VAX, где всё вышеперечисленное умещается в тридцать метров
> оперативки. Суммарно. Потому что иначе не взлетит.
> В общем, чем больше я познаю линуксовые управлялки пакетами, тем больше нравятся
> все остальные...1. Зачем pkg_add на perl переписали? netbsd-шный до сих пор сишный, и каких-то особенных неудобств я не заметил :) Вообще, лично я бы предпочёл python.
2. И современный debian, и современный openbsd можно запустить на p120/24. При этом, иксы - только в openbsd 4.2. Начиная с 4.3 произошло ЧТО-ТО, что любая версия openbsd от 4.3 до 5.4 выпадает в ddb при запуске. Флопи или rd-ядро - работают нормально, но иксы на них не запустишь. :(
3. Рядом с aptitude вообще ничего не стояло. В принципе. Это как сравнивать vi и ed. Разумеется, для тех, кто может держать в памяти 35000 пакетов (или 35000 символов) (или 35000 курьеров), и ed - самое то, но когда нужно, чтобы это помнил компьютер, а не ты - альтернативы просто нет. Даже близко. Даже на расстоянии световых лет. Из каменного века - в сверхсветовой. У меня просто нет слов, чтобы описать, насколько aptitude экономит время по сравнению со всем остальным, вместе взятым. Эх, если бы к aptitude ещё лучшее из openbsd-шного инсталлятора (кстати, в чём смысл делать по умолчанию консоль vt220 и пейджер more?), да евойную же базовую систему - я бы сразу женился.
4. Товарищ, дай свой е-мейл или джаббер, есть иногда меееелкие вопросы по openbsd, а спросить не у кого. Напиши мне на me@51t.ru
(прошу прощения за поздний ответ, иногда не думаю и на автомате отвечаю письмом - вот чего не хватает на Опеннете; а отлуп приходит далеко не сразу)>[оверквотинг удален]
>> фирменных опёнковского сборщика пакетов и pkg_add.
>> Это я молчу про VAX, где всё вышеперечисленное умещается в тридцать метров
>> оперативки. Суммарно. Потому что иначе не взлетит.
>> В общем, чем больше я познаю линуксовые управлялки пакетами, тем больше
>> нравятся все остальные...
>
>
> 1. Зачем pkg_add на perl переписали? netbsd-шный до сих пор сишный, и
> каких-то особенных
> неудобств я не заметил :) Вообще, лично я бы предпочёл python.Потому что после переписывания стало быстрее работать. :) Серьёзно. Perl, конечно, добавляет немного потерь в I/O, но за счёт простоты использования сложных структур данных (нативные хеш-таблицы), заботу по производительности которых берёт на себя среда, позволяет создавать достаточно быстрые приложения. Модель памяти у него более чётко
описана и более предсказуема, чем, например, у Питона... Плюс всё же - заметная экономия времени разработки, что при дефиците рабочих рук - важный фактор.К слову сказать, pkg_add и компания "внутри себя" с тех пор ещё пару раз были переписаны. Но внешне этого не было заметно, разве что появлялись в результате какие-то долгожданные плюшки.
И что важно, в менеджер пакетов должен, собственно, работать. Во всём, что основано на dpkg, я видел кучу свистоперделок, и при этом регулярно - мелкие факапы: тут получилась какая-то несовместимая конфигурация пакетов, и apt-get встал раком; здесь без объяснения причин не проходило обновление части пакетов...
Не сказать, что в pkg_add никогда не было багов - были, конечно. И сейчас он не лишён проблем - например, вылеты в кору чего-то там при обновление между крупными релизами GTK. Но в целом юзабельно. Ну и база пакетов в удобном формате, если что-то уж совсем накроется, да так, что pkg_check не спасёт - можно просто ручками поправить.
Справедливости ради также отмечу, что во многих линуксовых менеджерах пакетов есть поддержка дельта-файлов, а в OpenBSD она пока лишь в планах. pkg_add, он, конечно, умный, и лишний раз файлы не перезаписывает, и пакеты сверх "заголовока" без нужды не качает - но
всё же иногда раздражает, да. А уж когда сидишь на EDGE, ибо нужда заставляет... В общем, Марк что-то там говорил недавно, мол, к нынешнему pkg_add это должно быть не сложно прикрутить. Но он один, а хотелок много. :) Patches are welcome.> 2. И современный debian, и современный openbsd можно запустить на p120/24.
> При этом, иксы
> - только в openbsd 4.2. Начиная с 4.3 произошло ЧТО-ТО, что любая версия
> openbsd от 4.3
> до 5.4 выпадает в ddb при запуске. Флопи или rd-ядро - работают нормально,
> но иксы на них
> не запустишь. :(Тут ничего не скажу, смотреть надо. Для X.org 24 метра - довольно мало, но дело может быть в чём-то совсем постороннем. Я видел сообщения, что на машины@i386 подобного уровня Опёнок совсем недавно ставили, но насчёт использования там иксов ничего не знаю. Можно поковыряться, если интересно. Начиная с dmesg из установочного ядра.
>[оверквотинг удален]
> компьютер, а не ты -
> альтернативы просто нет. Даже близко. Даже на расстоянии световых лет. Из
> каменного века
> - в сверхсветовой. У меня просто нет слов, чтобы описать, насколько aptitude
> экономит
> время по сравнению со всем остальным, вместе взятым. Эх, если бы к aptitude
> ещё лучшее из
> openbsd-шного инсталлятора (кстати, в чём смысл делать по умолчанию консоль
> vt220 и
> пейджер more?), да евойную же базовую систему - я бы сразу женился.Хм. aptitude - это, конечно, хорошо - когда не глючит. Я с ним успел "заработать" - в стабильной ветке! - и проблемы с тем же терминалом, и глюки работы (натыкался на какой-то баг в поиске пакетов - долго удивлялся, почему не могу найти, полез в инет - а там я не один с такой проблемой).
Для быстрого поиска нужного пакета в консоли есть pkg_locatedb и sqlports. Нужно, скажем, найти, в каком пакете лежит konqueror - вбиваешь "pkg_locate bin/konqueror" и моментально получаешь ответ.
Были и какие-то попытки делать ncurses- и X11-менеджеры пакетов (помню pkg_mgr), но все они, по-моему, загнулись.
vt220 - чем он конкретно плох? vt100/vt220 знают практически все... Оно, конечно, прикольно было бы иметь эмулятор xterm в консоли, де Раадт не против. :) Только кто б занялся.
Насчёт же more - я когда-то начал ставить по дефолту less. А потом вернулся к more. Потому что more не очищает экран при выходе, и это удобно: открыл мануал/readme пакета/etc., нашёл нужное место, закрыл мануал и копируешь/вбиваешь команды ручками. Ну а просто файлы смотрю тем, что потребнее по ситуации. Разве что прописал MORE="-e -i" в ~/.profile. :)
И, к слову, less чуть требовательнее к ресурсам и возможностям терминала. В частности, на дефолтных RAMDISK'ах less использовать нереально, а с more можно договариваться.
> 4. Товарищ, дай свой е-мейл или джаббер, есть иногда меееелкие вопросы по
> openbsd, а
> спросить не у кого. Напиши мне на me@51t.ruЧем плох zhuk@openbsd.org ? :) Я открыт для нормального общения.
> И что важно, в менеджер пакетов должен, собственно, работать. Во всём, что
> основано на dpkg, я видел кучу свистоперделок, и при этом регулярно
> - мелкие факапы: тут получилась какая-то несовместимая конфигурация пакетов, и apt-get
> встал раком; здесь без объяснения причин не проходило обновление части пакетов...Debian-у не хватает концепции 'base system' :) Всё остальное - следствия - всё это стремление разбить на модульки, модулюшки и модулюшечки ради экономии 22 миллибайт не знаю чего - оборачивается проблемами несовместимости. Взять тот же emdebian - чего-то не хватает, и всё.
>> до 5.4 выпадает в ddb при запуске. Флопи или rd-ядро - работают нормально,
>> но иксы на них
>> не запустишь. :(
> Тут ничего не скажу, смотреть надо. Для X.org 24 метра - довольно
> мало,дело не в xorg, а в том, что в принципе на конкретном компьютере, древнем и сердитом, перестало запускаться. :( в qemu с -m 24 нормально работает.
на /bsd. на bsd.rd и на floppy - запускалось, но там не было апертур или чего-то подобно-мистического (мне нравится /ru/faq - часть на немецком, части вообще нет :)тот же netbsd запускается последняя версия. но netbsd... иксы мне там удалось запустить только раз, в qemu. в openbsd, разных версий, они работали ВЕЗДЕ, от p120/24, до всех моих компьютеров. :)
впрочем, тот компьютер уже умер. :) а жаль :(
> сообщения, что на машины@i386 подобного уровня Опёнок совсем недавно ставили, но
> насчёт использования там иксов ничего не знаю. Можно поковыряться, если интересно.
> Начиная с dmesg из установочного ядра.тупо вываливается в ddb при загрузке, я сначала на scsi грешил, потому что после его вызова вылетало, убрал через -c scsi и всё похожее - всё равно вылетало. любая версия, начиная с 4.3. в 4.2 и всех ранних - работало. впрочем, я особо не заморачивался, мне главное - факт работы из коробки. :) питон на нём гонял с приложениями, меряя скорость и работоспособность. :)
> Хм. aptitude - это, конечно, хорошо - когда не глючит. Я с
> ним успел "заработать" - в стабильной ветке! - и проблемы с
> тем же терминалом, и глюки работы (натыкался на какой-то баг в
> поиске пакетов - долго удивлялся, почему не могу найти, полез в
> инет - а там я не один с такой проблемой).Я один раз сапёра запустил во время установки - упал сразу :) Это было самое серьёзное. Но самое главное - aptitude это визуальный редактор, куча фильтров поиска, когда результат не показывается, а прямо помещается под клавиатуру - хошь жми "+" и добавляй на установку, хошь смотри визуально соседние пакеты (набрал gimp и ходишь выбираешь нужные плюгины), хошь выбирай версию. Сервис!
> vt220 - чем он конкретно плох? vt100/vt220 знают практически все... Оно, конечно,
> прикольно было бы иметь эмулятор xterm в консоли, де Раадт не
> против. :) Только кто б занялся.в mc не работает половина клавиатуры. в linux, понятное дело, TERM=linux, а тут? Вроде, нашёл wsvt25, прописал его (не в ,profile, а где консоли перечисляются).
>> 4. Товарищ, дай свой е-мейл или джаббер, есть иногда меееелкие вопросы по
>> openbsd, а спросить не у кого. Напиши мне на me@51t.ru
> Чем плох zhuk@openbsd.org ? :) Я открыт для нормального общения.Тем, что не знал. Вообще, видел этот адрес, когда смотрел paper про kde4, порадовал слайд про то, что kde3.5 остаётся ещё на много лет :)
Ну, вопросы про снапшоты интересуют - кто как живёт, как часто надо обновляться, порты или пакеты?Я на одном компьютере в итоге на 5.4 откатился (базу взял с snapshots/i386/t32, пакеты с 5.4/packages), потому что в снапшотах началась проблема регулярного вылета в ddb с руганью на модуль jme (сетевая карта) :(
ну и недостаток пакетов. на втором компьютере ati r600, как я понимаю, оно только в снапшотах поддерживается (kms - точно, если на первом ati rs690, и она даёт ошибку и отключает акселлерацию, так что разницы 5.4 или снапшоты - нет)... то есть, там всё нормально, fw_update и акселлерация работает, но постоянно не хватает пакетов - я пытался поставить с пакетов gnome 3.10, половины просто не было. я дособрал с портов, но начались сегфолты и другие неприятные вещи :( вообще, реально снапшотами без проблем пользоваться, или лучше брать release? Видимо, на этом компьютере 5.5 ждать придётся :)
Кстати, что там с 5.5. План "64 битное время везде" - как на портах скажется? :) Некогда обновлять будет? :)
>[оверквотинг удален]
>>> но иксы на них
>>> не запустишь. :(
>> Тут ничего не скажу, смотреть надо. Для X.org 24 метра - довольно
>> мало,
> дело не в xorg, а в том, что в принципе на конкретном
> компьютере, древнем и сердитом, перестало запускаться. :( в qemu с -m
> 24 нормально работает.
> на /bsd. на bsd.rd и на floppy - запускалось, но там не
> было апертур или чего-то подобно-мистического (мне нравится /ru/faq - часть на
> немецком, части вообще нет :)Хм. На jabber.ru#openbsd можно постучаться, узнать новости. Я уже настолько привык всё на английском читать, что увы. Рад бы заняться, только некогда. :(
>[оверквотинг удален]
>> ним успел "заработать" - в стабильной ветке! - и проблемы с
>> тем же терминалом, и глюки работы (натыкался на какой-то баг в
>> поиске пакетов - долго удивлялся, почему не могу найти, полез в
>> инет - а там я не один с такой проблемой).
> Я один раз сапёра запустил во время установки - упал сразу :)
> Это было самое серьёзное. Но самое главное - aptitude это визуальный
> редактор, куча фильтров поиска, когда результат не показывается, а прямо помещается
> под клавиатуру - хошь жми "+" и добавляй на установку, хошь
> смотри визуально соседние пакеты (набрал gimp и ходишь выбираешь нужные плюгины),
> хошь выбирай версию. Сервис!В этом плане да, удобно. Впрочем, не думаю, что аналог на ncurses для OpenBSD было бы сложно написать. Или взять за базу кодовую базу dpb (espie@ недавно туда ещё и цвета прикрутил зачем-то :) ), чтобы иметь готовую работу с терминалом и с OpenBSD::*... В общем, было бы желание и чуть-чуть умения, а допилить можно и всем миром.
>> vt220 - чем он конкретно плох? vt100/vt220 знают практически все... Оно, конечно,
>> прикольно было бы иметь эмулятор xterm в консоли, де Раадт не
>> против. :) Только кто б занялся.
> в mc не работает половина клавиатуры.
> в linux, понятное дело, TERM=linux, а
> тут? Вроде, нашёл wsvt25, прописал его (не в ,profile, а где
> консоли перечисляются).Тут вряд ли чем помогу, мне mc обычно больше мешает. Сейчас вот специально ставить пришлось, чтобы посмотреть на него нынешнего. :)
>>> 4. Товарищ, дай свой е-мейл или джаббер, есть иногда меееелкие вопросы по
>>> openbsd, а спросить не у кого. Напиши мне на me@51t.ru
>> Чем плох zhuk@openbsd.org ? :) Я открыт для нормального общения.
> Тем, что не знал. Вообще, видел этот адрес, когда смотрел paper про
> kde4, порадовал слайд про то, что kde3.5 остаётся ещё на много
> лет :)Если бы в KDE4 не переломали кучу всего, то, глядишь, и переехали бы. А так - да, пока остаётся. Всё посматриваю в сторону TDE - вроде, проект живёт, но портированием заниматься стабильно пока ни у кого не получается. Оно и понятно, там вовлечённость в разработку нужна немаленькая...
> Ну, вопросы про снапшоты интересуют - кто как живёт, как часто надо
> обновляться, порты или пакеты?В плане, как живёт? На десктопе обычно проще со снапшотами, ибо всегда свежий софт и можно что-нибудь с ports@ или tech@ потестировать. Как часто обновляться - кто как, я лично обновлялся где-то раз в три месяца до недавнего времени, что для активно вовлечённого в проект человека довольно большой интервал, - но это потому что пересобирать каждый раз весь KDE4 немного задалбывало. :) Теперь, когда официальные пакеты появились, стало попроще; вот как раз сейчас буду - недавно было обновление libc (убрали arc4random_stir() и arc4random_addrandom()) и libkvm. Если обновляться после смены версий основных либ (в базовой системе или xenocara; лего отслеживается по изменению файлов shlib_version), то не придётся тратить время на сборку из портов.
> Я на одном компьютере в итоге на 5.4 откатился (базу взял с
> snapshots/i386/t32, пакеты с 5.4/packages), потому что в снапшотах началась проблема регулярного
> вылета в ddb с руганью на модуль jme (сетевая карта) :(Транскрипцию panic на misc@, что тут ещё можно сказать. Я всегда храню старый снапшот про запас на такой случай. Один раз пригодилось.
> ну и недостаток пакетов. на втором компьютере ati r600, как я понимаю,
> оно только в снапшотах поддерживается (kms - точно, если на первом
> ati rs690, и она даёт ошибку и отключает акселлерацию, так что
> разницы 5.4 или снапшоты - нет)... то есть, там всё нормально,
> fw_update и акселлерация работает, но постоянно не хватает пакетов - я
> пытался поставить с пакетов gnome 3.10, половины просто не было. я
> дособрал с портов, но начались сегфолты и другие неприятные вещи :(
> вообще, реально снапшотами без проблем пользоваться, или лучше брать release? Видимо,
> на этом компьютере 5.5 ждать придётся :)Снапшотами пользоваться вполне реально, а Гнома не было - видимо, это так повезло, разрабы ведь предупреждали, что после импорта ещё несколько дней будут до ума доводить. А потом ещё пакеты собраться сами должны - полная сборка на опёнковском кластере amd64 сейчас занимает полтора дня (до KDE4 было на пару часов меньше :)). Плюс ещё time_t и ряд других крупных изменений в API/ABI, несколько дней в пакетах было много сломанного. Да и сейчас ещё по мелочи что-то не успели починить. Например, на данный момент вход в настройки в chromium отправляет в сегфолт, а productivity/taskjuggler не проходит собственные тесты на i386.
На основной работе в production сейчас одна из немногих виртуалок с опёнком бегает на 5.4-beta, обновлять не спешу. Там всё равно дрянь вроде Redmine крутится, я для неё порты пробовал собирать, но чуть не повесился, плодя ruby gems... Надо бы, наверное, какую-то инфраструктуру дополнительную приделывать для таких upstream-репозиториев, но пока достойных идей в голову не приходило.
> Кстати, что там с 5.5. План "64 битное время везде" - как
> на портах скажется? :) Некогда обновлять будет? :)Процесс переезда в связи с изменением time_t, ino_t и прочих описан в http://www.openbsd.org/faq/current.html#20130813 . Основная идея: сохраняем список установленных пакетов, удаляем их, обновляемся, ставим обратно из списка. Увы, геморройно, но иначе никак - сосуществование пакетов с разными ABI нереально.
> В этом плане да, удобно. Впрочем, не думаю, что аналог на ncurses
> для OpenBSD было бы сложно написать. Или взять за базу кодовую
> базу dpb (espie@ недавно туда ещё и цвета прикрутил зачем-то :)
> ), чтобы иметь готовую работу с терминалом и с OpenBSD::*... В
> общем, было бы желание и чуть-чуть умения, а допилить можно и
> всем миром.Тогда нужно было прикручивать и тэги, и три вида зависимостей, и другие вещи. aptitude вышла из dselect, и вокруг этой dselect была целая идеология. это не просто юзер интерфейс, это штука, в которую в 10 нажатий на клавиши на клавиатуре можно получить всё нужное, не получив при этом ненужное и затратив минимум внимания и концентрации.
Впрочем, когда все пакеты видны в панели mc - это тоже возможность "выбирать и ставить". В Debian так нельзя. :)
> Тут вряд ли чем помогу, мне mc обычно больше мешает. Сейчас вот
> специально ставить пришлось, чтобы посмотреть на него нынешнего. :)Мне-то всё равно, я поменяю. Просто непонятно, почему. :) Если мне нужно просто запустить rsync зеркала или dpb -F, то я и иксы не запускаю. :)
> Если бы в KDE4 не переломали кучу всего, то, глядишь, и переехали
> бы. А так - да, пока остаётся.И это хорошо. Одно из больших достоинств. Как только в снапшоты упали пакеты из kde4, так я сразу и удалил :) Ну, не из-за этого удалил, на другой компьютер перенёс distfiles и packages от снепшотов, а на этом поставил 5.4 (релиз послепослезавтра? как я понимаю, файлы уже не изменятся?)
>> вылета в ddb с руганью на модуль jme (сетевая карта) :(
> Транскрипцию panic на misc@, что тут ещё можно сказать. Я всегда храню
> старый снапшот про запас на такой случай. Один раз пригодилось.Оно на протяжении месяца были. Я на такие случаи в debian дуалбутюсь - ради того же флеш-видео со sportbox.ru. Но я уже снёс инсталляцию и поставил 5.4
> Снапшотами пользоваться вполне реально,Я на них и сидел. Но болезнь "обновлизм" их только поломала. Хорошая вещь '-release', обновляться вообще не надо :)
> до ума доводить. А потом ещё пакеты собраться сами должны -
> полная сборка на опёнковском кластере amd64 сейчас занимает полтора дня (до
> KDE4 было на пару часов меньше :)).Мне непонятно, почему пакеты вообще пропускаются. Как может собраться куча пакетов, зависящих от pcre 8.32, но при этом самого пакета pcre 8.32 не быть (это реальный случай несколькимесячной давности). И такое - постоянно, каких-то файлов в packages просто нет. Вот мне и интересно, почему?
>> Кстати, что там с 5.5. План "64 битное время везде" - как
>> на портах скажется? :) Некогда обновлять будет? :)
> Процесс переезда в связи с изменением time_t, ino_t и прочих описан в
> http://www.openbsd.org/faq/current.html#20130813 . Основная идея: сохраняем список
> установленных пакетов, удаляем их, обновляемся, ставим обратно из списка. Увы, геморройно,
> но иначе никак - сосуществование пакетов с разными ABI нереально.Я имею ввиду, что пока всё не сделают поддерживаемым, на другое внимания обращать не будет? Или, наоборот, повод обновить те вещи в портах, которые не обновлялись по 6 лет? :)
А переустановка через pkg_delete `pkg_info -v` - это вообще красотища! :) В Debian есть элегантное решение aptitude renistall ~i... но оно не работает, сразу отваливается, потому что не может обновить dpkg. :) А когда есть базовая система, а пакеты - сбоку прилепка, можно хоть все удалить. :)
>[оверквотинг удален]
> Мне-то всё равно, я поменяю. Просто непонятно, почему. :) Если мне нужно
> просто запустить rsync зеркала или dpb -F, то я и иксы
> не запускаю. :)
>> Если бы в KDE4 не переломали кучу всего, то, глядишь, и переехали
>> бы. А так - да, пока остаётся.
> И это хорошо. Одно из больших достоинств. Как только в снапшоты упали
> пакеты из kde4, так я сразу и удалил :) Ну, не
> из-за этого удалил, на другой компьютер перенёс distfiles и packages от
> снепшотов, а на этом поставил 5.4 (релиз послепослезавтра? как я понимаю,
> файлы уже не изменятся?)Не изменятся. Релиз как обычно, да.
>[оверквотинг удален]
>> Снапшотами пользоваться вполне реально,
> Я на них и сидел. Но болезнь "обновлизм" их только поломала. Хорошая
> вещь '-release', обновляться вообще не надо :)
>> до ума доводить. А потом ещё пакеты собраться сами должны -
>> полная сборка на опёнковском кластере amd64 сейчас занимает полтора дня (до
>> KDE4 было на пару часов меньше :)).
> Мне непонятно, почему пакеты вообще пропускаются. Как может собраться куча пакетов, зависящих
> от pcre 8.32, но при этом самого пакета pcre 8.32 не
> быть (это реальный случай несколькимесячной давности). И такое - постоянно, каких-то
> файлов в packages просто нет. Вот мне и интересно, почему?Больше похоже на проблему с локальным зеркалом. Если такое возникает на ftp.openbsd.org — повод писать на ports@. Но я пока о таком не слышал, или не помню. А зеркала дурят порой, это да.
>>> Кстати, что там с 5.5. План "64 битное время везде" - как
>>> на портах скажется? :) Некогда обновлять будет? :)
>> Процесс переезда в связи с изменением time_t, ino_t и прочих описан в
>> http://www.openbsd.org/faq/current.html#20130813 . Основная идея: сохраняем список
>> установленных пакетов, удаляем их, обновляемся, ставим обратно из списка. Увы, геморройно,
>> но иначе никак - сосуществование пакетов с разными ABI нереально.
> Я имею ввиду, что пока всё не сделают поддерживаемым, на другое внимания
> обращать не будет? Или, наоборот, повод обновить те вещи в портах,
> которые не обновлялись по 6 лет? :)Не пойму, что значит «сделать поддерживаемым». Оно или работает, или нет. «Не собирается», «не запускается», «портит данные» — это всё «не работает». Исправления в портах начали весь ещё до переезда на 64-битный time_t & Co. Сейчас список поломанного минимален, и касается больше 32-битных систем, из-за того, что в Линуксе time_t есть long.
> А переустановка через pkg_delete `pkg_info -v` - это вообще красотища! :) В
> Debian есть элегантное решение aptitude renistall ~i... но оно не работает,
> сразу отваливается, потому что не может обновить dpkg. :) А когда
> есть базовая система, а пакеты - сбоку прилепка, можно хоть все
> удалить. :)
>> файлов в packages просто нет. Вот мне и интересно, почему?
> Больше похоже на проблему с локальным зеркалом. Если такое возникает на ftp.openbsd.org
> — повод писать на ports@. Но я пока о таком не
> слышал, или не помню. А зеркала дурят порой, это да.Не знаю, сравнивал и с ftp.openbsd.org, и с двумя моими регулярными зеркалами, с которых я и делаю локальное - всё идентично. Если файла нет, то его нет нигде. Кстати, после 15-го октября, когда я поймал "полупустой", снапшоты где-то дней 10, что ли, не обновлялись, числа до 25-го.
>> Я имею ввиду, что пока всё не сделают поддерживаемым, на другое внимания
>> обращать не будет? Или, наоборот, повод обновить те вещи в портах,
>> которые не обновлялись по 6 лет? :)
> Не пойму, что значит «сделать поддерживаемым». Оно или работает, или нет. «Не
> собирается», «не запускается», «портит данные» — это
> всё «не работает».Я не знаю, что такое 64-битный time_t, я далёк от этого. Просто прочитал где-то в каких-то анонсах (или даже в пейперах было, не помню), что все порты будут шерстить на предмет поддержки, включая всякие базы данных и прочее. Вот я и подумал, что теперь будут ПЕРЕПАХИВАТЬ ВСЁ. :)
>>> файлов в packages просто нет. Вот мне и интересно, почему?
>> Больше похоже на проблему с локальным зеркалом. Если такое возникает на ftp.openbsd.org
>> — повод писать на ports@. Но я пока о таком не
>> слышал, или не помню. А зеркала дурят порой, это да.
> Не знаю, сравнивал и с ftp.openbsd.org, и с двумя моими регулярными зеркалами,
> с которых я и делаю локальное - всё идентично. Если файла
> нет, то его нет нигде. Кстати, после 15-го октября, когда я
> поймал "полупустой", снапшоты где-то дней 10, что ли, не обновлялись, числа
> до 25-го.Кстати да, обновлений именно в этот период не было, по двум причинам. Во-первых, хакатон в Германии; во-вторых, как оказалось, новую рабочую батарейку для контроллера в одном из основных серверов инфраструктуры найти проблематично. :-\
>[оверквотинг удален]
>>> обращать не будет? Или, наоборот, повод обновить те вещи в портах,
>>> которые не обновлялись по 6 лет? :)
>> Не пойму, что значит «сделать поддерживаемым». Оно или работает, или нет. «Не
>> собирается», «не запускается», «портит данные» — это
>> всё «не работает».
> Я не знаю, что такое 64-битный time_t, я далёк от этого. Просто
> прочитал где-то в каких-то анонсах (или даже в пейперах было, не
> помню), что все порты будут шерстить на предмет поддержки, включая всякие
> базы данных и прочее. Вот я и подумал, что теперь будут
> ПЕРЕПАХИВАТЬ ВСЁ. :)Уже перепахали. :)
А что такое 64-битный time_t, зачем оно нужно и почему именно так, как это сделано в OpenBSD, хорошо сам Тео рассказал: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/
> полная сборка на опёнковском кластере amd64 сейчас занимает полтора дняЧто ж это за кластер-то такой -- может, им передать один Athlon64 X2 для заметного усиления группировки? :)
>> полная сборка на опёнковском кластере amd64 сейчас занимает полтора дня
> Что ж это за кластер-то такой -- может, им передать один Athlon64
> X2 для заметного усиления группировки? :)В смысле, сборка не базовой ОС с иксами. А полная сборка всех поддерживаемых пакетов. Включая LO, KDE3&4, GNOME3, TeXLive, игры и т.д. Всего, на данный момент, 22,5 гигабайт барахла для i386 и чуть больше для amd64.
Впрочем, я выразился, возможно, неверно. Сам кластер смешанный, в нём все архитектуры встречаются, но сборка при этом идёт единая - dpb такое умеет. Из этих машин те, которые amd64, вместе управляются за ~36 часов.
> В смысле, сборка не базовой ОС с иксами. А полная сборка всех поддерживаемых пакетов.Ровно так и понял. Как-то это совсем грустно, попробуйте сборку на аналоге tmpfs, если он есть (ну или на кожзаменителе из рамдиска, если нету).
Даже альт собирается заметно быстрее -- при том, что только files/x86_64/RPMS занимает 26G, а рядом ещё noarch на пару гиг больше, собирающийся из тех же src.rpm, и всё это ужато xz и прошло проверку на устанавливаемость индивидуальных бинарных пакетов в каждом задании. При этом сборочницу есть куда оптимизировать.
>> В смысле, сборка не базовой ОС с иксами. А полная сборка всех поддерживаемых пакетов.
> Ровно так и понял. Как-то это совсем грустно, попробуйте сборку на
> аналоге tmpfs, если он есть (ну или на кожзаменителе из рамдиска,
> если нету).В Опёнке на данный момент две файловые системы "в памяти", из них одна, к сожалению, не пригодна для подобной нагрузки, а вторую (tmpfs как раз) пока допиливают - вроде, основную массу багов уже выловили, может, в 5.5 уже и будет. Тестовые сборки (на других машинах) иногда уже проходят без проблем, и там действительно наблюдается огромный прирост средней скорости.
> Даже альт собирается заметно быстрее -- при том, что только files/x86_64/RPMS занимает
> 26G, а рядом ещё noarch на пару гиг больше, собирающийся из
> тех же src.rpm, и всё это ужато xz и прошло проверку
> на устанавливаемость индивидуальных бинарных пакетов в каждом задании. При этом
> сборочницу есть куда оптимизировать.Её всегда есть, куда оптимизировать. :) А "заметно быстрее" - это насколько?
> А "заметно быстрее" - это насколько?Насколько помню, в сутки сейчас укладывается (и это не полная возможная загрузка сборочницы). Уточните у ldv@, если что.
2 б.б.: речь вроде о конкретно взятом amd64, а вообще альт ещё под armh (v7hf) собирается.
> Ровно так и понял. Как-то это совсем грустно, попробуйте сборку на
> аналоге tmpfs, если он есть (ну или на кожзаменителе из рамдиска,
> если нету).
> Даже альт собирается заметно быстрее -- при том, что только files/x86_64/RPMS занимает
> 26G, а рядом ещё noarch на пару гиг больше, собирающийся из
> тех же src.rpm, и всё это ужато xz и прошло проверку
> на устанавливаемость индивидуальных бинарных пакетов в каждом задании. При этом
> сборочницу есть куда оптимизировать.В альте, по-моему, только две ахритектуры. В openbsd - с десяток.
Но мне больше нравится, что в openbsd ВСЯ базовая система на самом низком и одноядерном турионе собирается раз в 10 быстрее, чем в linux одно только ядро :)А порты - да, подолее собираются. :(
> Но мне больше нравится, что в openbsd ВСЯ базовая система на самом
> низком и одноядерном турионе собирается раз в 10 быстрее, чем в
> linux одно только ядро :)недавно пересобирал ядро. кора2дуба 3GHz, x86, 4GB RAM. шесть с половиной минут. неужели базовую систему опёнка можно собрать за 36 секунд? О-ФИ-ГЕТЬ.
или ты опять соврал?
>> Но мне больше нравится, что в openbsd ВСЯ базовая система на самом
>> низком и одноядерном турионе собирается раз в 10 быстрее, чем в
>> linux одно только ядро :)
> недавно пересобирал ядро. кора2дуба 3GHz, x86, 4GB RAM. шесть с половиной минут.
> неужели базовую систему опёнка можно собрать за 36 секунд? О-ФИ-ГЕТЬ.
> или ты опять соврал?Я никогда не вру. А в этот раз я не соврал, как никогда. :)
Я не знаю, кто такие кора дуба. Я знаю только 386, 486, p1, pmmx, p2, p3, p4 и низкие турионы. :) Впрочем, меня это и не интересует. :)
> Я никогда не вру. А в этот раз я не соврал, как
> никогда. :)— а твой пацак сказал, что целую!
— и он пошутил!
>> Я никогда не вру. А в этот раз я не соврал, как
>> никогда. :)
> — а твой пацак сказал, что целую!
> — и он пошутил!по средам не целую
> Debian-у не хватает концепции 'base system' :)Нафиг надо. Чтобы он пытался втюхивать апач на десктопник? Вот уж спасибки.
>> Debian-у не хватает концепции 'base system' :)
> Нафиг надо. Чтобы он пытался втюхивать апач на десктопник? Вот уж спасибки.Если надо, то и апач. Это лучше, чем экономить на спичках, получая с этого очевидные проблемки. :)
> Если надо, то и апач.Нет, извините, кому надо? Мне апач на десктопе - не надо. Совсем никак.
> Это лучше, чем экономить на спичках, получая
> с этого очевидные проблемки. :)Поэтому давайте вкатим все 20К пакетов из репок, чтобы никому не обидно было.
Впрочем, как минимум убунтуи метапакетов на разные случаи жизни понаделали например. Так что из одного теста лепится что минимальная система, что сервер, что десктоп "с кедами" (или без кедов). Вот это выглядит относительно разумно - не "базовая система" где 1 размер хватит всем, а вполне осмысленная распиловка на метапакеты под типовые цели и задачи. Куда более гибкий подход.
> Это я молчу про VAX, где всё вышеперечисленное умещается в тридцать метров
> оперативки. Суммарно. Потому что иначе не взлетит. В общем, чем больше я познаю
> линуксовые управлялки пакетами, тем больше нравятся все остальные...Так нам не полутора пакетами управлять приходится (это не в оправдание yum и подобному непотребству).
>> Это я молчу про VAX, где всё вышеперечисленное умещается в тридцать метров
>> оперативки. Суммарно. Потому что иначе не взлетит. В общем, чем больше я познаю
>> линуксовые управлялки пакетами, тем больше нравятся все остальные...
> Так нам не полутора пакетами управлять приходится (это не в оправдание yum
> и подобному непотребству).Не понял сути наезда. Ну или изначально непонятно я сам выразился, хотя и не пойму, где. :(
>> Так нам не полутора пакетами управлять приходится
> Не понял сути наезда.
>>> Так нам не полутора пакетами управлять приходится
>> Не понял сути наезда.
> https://bugzilla.altlinux.org/29514Ну, вопросы с версиями в openbsd решаются элегантнее, чем в apt. Тому просто пофиг, хоть тыщу версий заведи. :)
>>> Так нам не полутора пакетами управлять приходится
>> Не понял сути наезда.
> https://bugzilla.altlinux.org/29514Это называется "непродуманная архитектура". Получается, apt жрёт ресурсы пропорционально общему количеству пакетов в репозитории, а не пропорционально количеству пакетов, в данный момент обрабатываемых. Ради каких-то смутных выгод создаются гигантские кеши... Эх. :(
> моя смотрит на твоя с недоумением... т.к. у моя шаблон
> для виртуалок начинается 1Гx2cpu, даже для тестовых серверов.А теперь прикинь - я могу делать по VM на сервис например. Сервис может быть маленьким и легким - я не люблю энтерпрайзные монстрилы. А вот изоляция лишней не бывает. Ну так, на случай факапов, и вообще возможности рулить всем этим отдельно и гибко перекидывать куда-нибудь еще. Поэтому десяток-другой VM с небольшой памятью - ничему не противоречит. Половине софта 128-256Мб оперативы - выше крыши. И как-то так дебианскому пакетному манагеру этого хватает выше крыши. А гумняшка с названием yum - в два счета OOM ловит. Вот ща я уже сокращу в 3 раза число виртуалок на железяке "потому что yum гумно", ага, мечтайте. Так весь пойнт виртуализации (хорошая изоляция при плотной набивке сервака множеством независимых задач) теряется.
> Экономим на спичках?
Если у вас каждая спичка в кило весом - когда потребуется спичечный коробок, можно будет нехило поднакачаться.
> Это вообще фича которую надо использовать реже чем стопкран в самолете.И внутренние репозитории ни в коем случае в компании не использовать. Что еще реалистичного посоветуете?
> И внутренние репозитории ни в коем случае в компании не использовать.Внутренние репы никак с этим стопкраном не связаны сами по себе. Если кому зудит пониже спины всенепременно вбить этот гвоздь именно этим микроскопом и в процессе найти приключения на свой зад - это можно. Но зачем? Ручное диджейство версиями софта на уровне отдельной системы и пакетного манагера настолько против общей идеи, что пользоваться этим турбо-костылем натурально надо реже чем стоп-краном в самолете.
Это openSUSE-то "недодистр"? Нууууу.....
> Это openSUSE-то "недодистр"? Нууууу.....А федора - передистр. Потому что там все постоянно перехреначивают, до состояния отвалбашки зачастую :)
> В итоге всякие суси и прочие дистры первые возьмут заберут себе эти изменения...Да Вы шутите! Кто в здравом уме поменяет libzypp/zypper на пистонную поделку?
> Да Вы шутите! Кто в здравом уме поменяет libzypp/zypper на пистонную поделку?Разработчики суси.
Потому что сейчас, например, zypper не намного быстрее yum.
Если DNF реально быстрее - вот вам и повод.
> На что только не идут люди, лишь бы не использовать zypper (c++, если чё)...При наличии нескольких дополнительных реп zypper начинает неслабо тормозить аки yum.
Что наглядно доказывает нам: правильный выбор языка не дает 100% гарантии успеха.
> При наличии нескольких дополнительных реп zypper начинает неслабо тормозить аки yum.Толко если yum столько репок вкатить - начнется вообще сталинград.
> Что наглядно доказывает нам: правильный выбор языка не дает 100% гарантии успеха.
Зато желание схалтурить в системном инструменте который пишется на века - приветствовать ну нкиак не можно. Неприятно юзать годами кривую наколенщину знаете ли.
И да, один только yum - достаточное основание чтобы выбросить центосятину на помойку. Отвратительная мерзость.
>> При наличии нескольких дополнительных реп zypper начинает неслабо тормозить аки yum.
> Толко если yum столько репок вкатить - начнется вообще сталинград.Да-да, он будет работать так же паршиво, как zypper. Что как бы намекает нам.
> Зато желание схалтурить в системном инструменте который пишется на века - приветствовать ну нкиак не можно. Неприятно юзать годами кривую наколенщину знаете ли.
SysV init лет 30 пользовались, и не вякали. Хотя sh - еще большая халтура, чем пистон.
> И да, один только yum - достаточное основание чтобы выбросить центосятину на помойку. Отвратительная мерзость.Примерно как zypper.
> Да-да, он будет работать так же паршиво, как zypper.Думаю что во первых в разы паршивее, во вторых - сожрет терабайт памяти бонусом.
Изменения ради изменений?
> Изменения ради изменений?fxd
изменения ради изменений!
>> Изменения ради изменений?
>fxd
>изменения ради изменений!'s/fxd/fixed/'
изменения ради изменений!
Нет, вы ошиблись окошечком, это новость не про убунту.
Тем более,
>Для обычного пользователя главными достоинствами DNF является заметно более высокая скорость работы и низкое потребление памяти.
Обычный пользователь устанавливает и удаляет программы по три раза в день. Хорошо, когда программа, которая работает постоянно - оптимизируется, переписывается, меняется. Нет предела совершенству, верно ведь?!
> Обычный пользователь устанавливает и удаляет программы по три раза в день. Хорошо,
> когда программа, которая работает постоянно - оптимизируется, переписывается, меняется.
> Нет предела совершенству, верно ведь?!херня.
А тот "обычный" пользователь, которого вы описали, эти программы не устанавливает, а скорее компилирует.
помечай сарказм, а то идиоты cannot into.
> помечай сарказм, а то идиoты cannot into.Боюсь, это был не сарказм.
Ну федора не брезгует частотой обновления пакетов, вроде. У меня старые машинки дома, понравится в виртуалке — поставлю на какую-то из них, так что и производительность не лишняя.
> Обычный пользователь устанавливает и удаляет программы по три раза в день.А вот если бы оно было не так... это был бы законный повод не париться с оптимизацией пакетного менджера. Подумаешь, один пакет полдня ставится. Все равно пользователю новые пакеты надо ставить не чаще раза в месяц.
*обычному пользователю
> Обычный пользователь устанавливает и удаляет программы по три раза в день. Хорошо,
> когда программа, которая работает постоянно - оптимизируется, переписывается, меняется.
> Нет предела совершенству, верно ведь?!пришло время еще раз переустанавливать программы. программы сами не переустановяться. я переустанавливаю программы по три раза в день. я успешен и потому весь день настраиваю дистр, а потом опять переустанавливаю программы...
</sarcasm>, ну ты понел
> Обычный пользователь устанавливает и удаляет программы по три раза в день. Хорошо,
> когда программа, которая работает постоянно - оптимизируется, переписывается, меняется.
> Нет предела совершенству, верно ведь?!По три раза в день, это чтоли, чтобы утром почитать почту - установил клиента,почитал, удалил, в обед чтобы почитать почту - установил клиента,почитал, удалил, вечером то же самое?
> По три раза в день, это чтоли, чтобы утром почитать почту -
> установил клиента,почитал, удалил, в обед чтобы почитать почту - установил
> клиента,почитал, удалил, вечером то же самое?Ну есть такие люди, которые трясутся над каждым мегабайтом. Правда, они обычно на генте сидят.
Пффф, это же Fedora, расслабьтесь, это нормально :-)
скоро будем писАть:fepora/python
opensuse/ruby?
Что, получим опять пакеты RPM? Ещё один "другой" RPM отличающийся от тех RPM, которые не совместимы со старыми RPM ?
> Ещё один "другой" RPMСмеяться после слова "лопата"?
> Что, получим опять пакеты RPM? Ещё один "другой" RPM отличающийся от тех
> RPM, которые не совместимы со старыми RPM ?При чем тут формат RPM-пакетов? dnf и yum - это frontend package manager'ы, rpm - backend.
>> Что, получим опять пакеты RPM? Ещё один "другой" RPM отличающийся от тех
>> RPM, которые не совместимы со старыми RPM ?
> При чем тут формат RPM-пакетов? dnf и yum - это frontend package
> manager'ы, rpm - backend.А не с этого ли началось такое разнообразие rpm-пакетов?
Брали новый менеджер пакетов в новом дистрибутиве, допиливали функционал, часть которого шла в скрипты самого пакета rpm, и он становился несовместимым с прошлым дистрибутивом, хоть и был rpm.
Вас ввел в заблуждение заголовок новости.В современном линуксе есть 2 типа пакетных менеджеров:
a) низкоуровневые - rpm и dpkg
б) высокоуровневые - apt-get, zypper, yum и др.
Каждый дистрибутив строится на паре пакетных менеджеров (высокоуровневый+низкоуровневый). Комбинации, теоретически, могут быть разнообразными. На практике, есть apt-get/RPM, zypper/RPM, yum/RPM и apt-get/DPKG.
DNF - это высокоуровневый пакетный менеджер, аналог apt-get, zypper, yum. Теоретически, его можно сделать так, чтобы он работал с RPM и DPKG. Но на практике он будет работать лишь с RPM. От скриптов .spec файла DNF, как и другие высокоуровневые менеджеры, в первом приближении не зависит.
>[оверквотинг удален]
> a) низкоуровневые - rpm и dpkg
> б) высокоуровневые - apt-get, zypper, yum и др.
> Каждый дистрибутив строится на паре пакетных менеджеров (высокоуровневый+низкоуровневый).
> Комбинации, теоретически, могут быть разнообразными. На практике, есть apt-get/RPM, zypper/RPM,
> yum/RPM и apt-get/DPKG.
> DNF - это высокоуровневый пакетный менеджер, аналог apt-get, zypper, yum. Теоретически,
> его можно сделать так, чтобы он работал с RPM и DPKG.
> Но на практике он будет работать лишь с RPM. От скриптов
> .spec файла DNF, как и другие высокоуровневые менеджеры, в первом приближении
> не зависит.Всё отлично понятно, спасибо.
+
1) Обычно (а) называются "администраторами пакетов" (packet managers), а (б) "системами управления пакетами" (packet management system).2) К Linux это не имеет вообще никакого отношения.
1) Спасибо. Но термины не устоялись. См. к примеру http://en.opensuse.org/Portal:Zypper :
"Zypper is a command line package manager"2) Обсуждаем именно дистрибутив Линукса, поэтому, чтобы не вываливать всю бездну мудрости на неподготовленного человека, я ограничился именно Линуксом. Хотя, конечно, можно было бы рассказать и про другие системы. Именно для простоты изложения, я вычеркнул дурацкий IPS из Solaris'а, про который было написал.
frontend package manager, backend package manager... по-моему программисты слишком увлеклись
> frontend package manager, backend package manager... по-моему программисты слишком увлеклисьНе нравится - го на слаку. Там не фронтендов.
>> frontend package manager, backend package manager... по-моему программисты слишком увлеклись
> Не нравится - го на слаку. Там не фронтендов.Есть. :)
> Не нравится — го на слаку. Там не фронтендов.Знаток, чо!
откуда вы лезете?
это Свидетели Убунту
так что МаркАкбар
Я смотрю тут "Убунтовод" приобрело значение типа проклятия или оскорбления. Они вас не оценят.
> Я смотрю тут "Убунтовод" приобрело значение типа проклятия или оскорбления. Они вас
> не оценят.И не только тут и не недавно. И не надо.
> Я смотрю тут "Убунтовод" приобрело значение типа проклятия или оскорбления.Да тут почти все приобрело - на фанатов какого дистра ни глянь, полный ужас. Квалификация в районе плинтуса, а ЧСВ до небес. Особенно грешат этим одепты bsd-based и прочих гент, впрочем остальные успешно борятся за первое место Специальной Олимпиады.
>> Я смотрю тут "Убунтовод" приобрело значение типа проклятия или оскорбления.
> Да тут почти все приобрело - на фанатов какого дистра ни глянь,
> полный ужас. Квалификация в районе плинтуса, а ЧСВ до небес. Особенно
> грешат этим одепты bsd-based и прочих гент, впрочем остальные успешно борятся
> за первое место Специальной Олимпиады.Уфф. Ну наконец-то нашёлся честный и справедливый человек, который не вешает ярлыки. Ура! Вот он, спаситель! Вот он, я!
на первый взгляд dnf показался более медленным, чем yum
В моем случае dnf еще пару раз и сглючил на ровном месте (там, где yum аналогичную операцию провел на ура). После этого забросил эксперименты и вернулся к yum`у :)
> на первый взгляд dnf показался более медленным, чем yumЭто на первый взгляд. Changeset на 1000 пакетов при апгрейде он обрабатывает за пять секунд, в то время, как yum это делает часа два! Правда, он не поддерживает многие фичи yum-а, особенно, те, которые предоставляются плагинами к yum-у.
> yum это делает часа два!Хаха, а у дебианщиков я и 2000 пакетов обрабатывал их манагером. Вообще не тормозило...
>> yum это делает часа два!
> Хаха, а у дебианщиков я и 2000 пакетов обрабатывал их манагером. Вообще
> не тормозило...При чем тут дебиан, если объясняется сравнение производительности yum и dnf, который, кстати и 2000 примерно за те же 5 секунд прожевывает?
Иди лучше почини, наконец, pinning в apt-е, а то на дворе 2013 год, а приоритетами для пакетов до сих пор занимает через пень-колоду работающий код из 90-х.
да здравствует федора как испытательный стенд
> да здравствует федора как испытательный стендне знаю как кто, а я федору давно рассматриваю как дистр для бесплатных бета-тестеров redhat
> не знаю как кто, а я федору давно рассматриваю как дистр для бесплатных бета-тестеров redhatВы не поверите, но сам и RedHat федору рассматривает как дистр для бесплатных бета-тестеров.
> не знаю как кто, а я федору давно рассматриваю как дистр для
> бесплатных бета-тестеров redhatАга, а убунта - бесплатные бета-тестеры debian.
Осталось найти, чьими же бета-тестерами работают арчеводы...
> Ага, а убунта - бесплатные бета-тестеры debian.
> Осталось найти, чьими же бета-тестерами работают арчеводы...Апстрима. Ваш КО.
> Ага, а убунта - бесплатные бета-тестеры debian.Глядя на то как выглядит типичный десктоп дебианщика (как вы понимаете, stable хватает далеко не всем) - я начинаю сомневаться, кто и у кого тестерами выступает :).
>> Ага, а убунта - бесплатные бета-тестеры debian.
> Глядя на то как выглядит типичный десктоп дебианщика (как вы понимаете, stable
> хватает далеко не всем) - я начинаю сомневаться, кто и у
> кого тестерами выступает :).Показать как он у меня выглядит? Обычный XFCE из обычного Debian Stable. Пакетов из других репозиториев нет. Может я не типичный?
zypper в суське офигенен. Быстрый и удобный.yum явно хуже.
Зачем спешка в yum? Для ловли блох?
> Зачем спешка в yum? Для ловли блох?видать все баги уже исправили, теперь можно заняться внесением новых^W^W оптимизацией.
З.Ы. реквестую тег для перечёркнутого текста
> Зачем спешка в yum? Для ловли блох?Ну да, фанатикам не в облом подождать. И памяти можно докупить. И серверов новых. Для милого дружка - и сережку из ушка...
> zypper
> Быстрый/0