1.4, Buy (?), 22:55, 26/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>закончится так же, как и grub2
А чем закончился grub2?
| |
|
|
3.9, аноним (?), 00:18, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
странно, как же это я с ним два года живу уже, да и вон в убунте он по умолчанию будет.
| |
|
|
1.6, Аноним (6), 23:21, 26/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Идея неплохая. Только займет это у дебианщиков годы. И правильно. В процессе можно будет на кошк^W убунтоводах потренироваться.
| |
1.7, аноним (?), 23:45, 26/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Хорошо, что кто-то еще нативный софт пишет, а не дерьмо на интерпретируемых языках. Нет, я против них ничего не имею, но никак не для низкоуровневых вещей. Хотя vala тот еще костыль, лучше бы на C++.
| |
|
2.24, Аноним (-), 09:55, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Посмотрите в Gentoo. Система по сути базируется на Python, который входит в небольшой список базовых пакетов system. Теперь посмотрите что вам предлагают установить тут. Glib! А теперь посмотрите на встраиваемые решения и убедитесь, что поддержка Python у многих из коробки, тогда как GTK никто даже и не пробовал для них скомпилить.
Тем не менее я за (хоть и не использую deb-дистрибутив). Vala требует обкатки прежде чем кто-то на нём станет писать. APT как раз подойдёт для экспериментов :)
| |
|
3.27, ixrws (ok), 10:27, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Glib != gtk, это так, для начала.
Также gentoo из-за не самой лучшей реализации на питоне - довольно медлительно ворочается. Элементарный emerge --search должен работать мгновенно, но занимает секунды. Тут конечно виноват не только питон.
Ну и конечно питон ни чем не легче glib, а для дистрибов типо debian, gentoo и тд - без разницы что пихать в базу, питон ли, glib ли. Главное чтобы результат был хороший. Пожелаем им успехов.
| |
|
|
|
6.42, ixrws (ok), 14:19, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Господа, я понимю что юзать. Речь шла как бы именно о родных утилитах дженты. Именно они на питоне. Хотя ещё раз повторюсь там тормоза не только из-за питона.
Но причин писать системные утилиты на питоне я не вижу, ни одной.
| |
|
7.43, anonymous (??), 14:31, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Но причин писать системные утилиты на питоне я не вижу, ни одной.
а на чём? на си, что ли? вообще-то у никсов есть давняя традиция писать всякие подобные вещи как раз на скриптах. а на си — только какие-то совсем уж time critical вещи.
зыж но бидон я не люблю, да. потому генту и не ставил.
| |
|
|
|
|
3.39, User294 (ok), 13:30, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А теперь посмотрите на встраиваемые решения и убедитесь, что
>поддержка Python у многих из коробки,
Смотрю. Например Nokia n800 (хоть и не то чтобы встраиваемое, но ограниченное в ресурсах решение). Apt вижу. И даже GTK из коробки есть. Но питон надо доустанавливать, если он нужен. Или вот мой WL500GP. Там вообще манагер пакетов облегченный opkg :P. И упаси меня боже на такой железке запускать питон - он половину оперативки только под свой долбаный интерпретер сожрет. Не говоря уж о том что yum писаный на оном yum стушевался на виртуалке с 128 мег оперативы. Что же будет если байду на питоне запустить на встраиваемом решении - роутере, у которого на все 32 мега из коих половина уже забита сетевыми сервисами?! Я вообще не смогу заинсталировать ни 1 пакета по причине окончания памяти до того как пакеты установятся? oO К слову, питона там тоже нет. По дефолту - точно. Можно ли поставить - а хрен знает - нафиг мне питон на железке с 32 мег памяти?
| |
|
2.38, User294 (ok), 13:26, 27/08/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Нет, я против них ничего не имею, но никак не для низкоуровневых вещей.
Однозначно! Знаете как удивились чуваки которые yum-ом попытались на виртуалку поставить обыкновенный такое PHP? Этому говну на питоне... 128Mb памяти - НЕ ХВАТИЛО. В системе где кроме оного почти ничего не работало (ssh и еще пара не слишком жирных демонов). Охренеть.
| |
2.45, ximaera (?), 20:35, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Хорошо, что кто-то еще нативный софт пишет, а не дерьмо на интерпретируемых
>языках. Нет, я против них ничего не имею, но никак не
>для низкоуровневых вещей. Хотя vala тот еще костыль, лучше бы на
>C++. | |
|
|
2.14, anonymous (??), 00:56, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
> в apt не хватает проверки скаченного с md5 и torrent
Давайте скажем проще — Metalink ему не хватает. Качает-то все равно не apt.
Алсо, подписи и контрольным суммы пакетов проверяются. Или я чего-то не понимаю?
| |
|
3.63, Ano (?), 00:55, 29/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> в apt не хватает проверки скаченного с md5 и torrent
>
>Давайте скажем проще — Metalink ему не хватает. Качает-то все равно не
>apt.
>
>Алсо, подписи и контрольным суммы пакетов проверяются. Или я чего-то не понимаю?
>
я не в курсе что там проверяется, но пакеты частенько скачиваются битые
| |
|
2.18, Аноним (-), 04:34, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
> в apt не хватает проверки скаченного с md5 и torrent
apt-transport-debtorrent:
Description: an APT transport for communicating with DebTorrent
This package contains the APT debtorrent transport. It makes it possible to
use 'deb debtorrent://localhost:9988/foo distro main' type lines in your
sources.list file.
не оно ?
| |
|
3.64, Ano (?), 00:57, 29/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> в apt не хватает проверки скаченного с md5 и torrent
>
>apt-transport-debtorrent:
>Description: an APT transport for communicating with DebTorrent
> This package contains the APT debtorrent transport. It makes it possible
>to
> use 'deb debtorrent://localhost:9988/foo distro main' type lines in your
> sources.list file.
>
>не оно ?
а вот за это огромное спасибо!!!
| |
|
|
1.13, anonymous (??), 00:55, 27/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> Иными словами APT2 отличается от APT своей ориентацией на библиотечную подсистему, в то время как APT сосредоточен вокруг конечных приложений.
Что-что? APT вообще не различает приложения и библиотеки дальше понятия категорий, на которое все инструменты его уровня плевать хотели и оно больше информативное, для aptitude/synaptic/...
| |
|
2.22, koblin (ok), 09:47, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
речь о том, что apt2 - будет набор библиотек для работы с пакетами, тогда как apt - это набор конечных приложений...
| |
|
1.21, mike lee (?), 09:34, 27/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
гы... дебиянщеки устали от старых костылей и решили сделать новые. видать aptitude тоже неудачной попыткой переписать apt оказалась
| |
|
2.25, webbeans (?), 09:57, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>видать aptitude тоже неудачной попыткой переписать apt оказалась
не путайте userland с core.
| |
|
1.26, Аноним (-), 09:58, 27/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
mike lee похоже управляет своими пакетами руками, потому что в его слаке ничего нету. Пакетная система debian'a одна из самых совершенных.
| |
|
2.30, mike lee (?), 12:42, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>mike lee похоже управляет своими пакетами руками, потому что в его слаке
>ничего нету. Пакетная система debian'a одна из самых совершенных.
кроме слаки и дебиан бэйзед (и прочего rpm как с apt-rpm так и без оного) в мире есть еще много интересного. имхо portage куда как более совершенен.
| |
2.52, аноним (?), 22:39, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Пакетная система debian'a одна из самых совершенных.
С ублюдскими suggests/recommends и тормозами? Очень сомневаюсь. А "самой" совершенной _бинарная_ система пакетов быть в принципе не может.
| |
|
3.55, User294 (ok), 01:17, 28/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>С ублюдскими suggests/recommends
А что в них ублюдского? oO
> и тормозами?
Это говорит поклонник source based систем?! Знаете, дебианский пакетный манагер вкатит пакет быстрее чем он у вас перекомпилируется на том же железе. Как ни крути. И побыстрее ряда других пакетных систем.
>А "самой" совершенной _бинарная_ система пакетов быть в принципе не может.
А по-моему у дебианщиков очень даже грамотно - если за каким-то хреном надо перекомпилить некий пакет (скажем, параметры другие задать) - так это у дебианщиков просто и автоматизированно, блин. Вот только в отличие от source based это не "с ножом к горлу" а "по желанию". Что в случаях когда время важнее эстетства - очень ценно.
| |
|
4.65, Аноним (-), 06:34, 29/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Это говорит поклонник source based систем?! Знаете, дебианский пакетный манагер вкатит пакет быстрее чем он у вас перекомпилируется на том же железе.
Да вот нет. Пакет, который не надо собирать FreeBSD установит моментально, пока ваш apt будет читать базу да какие-то там hook'и выполнять. На перловых модулях очень заметно.
| |
|
|
|
1.28, Аноним (-), 10:53, 27/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Только что в какой-то из соседних веток о 0install писали...
Вот вот, я тоже это читал. Может я что-то не понимаю (да, APT и .deb лучшее что сейчас есть), но все таки недостатки есть. И только 0install-подобная система управления пакетами позволит уйти навсегда от ограничений, типа одновременной установки одной версии библиотеки с модификациями, блокирования обновлений, затрудненная установка сторонних пакетов, дистрозависимость, трудность переноса программы с компьютера на компьютер и т.д.
| |
|
2.36, Aleksey (??), 13:17, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Устанавливать для каждой программы необходимые ей библиотеки как минимум не экономно с точки зрения распределения пространства жесткого диска. Кроме того одинаковые динамические библиотеки, находящиеся в разных местах - это разные библиотеки, что с точки зрения памяти тоже не айс.
| |
|
3.40, Michael (??), 13:57, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Можно запустить демона, коооорый будет проверять запрошенные библиотеки на одинаковость и держать по копии для каждой. Конечно, это будет уже не совсем 0install, но вполне реализуемо и уже реализовано в Nix.. Вопрос в том, стоит ли отсутствие понятия конфликта пакетов (я могу поставить А и я могу поставить Б => я могу поставить А и Б) и возможность быстрого отката изменений недостатков - то есть необходимости обновить всё зависящее от библиотеки при её изменении. Лично для меня ответ - стоит.
| |
|
4.41, anonymous (??), 14:03, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Можно запустить демона, коооорый будет проверять запрошенные библиотеки на одинаковость и держать по копии для каждой.
можно и ещё кучу методов придумать. например, общее хранилище библиотек и проверка md5/sha при установке. совпали? симлинк. не совпали? кладём файл. нет вообще? в хранилище и симлинк. вот и демона не надо, например.
| |
|
5.44, Aleksey (??), 17:09, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
О, т.е. теперь еще и установка будет не быстрой. А потом обновляем пакет на который ссылаются все симлинкующиеся и получаем ту же ситуацию, что и в данный момент, когда обновляется все. А если нет разницы, то зачем качать больше?
| |
|
6.50, anonymous (??), 21:15, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>О, т.е. теперь еще и установка будет не быстрой. А потом обновляем
>пакет на который ссылаются все симлинкующиеся и получаем ту же ситуацию,
>что и в данный момент, когда обновляется все. А если нет
>разницы, то зачем качать больше?
какой «пакет», дарагой? съешь таблеточку, успокойся, может, у тебя подумать выйдет. *кто* позволит перезаписывать библиотеку в хранилище, а? ну, обновил ты софтину. ну, приволокла она новую библиотеку. ура — новая либа welcome в хранилище либ. старая — ВНИЗАПНА! — никуда не делась. теперь покажи, как тут что-то сломается, а?
поскольку твой умственный уровень у меня вызывает определённые сомнения (в смысле — наличие оного), то я поясню: хэши библиотек тоже можно хранить на винте, а не считать каждый раз. и в пакете хранить. где тут тормоза, а? спросить у центральной базы «дорогая, а есть ли у тебя библиотека вот с таким вот хэшем?» ну, если у тебя и ТАКОЕ тормозит — то выкинь свой MK-62.
да, для альтернативно одарённых: библиотеку из хранилища можно выкидывать, когда снесены все ссылающиеся пакеты. а можно и не выкидывать. а для девелоперов можно предусмотреть дополнительные опции — типа «сканировать весь диск на предмет линков» (благо, locate и так базу строит, дело недолгое).
уловил?
| |
|
7.53, Alexey (??), 22:45, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
А блокнот зависимый от kdelibs будет в пакете содержать весь kde?
| |
7.58, Michael (??), 09:10, 28/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>да, для альтернативно одарённых: библиотеку из хранилища можно выкидывать, когда снесены все
>ссылающиеся пакеты. а можно и не выкидывать. а для девелоперов можно
>предусмотреть дополнительные опции — типа «сканировать весь диск на предмет линков»
>(благо, locate и так базу строит, дело недолгое).
Сканировать не надо, зачем. Есть просто сообщение для базы "я использую это пакет и положил ссылку сюда". Проверить достаточно зарегистрированные места со ссылками.
| |
|
|
5.57, Michael (??), 09:08, 28/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Демон нужен. С ним пользователи должны верить только root (и тем, кого root публично добавил в список доверия). То есть если пользователь хочет "пакет, собранный вот так" - он его получит. Возможно с бинарного репозитория, добавленного root. Если другой пользователь хочет тот же пакет - он получит ссылку на установленную копию. Если пользователь хочет пакет с тонной вирусов - он его тоже получит для личного пользования, но не сможет подложить его другому пользователю как хороший. Для этого и нужен демон - права записи в хранилище только у него.
| |
|
|
|
2.37, Аноним (-), 13:18, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
вместо того чтобы обновить одну либу libpng например Вы предлагаете обновлять все пакеты её использующие ? гениально ! :)
| |
2.54, аноним (?), 22:49, 27/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
От этого позволяет уйти source-based система, а для бинарных пакетов вы только и будете что городить костыли, демоны, да симлинки. Я на FreeBSD десктопе сижу года 4 с 3000+ установленными пакетами последних версий - и НИКОГДА не встречал проблем с обновлением. Почему в Linux нельзя также?
| |
|
3.61, AlexanderYT (?), 10:55, 28/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Потому что все программы раздроблены на мелкие пакеты (особенно это касается deb дистрибутивов). Наверное, такой подход очень экономит место на современных бездонных дисках, чем-то упрощает жизнь девелоперам, но вот поэтому-то и нельзя. Что бы обновить какую-нибудь перделку-сопелку, то может потребоваться перевести stable всего дистрибутива в состояние testing+stable. А если мантейнер пакета возмет и build-depends "причешет, лишь бы стработало" под ветку testing, то с такими зависимости на stable может вообще все плохо кончится.
| |
|
4.66, Аноним (-), 06:39, 29/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>дистрибутива в состояние testing+stable. А если мантейнер пакета возмет и build-depends
>"причешет, лишь бы стработало" под ветку testing, то с такими зависимости
>на stable может вообще все плохо кончится.
Ужас, как дебиланщики живут. На source based нет никаких stable/unstable/testing, а все гораздо стабильнее, удобнее и при этом новее.
| |
|
|
|
1.34, АП (?), 13:16, 27/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Vala (похожий на шарп) с GLib, да ещё и развиваемый GNOME... Ужас.
Как бы не оказался очередной микрософтовский мигрант, который не смог разобраться с APT и потому решил написать свой.
Пугающая тенденция. Очень хочется ошибаться и верить, что на самом деле всё наоборот и это просто я не разобрался...
| |
|