Linux - на помойку!

NetBSD - рулез фарева!!!

Запретить анонимам постить комментарии!

Я, кстати, ставил Debian/NetBSD x86
Вполне себе приятно, apt работает, dpkg. Только много чего другого пока не работает, зависимости поломаны, ну да это, я надеюсь, дело времени :)

NetBSD - на SPARC-e работает, в отличие от Linux.

задолбали ананимусы!

в натуре, уроды
мочить анонимоусов в сортире

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

2lenin_пиздобол у мна дебиан на ultra sparce живет еще с 2.2, и если руки не кривить, то еще ничего не вызывало проблем на этой платформе

Врет ленин, у меня Gentoo Linux c ядром 2.4.20 живет как родной на SPARC (Ultra 10) уже пол года наверно

А смысл? Пристроить старое сановское железо ? Если на нормальный PC без монитора не хватает денег - то довод.

Искать драйвера под САНовские хардверные новшевста ? А оно надо ? Зачем вообще купили САН ? Solaris очень стабильная ОС, отлично ведет себя под большими нагрузками. Если привычно использовать Solaris - то какой смысл в этих портациях? Если нет такой привычки - найдите железо по дешевле. Академический интерес и все.

А смысл?????
Салярки мало??? Маньяки-самоучки! Ж:о( )

А ведь еще где-то живет проект где народ на Z80 - Z8000 линукс прикручивает!!! Типа, на синклер :)
Осталось на звонок от детского велосипеда линукс портировать!

Linux на SPARC

А вообще, какой Linux лучше всего ставить на SPARC ? Можно ли делать двойную загрузку как на PC (чтобы можно при старте скажем с консоли выбирать Solaris/Linux)?

Мне кажется что SPARC'овские 64-битные машины всё же лучше чем Intel'овские всё ещё 32-разрядные.

>Вполне себе приятно, apt работает, dpkg. Только много чего другого пока не работает, зависимости поломаны, ну да это, я надеюсь, дело времени :)

формат пакетов deb вообще убожество
надо же додуматься ставить _это_ на нормальное ядро
лучше бы себе на линукс поставили нормальные пакеты: http://pkgsrc.org/

Круто берем любой юних портируем его с помощью ядра NetBsd и типа счастье? А теперь риторический вопрос - на...уя это нужно? Если есть Нэт, то для чего придумавать велосипед?

lenin (*) (2003-04-29 22:47:12.759064):

Не надо ля-ля! Вот что я лично на спарках использовал:

Linux 2.2.20/SPARC U64

Linux 2.2.18/SPARC IPX

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

anonymous (*) (2003-04-30 09:54:40.603003): вумный, да?! А зависимости как отслеживать? тогда уж лучше .rpm - там это на уровне :)

vada (*) (2003-04-30 09:40:29.447941)

жил. только не линух, а юникс. На ямаху MSX портировали, на этом заглохло :( до спектрума так и не добрались, к сожалению, а то еще толпой терминалов по $10 за тонну все обзавелись бы :)

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

http://www.zilog.com/products/xq/asp/Id.eZ80L92/qx/partdetails.htm

Не зная брода - не суйся в воду, зайлог - весьма перспективная контора, которая так просто своих позиций не сдаст :)

>формат пакетов deb вообще убожество
Приведите хоть один аргумент.
Похоже вы никогда с Дебианам не работали.

Порт OpenBSD/sparc объективно быстрее NetBSD/sparc, не знаю как насчет сравнения с Linux/sparc.

Linux/sparc (не путать со sparc64) недостаточно правильно работает со спарковским MMU отчего у него наблюдается некоторые тормоза на контекст свичах и тому подобной активности. Посколку это вроде как никого не напрягает, спарки (32х битные) отмирают, то и фиксить это никто пока не собирается.

А в новом RPM-е вскоре должна появиться поддержка "зависимостей", то есть в саму рпмку будут включать недостающие файлы.

2 anonymous (*) (2003-04-30 09:58:18.613098):

> Круто берем любой юних портируем его с помощью ядра NetBsd и типа счастье?
> А теперь риторический вопрос - на...уя это нужно?

Что касается GNU, то это просто еще один порт в довесок к GNU/Linux,
пока свое ядро (Hurd) не доделают.
А зачем это делать с другим *NIX'-ом -- не очень понятно.

Уязвимость в mgetty (GENTOO LINUX)

2Dselect (*) (2003-04-30 11:03:09.79502)

А зачем это делать с другим *NIX'-ом -- не очень понятно.

Портировать NetBSD kernel на новую железку можно за 3 дня,

а линух за 3 месяца.

Нет, не всегда. Зависит от того, поддерживается ли уже данный процессор или нет.

>формат пакетов deb вообще убожество

это всего навсего ar архив !

>лучше бы себе на линукс поставили нормальные пакеты: http://pkgsrc.org/

обсуждали уже в треде про слаку,
я бы не сказал что "это" вообще можно назвать
пакетом

>А в новом RPM-е вскоре должна появиться поддержка "зависимостей", то есть в саму рпмку будут включать недостающие файлы.

как в виндах чтоль??
упаси Господь нас от этого !!!

>>формат пакетов deb вообще убожество
>Приведите хоть один аргумент.

Архив в формате ar (зачем?!) в котором лежат несколько .tar.gz - типа круто?
За попытки снести мне при apt-get install некоторые пакеты надо что-нибудь отрывать (и не надо мне говорить про десять конфликтующих репозитариев, такой уж этот линукс). Иногда проще руками разложить...

>Похоже вы никогда с Дебианам не работали

Если бы.

>Архив в формате ar (зачем?!) в котором лежат несколько .tar.gz - типа круто?

не несколько, а два.

>За попытки снести мне при apt-get install некоторые пакеты

как это ты install'ом будешь сносить???
и при чём тут формат .deb ?

>надо что-нибудь отрывать

чего???

>и не надо мне говорить про десять конфликтующих репозитариев, такой уж этот линукс

репозиторий официальный всего один, а если ты ставишь
пакеты из каких-то левых мест и при этом у тебя что-то
не ставится, то это уже твои проблемы!!
ни Debian ни формат .deb тут ни при чём !!

>Иногда проще руками разложить...

сотни/тысячи пакетов ??? руками ???
да ты извращенец !!!

>Иногда проще руками разложить... 
А программировать в кодах...

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

2Dselect
Лично мне кажется что при нынешней ситуации hurd доделают до более менее рабочего состояния ещё очень и очень не скоро.

2anonymous (*) (2003-04-30 10:19:55.745263)

>А насчет такого "презрительного" отношения к z80

Кто говорил про презрение??? Это не ко мне!

>не несколько, а два.

ага, всего

>>Иногда проще руками разложить... >сотни/тысячи пакетов ??? руками ???

Кто говорил про сотни? Это вы что-то придумали...

>да ты извращенец !!!

"... и они запрещают мне ковыряться в носу" :)

>репозиторий официальный всего один, а если ты ставишь >пакеты из каких-то левых мест и при этом у тебя что-то

отказ работать без "apt-get -f install" - верх маразма, при том что debian совсем не торопится выкладывать свежие версии тох же gnome и kde даже в experimental тот же sim, обсуждаемый в соседней ветке, просто отсутствует в официальном репозитарии debian впрочем, это к кривости формата .deb и правда уже не имеет отношения, и без того про него всё понятно, сделали, как пришлось, как это обычно происходит в линуксах Greg Lehey в интервью http://osnews.com/story.php?news_id=3415&page=4 об этой разнице хорошо сказал

или я не то сказал, или меня не так поняли.

> Портировать NetBSD kernel на новую железку можно за 3 дня

Дык при чем тут это? Я имел в виду, что портировать _ВЕСЬ_ софт,
который есть, скажем, для True 64, на NetBSD -- не слишком
осмысленное занятие. В отличие от портирования всего (или, большой
части) GNU'-того софта.

Люди, мне очень надо - ответьте пожалуйста: на спарках (старых и новых, а также SunRays) Хы по дефолту какую глубину цвета имеют - 16 бит или 24 бита? Могут ли на сантехнике видеоадаптеры глубину в 24 или 32 бита поддерживать? Спасибо за ответ!

>Кто говорил про сотни? Это вы что-то придумали...

ну если у вас стоит base system + несколько дополнительных
пакетов, то проблем нет, а у меня сейчас в системе установлено
~1400 пакетов

Да, например

cgtwelve - 24-bit color, accelerated cgfourteen - 8 or 24-bit color, accelerated Fujitsu AG-10e (agten) - 24-bit color, accelerated

ну и далее по списку.

>ну если у вас стоит base system + несколько дополнительных пакетов, то проблем нет, а у меня сейчас в системе установлено ~1400 пакетов

а теперь ответьте: на сколько надо поделить эту цифру, чтоб узнать количество софтин. зачем? смотрите:

я собираю XFree86 за один присест и зависимости для всего насобранного одни. у вас тот же XFree исчисляется десятками пакетов.

также есть либы -- их у вас пакуют отдельно runtime и devel.

желающий продолжит.

---vk

>я собираю XFree86 за один присест и зависимости для всего насобранного одни. у вас тот же XFree исчисляется десятками пакетов.

правильно, нахер мне весь xfree86 ставить????
я поставлю только то что мне надо!!


>также есть либы -- их у вас пакуют отдельно runtime и devel.

это несомненный плюс !!!

> правильно, нахер мне весь xfree86 ставить???? я поставлю только то что мне надо!!

вы уходите от темы. речь шла о поддержке зависимостей для ~1400 пакетов. я же показал, что цифра искуственно раздута и спросил, во сколько раз.

---vk

да, я и не спорю, каждая прога разбита на n пакетов, где n от 1 до ...., например kdemultimedia разбит на ~15 пакетов

никаких проблем с зависимостями при этом не возникает.

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

>>также есть либы -- их у вас пакуют отдельно runtime и devel.

ещё там часто пакуют отдельно -bin

>это несомненный плюс !!!

ага, жирный такой, покосившийся :)

агументы в пользу мелкого разбиения по пакетым приведены были -
при таком разбиении не устанавливается лишее.

агруметы против мелкого разбиения по пакетым пока ещё никто не привёл !

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

опять уходите от темы. и все туда же. сколько еще нужно сообщений, чтоб вы ответили на корректно поставленный вопрос?

---vk

незнаю я во сколько раз завышена цифра количества пакетов, и мне это абсолютно пофиг

>>А в новом RPM-е вскоре должна появиться поддержка "зависимостей", то есть в саму рпмку будут включать недостающие файлы.

>как в виндах чтоль?? >упаси Господь нас от этого !!!

Недостающие файлы надо держать в голове, во встроенном чипе

тоже немного Андроид (сочувствующий)

Мальчику, который жалуется на то, что apt-get сносит пакеты.

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

1. У вас есть машина на которую утановлен exim и вы ставите sendmail. Чтобы не сломать систему вы должны снести exim и установить sendmail

2. У вас есть pkg1 от которого зависит pkg2. Например вы ставите пакет pkg3 который конфилктует с пакетом pkg1, В результате будут снесены все пакеты которые зависят от pkg1.

Так вот, начинающий линуксоид, debian это давно отлаженная и продуманная система, все зависимости там взяты не с потолка именно благодарая .deb ты можешь создавать пакеты, которые конфликтуют с другими пакетами, заменяют собой другие пакеты и т.д.

apt-get это автоматическая систему удволетворения зависимостей и не более того, но без .deb (на rpm) она работает кривовато из-за ограниченности формата rpm.

PS: Только не надо мне рассказывать, что зависимости нужно держать в голове, этот бред я даже слушать не хочу.

Интересно, а чем это RPM так ограничен ?

уже в каком-то треде упоминали про различные уровни зависимостей
в deb, чего нету в rpm.

rpm сам догадается без apt'а разрешить конфликты?

Debian Reference Manual, страница 33, пункт 2.2.8

2anonymous (*) (2003-05-04 22:15:56.241)
в deb'е есть несколько уровней зависимостей:

Depends
Saggests
Conflictes
Replaces
Provides
Все они очен активно используются в apt-get'овской базе debian'а.