> Вот тебе юзерфрендлевый фаервалл не?

Нет, уж лучше firestarter.

> Один

Вот такие там инструкции для убунты:

To run Tonido.sh:

cd /usr/local/tonido

./tonido.sh start

Не обратил внимание на 64-битную, что они там предлагают, но ссылка на деб есть

А что до Асус, то это я только сейчас нашёл случайно в поисках Tonido.

Видел я HP с предустановленным SLED. Это пи..ц, товарищи. Ничего не настроено, вайфай и управление питанием не работают. Свежеустановленная опенсусе той же версии намного лучше себя вела. Сомневаюсь, что эти новые ноутбуки хоть кто-то будет доводить до ума.

>А на дебиане все зависимости прописываются вручную

Откуда инфа? Сэр, видимо, никогда ничего под деби толком и не упаковывал. Есть же Depends: ${shlibs:Depends}, ${misc:Depends}

> Видел я HP с предустановленным SLED. Это пи..ц, товарищи.

Зато на кликпаде лампочка при отключении загорается:)

Это макросы в которые входит заранее определенный список пакетов, а не автоматические зависимости.

Автоматические зависимости вот:

$ rpm -qR racket-core
lib64racket = 1:5.1.3
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
bash
coreutils
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libdl.so.2()(64bit)
libffi.so.5()(64bit)
libm.so.6()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libracket3m-5.1.3.so()(64bit)
rtld(GNU_HASH)
python(abi)
rpmlib(PayloadIsLzma) <= 4.4.6-1

Руками в spec файле прописан только libracket.

> Не обратил внимание на 64-битную, что они там предлагают, но ссылка на деб есть

И на rpm есть: http://tonido.com/download.php?tonido-0.7.0.11017-1.i386.rpm

И инструкция: http://www.tonido.com/support/OpenSuseInstallation

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

Что показательно, rpm'ка названа по всем канонам, а deb как непойми какая хрень без версии. Я бы побоялся такую deb'ку ставить.

Зато на кликпаде лампочка при отключении загорается:)

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

Очевидно, что прямое подключение к принтеру по tcp, порт 9100. Какой это протокол - х.з.

http://ru.wikipedia.org/wiki/JetDirect

Да и в венде поиск сетевых принтеров отлично работает без всяких самб.

Бугага. Каждый раз мне приходилось руками адрес принтера вбивать. Капс же сам все быстро находил.

И снова злюКО, толкатель "лицушной" убунты за лавэ

Ты лучше поведай, какое количество шекельей надбавилось за предустановленную убунту к стоимости ноута, продавец (воздуха) лицензий на линь, ёмана xD

Снес я SLED с HP-ProBook-4320s, но лампочка запомнилась!

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

А то, что в дебиане есть тулза, которая смотрит с чем слинкован бинарник и генерит этот макрос?

Причем, автоматические зависимости генерируются даже если сконвертировать пакет в rpm из deb или даже просто бинарного тарболла. То есть, если есть zip-архив с бинарниками, alien из него сделает валидную rpm-ку, взяв имена нужных библиотек прямо из симводлов внутри бинарных файллов. При установке такой пакет подтянет все нужное из репозитория или сообщит, чего не хватает в репе.

А если конвертировать rpm->deb, то получается пкет вообще без каких-либо зависимостей. То есть, по-сути, кривой пакет. После установки котрого программа может не запуститься или крэшануться в любой момент при использовании.

в том то и дело, что в дебиане такого нет

This program is merely a wrapper around dpkg-shlibdeps(1) that calls it once for each package listed in the control file, passing it a list of ELF executables and shared libraries it has found

А по описанию совсем другое выходит. Что она парсит таки и высчитывает все, что надо.

> Есть же Depends: ${shlibs:Depends}, ${misc:Depends}

Все равно в зависимости попадают только имена пакетов. А соответствие библиотек именам пакетов может меняться от системы к системе и от релиза к релизу. Соответственно, если из пакета выкинули какую-то либу или поменяли ее so-name, то пакет просто не будет работать.

Знаем мы такие ноуты. Хоть на ней и стоит бубунта, стоимость винды которую вам не продали, все равно входит в цену.

Так, и где её результаты работы? Да и как оно вообще может работать, если в deb нет файловых зависимостей.

Слава Космонавтам!

Этот топик живое доказательство, что ЛОР готов к срачу выходу 11.10

>Так, и где её результаты работы?

Ну результаты как бы есть. Я могу сделать программу, слинковать её с чем мне надо, а потом при сборке пакета дебхэлпер выловит то, с чем слинковано и это будет в зависимостях.

Все равно в зависимости попадают только имена пакетов.

Это да, неудобно. Приходится пересобирать пакет, чтобы не было «сломанного» пакета.

> Приходится пересобирать пакет, чтобы не было «сломанного» пакета.

Ну вот о чем и речь.

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

> Да и как оно вообще может работать, если в deb нет файловых зависимостей.

Оно ищет соответствие между либами и именами пакетов по базе данных в момент сборки, как я понимаю. Соответственно, зависимости получаются правильными только для данной системы/релиза. А уже в следующем релизе соответствие может поменяться и паекет «поломается» хотя пользователь об этом может узнать когда будет уже поздно - программа просто вылетит по сегфолту в самый неподходящий момент.

дополучит, в стоимость компа с бубунтой входит лицензия винды.

заметила когда относительно недавно собирала custom ноут у НР

>обновлению вообще всего.

Это как бы необходимая жертва. Хотя rpm в этом удобней.

программа просто вылетит по сегфолту

Обычно пакет просто будет удален, т.к. не будут разрулены зависимости.

Рядовые потребители, они же безмозглое детям подобное быдло, хочет не программы и возможности, оно хочет ВИНДОУЗ! Поэтому абсолютно бесполезно объяснять, что умеет GIMP или уж тем паче Blender со Scribus'ом, людям всё, что нужно - это не дай Бог ничего не менять и не привыкать к новому, чтобы не шевелить мозгами. Даже если там и шевелить не нужно - они не станут пользоваться Убунту из страха, что шевелить таки придётся.

> Это как бы необходимая жертва. Хотя rpm в этом удобней.

rpm вообще не интересует версия пакета с либами: ты линкуешь свою программу с некоей библиотекой, и потом можешь установить хоть самый древнбючий пакет с либой - если там есть такая библиотека, то твоя прога не будет ругаться на зависимости. Аналогично ты можешь поставить пакет от новой системы на старую - если там есть нужные либы, то пакет будет работать.

В deb же как правило просто пишут зависимость на либу >= (та версия, которая была в момент сборки). Ну и соответственно, ты новый пакет на старую систему никак не поставишь.

Обычно пакет просто будет удален, т.к. не будут разрулены зависимости.

Зависимости-то по именам пакетов, если поменяется соответствие содержание файлов библиотек в пакете с либами, твой пакет от старой системы не будет знать, так как это соответствие проверяется только один раз и на всегда в момент сборки пакета и справедливо только для той системы, на которой пакет собирался.

> Вот это реальная претензия к Ubuntu - даже LTS редко выдерживала с её гномом аптайм в несколько месяцев

Перезагружаю ubuntu только после обновления ядра, ЧЯДНТ?

В пакете есть соответсвующие симлинки обычно. Так что пакет большей версии обычно удовлетворяет нужные зависимости. А вообще, подход rpm неоднозначен. Установив древнбчую версию можно схватить рандомные баги из-за изменения ABI/API. Поэтому мне кажется, что deb не лишен в этом смысле логики.

> Установив древнбчую версию можно схватить рандомные баги из-за изменения ABI/API.

Тогда поменяется soname и файл будет иметь другое имя.

Это, увы, не всегда так. Ярчайший пример тому переход с libc на eglibc. Программа скомпилированная с libc имела пару рандомных глюков при замене libc на eglibc. Warnings не было при компиляции. А eglibc заявлена как совместимая по ABI и API

> Поэтому мне кажется, что deb не лишен в этом смысле логики.

Тем, что запрещает динамически линковать бинарник с либами более старой версии, чем в момент сборки? Ну так с более новой версией же не запрещает. А API может поменяться в более новой версии точно также как и в более старой.

>Тем, что запрещает динамически линковать

Мимо. В зависимости может быть указано просто имя пакета.

Кстати аналогично. Две недели аптайма запросто выдерживает. Правда у меня не гном, а XFCE.

Поэтому для libc идет еще отдельно версия:

libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)

Here you go...

http://support.microsoft.com/kb/247804/ru

> Программа скомпилированная с libc имела пару рандомных глюков при замене libc на eglibc. Warnings не было при компиляции. А eglibc заявлена как совместимая по ABI и API

Ну значит, это баг в библиотеке, если была заявлена совместимость и был тот же soname а по факту были различия. А в случае, если бы бага не было, все было бы нормально. А в случае Дебиана он бы просто не позволил бы использовать пакет с другим именем, и тебе бы вообще не удалось заменить одну библиотеку другой, аналогичной, даже при 100% совместимости, не ломая зависимости.

> Мимо. В зависимости может быть указано просто имя пакета.

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

>А в случае Дебиана

Так это пример с дебиана. Прям вот, из первых рук

Скорее баг в софте, который был завязан на какое-нибудь пересечение участков в памяти в memcpy, а его сломали в соответствии с документацией. API и ABI не поменялось, а программа стала глючить. Перекомпиляция тут 100% будет бессильна.

Значит, там имя пакета не изменилось, но из-за того, что было прописано «libc >= ...» без учета, что более новые пакеты не всегда совместимы с более старыми, и возникла проблема. Как это решается в случае rpm смотри выше пост reset.

>Перекомпиляция тут 100% будет бессильна.

Она, как раз, помогла.

Выглядит странно. Такого не бывает. Скорее всего дело в чем-то другом что ты умалчиваешь.

>У меня у ноутбуков аптайм по 60 дней и больше. Правда, я их особо далеко не таскаю.

А нафига ноутбукам такой аптайм? Или имеется ввиду «ждущий режим»?

>Выглядит странно. Такого не бывает.

Знаешь, я тоже не верил, пока не столкнулся. У проги 3 зависимости - zlib, liblua и libc. Смена liblua и zlib к такому не приводила.