Linux за българи: Форуми

За нашата малка страна, добре се справяме:
http://www.perrier.eu.org/weblog/2014/07/29#devel-countries-201407
Благодарим на тези трима юнаци, а и на всички останали.

интересно дали има подобна статистика за Slackware -- приближените до Патрик Вoлкердинг и участниците в SlackBuilds.org проекта...

интересно дали има подобна статистика за Slackware -- приближените до Патрик Вoлкердинг и участниците в SlackBuilds.org проекта...

Той там не е ли само ПАтерик  девелопера :)) ххъъхъъхъхъхъъ

гхъхъхъъ... :) само той е

за това писах приближените

гхъхъхъъ... :) само той е

за това писах приближените

Не ви разбирам неприязънта към Slackware проекта.... Всъщност това е една от първите (и от малкото) дистрибуции, която се придържа към "някакви" стандарти. И като такава е предпочитана при разработката на отговорни проекти (а не като някои други, при които нещата се скапват след apt-get update... ).
А фактът, че дори не сте отворили официалната страница и почвате да плюете, не говори добре за Вас като за "културни" индивиди.
http://www.slackware.com/about/

аз не плюя най-малкото пък по Slackware. A  David Cantrell и Chris Lumens отдавна не работят по този проект.

Цитат на: lunarvalley в Aug 09, 2014, 13:58

гхъхъхъъ... :) само той е

за това писах приближените

Не ви разбирам неприязънта към Slackware проекта.... Всъщност това е една от първите (и от малкото) дистрибуции, която се придържа към "някакви" стандарти. И като такава е предпочитана при разработката на отговорни проекти (а не като някои други, при които нещата се скапват след apt-get update... ).
А фактът, че дори не сте отворили официалната страница и почвате да плюете, не говори добре за Вас като за "културни" индивиди.
http://www.slackware.com/about/

Сега като каза неприязън се замислих какво точно чувствам относно слакваре и то е .... нищо, само ми е малко комично :))

А за Патрик ми беше истински мъчно, когато се беше разболял от нещо, от което не можеше да се оправи и искрено се надявах да е добре :)

ПС . Кой те кара да правиш апт-гет ъпдейт без да знаеш кво ще стане?

Не ви разбирам неприязънта към Slackware проекта.... Всъщност това е една от първите (и от малкото) дистрибуции, която се придържа към "някакви" стандарти. И като такава е предпочитана при разработката на отговорни проекти (а не като някои други, при които нещата се скапват след apt-get update... ).

1. Никой не се подиграва и не изпитва негативни чувства към Slackware. Просто, много хора са забравили за нея. Тези, които се сещат я споменават с добро.
Изобщо не си прочел, че постът над теб е писан от потребител на Slackware.
3. Относно - apt-get update
Тази команда само презарежда хранилищата.
Ще е малко странно, нещо да се "скапе" след нейното изпълнение.
Колкото до APT - това за мен е най- съвършеният мениджър на пакети и никой не може да ми промени мнението в това отношение.

Сега като каза неприязън се замислих какво точно чувствам относно слакваре и то е .... нищо, само ми е малко комично :))

ее, чак комично... :) дистрото си държи на принципите ;)

cyber, оправи го това Swackware, че то вече наистина изглежда комично

Споровете за дистрибуции са тъпи, въпрос на вкусове.

Това казано, имам силни предпочитания към дебиан, понеже го ползвам над 10 години и са ми ясни номерата му. Други дистрибуции ползвам само на работа или за да тествам нещо дребно как се държи там, което вече става рядко. При все това не мога да водя спорове защо точно дебиан трябва да е най-великата и добра дистрибуиция на планетата, та ползвам именно нея. Трябва ли да си оправдавам избора в крайна сметка?

Трябва ли да си оправдавам избора в крайна сметка?

ми не

Дебиан не е "някакъв", а направо е стандарт за ОС, затова най-разпространените дистра се базират именно на него.

И като такава е предпочитана при разработката на отговорни проекти (а не като някои други, при които нещата се скапват след apt-get update... ).

Някакви конкретни факти да споменеш за да не излезе, че си само един гол фен?
А това неговото е силно да се нарече и пакетен мениджър (колкото и тар множе да се нарича пакетен мениджър).

Хората уважават Слак-а по исторически причини, но вече не смогва на темпото на останалите.

Хората с години мъчат да детронират apt/dpkg, но безуспешно. Дори rpm, urpm, pacman изглеждат жалки.

yum/rpm е на практика същата история като apt*/deb нещата с тази разлика че няма 50 отделни tool-а дето вършат някаква специализирана работа и които не мога да запомня как се казват и какво точно правят. На практика не се сещам за някакво сериозно предимство на дебианската пакетна система спрямо редхатската. Дори RHEL-ските дивотии със satellite сървъра и красивите RHN-ски статистики кои какво трябвало да му се ъпдейтне правят нещата една идея по-удобни, не мисля че в дебиан има някаква аналогична постановка. Но така или иначе от това има някаква файда ако администрираш голям брой машини, аз не го правя и съответно ми е тотално ненужно.

На практика не се сещам за някакво сериозно предимство на дебианската пакетна система спрямо редхатската.

Дали има сериозно предимство - не знам. В самите пакети, според мен няма разлика.
Но, инсталирането и премахването на пакети от YUM става отчайващо бавно. Управлението на зависимостите не е на ниво. Случвало ми се е при някои програми (най- пресните ми наблюдения са ми върху blueman) , зависимостите да са удовлетворени, но тези пакети да не са достатъчно за безпроблемната работа на приложението. Липсва алтернатива на apt-get autoremove (за разлика от URPMI - urpme --auto-orphans) и трябва да се намират и трият ръчно осиротелите пакети.
За щастие, старият YUM ще бъде сменен във Fedora 22. Бъдещият пакетен мениджър се очаква да бъде доста по- бърз и ефективен.

Ъъъъм сигурен ли си? Имам силни спомени че лесно се разкарваха осиротели пакети, поне в rhel/centos. Някакъв cleanup, rpm-cleanup ли не помня точно как се казваше tool-а. Трябва да погледна.

Ами, ще съм ти благодарен да го намериш (yum --help).
Автоматично почистване на orphans с пресмятане на всички зависимости, а не изкарване на списък, след което да ги премахваш ръчно. След което да се окаже, че други пакети са осиротели.
cleanup не е еквивалент на apt-get autoremove/urpme --auto-orphans (която също не е много надеждна).
По отношение на YUM няма никаква разлика между Fedora/CENTOS. Пакетният мениджър е един и същ.

На практика не се сещам за някакво сериозно предимство на дебианската пакетна система спрямо редхатската.

* например update и upgrade/dist-upgrade са разделени. Можеш да пуснеш един apt-get update и после един милион apt-get upgrade или apt-get dist-upgrade или apt-get install ..... става светкавично. При rpm - всяка итерация ти пуска и нежелания update и ходи да ти обикаля огледалата - изчаква ти се чакалото
* apt-get update - сваля само делтите и веднъж обновени индексите, после става светкавица. Пакетите също свалят делтите (тук не съм сигурен за рпм)
* ако сложиш настройките deb http://http.debian.net/debian/  вместо разните регионални УРЛ-и, апт автоматично намира най-бързото огледало и смуче от него (това даже Убунту още не го може)
* при апт-гет първо сваля пакетите и после ги наинсталира - т.е можеш да прекъсваш и продължаваш процеса колкото си искаш - good luck with rpm, той сваля пакет и го инсталира, след това следващия.
* рпм прави хиляда паса дорде инсталира пакет(и), апт-гет сваля, после инсталира и накрая конфигурира. Прекъснат процес (дори поради диск фулл) лесно се продължава без инфекции.
* рпм винаги чисти накрая свалените пакети - аз може да не искам, може да ги ползвам пак или да преинсталирам пакета, няма да го свалям пак я.
* пакетите в Дебиан имат по-прегледни имена (нямат версии- те се пазят вътрешно), при рпм дистрата, като инсталираш пакет трябва да му укажеш цялото име барабар с версията.
* bash_completion за dpkg и apt е доведен до съвършенство - например apt-get install linux-imag<tab><tab> и ти показва всички налични ядра в хранилището. apt-get remove linux-ima<tab><tab> - показва само ядрата дето са ти инсталирани и могат да бъдат деинсталирани.
* да не говорим за dependacy hell при рпм дистрата (мисля че това идва точно заради номерата на версиите в пакетите), такива л*на не съм виждал с деб освен ако не си разбъркал репо-тата или е Дебиан сид. (За Arch pacman дори не ми се мисли - те са в средновековието там)
* няма дебиан рабита инсталация да не може да се оправи с apt/dpkg/aptitude същото не може да се каже за рпм-те (доказателство са форумите)
* не знам много за локалните репо-та при рпм, но мисля че и тук деб. са с едни гърди напред откъм фийчъри.
* апт сваля многнишково - нялколко пакета едновременно и това се вижда на екрана, това по някога ускорява работата особено ако сваляш пакети от няколко огледала (това още Убунту не го може).
* последното което се сещам, за мен например е много полезно-  е че апт говори много докато работи - какво точно става и колко точно ще отнеме време - ЕТА на доунлод, изчислява точно какъв обем точно ще бъде свален (това го може и рпм), скорости, но и точно колко ще ти заеме или освободи дисково пространство когато свърши.

Има като ти казвам бе :)

http://man7.org/linux/man-pages/man1/package-cleanup.1.html


jet, не ща да спорим за глупости, но не си прав за прилична част от списъка. Примерно инсталацията на нови пакети не е обвързана с ъпдейт, това си е конфигурационна опция в yum.conf. update ръчно също си има, с други думи не е супер сложно да накараш yum да ти работи като apt-get. Dependency hell-a е въпрос на менажиране на дистрибуцията, а редхатците си я менажират как трябва, ако си ползваш официалните хранилища, няма да имаш драми. Други неща като bash completion правила за apt...вече издребняваш :)

Всъщност обаче се сещам за едно значително предимство на дебианската пакетна система, multiarch нещата, които първоначално ми бяха доста объркани и досадни (а бяха и бъгливи в началото), но сега си работят прекрасно. Не мисля че при рпм-базираните пакетни системи има нещо подобно.


Абе я между другото гледам че сте вманиачени в тоя apt, има ли начин да накарам някой пакет да не ми излиза за autoremove? Едно време инсталирах gnuradio, който влачи ужасно много C++ библиотеки като зависимости, доста такива свързани с boost. Оказа се че е крив, защото това което пакетират не е билднато с подръжка на някои неща и трябваше да го билдвам от сорс. Естествено библиотеките от които зависи трябваше да си останат, но сега ми ги вади като ненужни и ми бълва един дълъг списък с ненужни неща, повечето от които са нужни. Къде да ходя да му кажа на тва че всъщност ми трябват?

Има като ти казвам бе :)
http://man7.org/linux/man-pages/man1/package-cleanup.1.html

Ползвал съм приложението преди няколко години и имам спомени, че изобщо не работеше като apt-get autoremove.
Утре ще го инсталирам и ще го тествам, че сега съм си пуснал филм.

jet, не ща да спорим за глупости, но не си прав за прилична част от списъка. Примерно инсталацията на нови пакети не е обвързана с ъпдейт, това си е конфигурационна опция в yum.conf. update ръчно също си има, с други думи не е супер сложно да накараш yum да ти работи като apt-get. Dependency hell-a е въпрос на менажиране на дистрибуцията, а редхатците си я менажират как трябва, ако си ползваш официалните хранилища, няма да имаш драми. Други неща като bash completion правила за apt...вече издребняваш :)

Всъщност обаче се сещам за едно значително предимство на дебианската пакетна система, multiarch нещата, които първоначално ми бяха доста объркани и досадни (а бяха и бъгливи в началото), но сега си работят прекрасно. Не мисля че при рпм-базираните пакетни системи има нещо подобно.


Абе я между другото гледам че сте вманиачени в тоя apt, има ли начин да накарам някой пакет да не ми излиза за autoremove? Едно време инсталирах gnuradio, който влачи ужасно много C++ библиотеки като зависимости, доста такива свързани с boost. Оказа се че е крив, защото това което пакетират не е билднато с подръжка на някои неща и трябваше да го билдвам от сорс. Естествено библиотеките от които зависи трябваше да си останат, но сега ми ги вади като ненужни и ми бълва един дълъг списък с ненужни неща, повечето от които са нужни. Къде да ходя да му кажа на тва че всъщност ми трябват?
[/quote]

GeSHi (Bash):
echo package_name hold | dpkg --set-selections

Други неща като bash completion правила за apt...вече издребняваш :)

добре де, ти на всички пакети знаеш ли им имената. Имаш една гола конзола на сървър и искаш да инсталираш например Sauerbraten  Server пакета - аз това име не мога да го запомня - пишеш apt-get in<tab><tab> sau<tab><tab> и то излиза. Освен ако не ходиш да търсиш графичен инсталатор и да се откачиш от кликане. Като свикнеш на благини и седнеш на машина дето ги няма и си като сакат кон

Абе я между другото гледам че сте вманиачени в тоя apt, има ли начин да накарам някой пакет да не ми излиза за autoremove? Едно време инсталирах gnuradio, който влачи ужасно много C++ библиотеки като зависимости, доста такива свързани с boost. Оказа се че е крив, защото това което пакетират не е билднато с подръжка на някои неща и трябваше да го билдвам от сорс. Естествено библиотеките от които зависи трябваше да си останат, но сега ми ги вади като ненужни и ми бълва един дълъг списък с ненужни неща, повечето от които са нужни. Къде да ходя да му кажа на тва че всъщност ми трябват?

gat3way точка 6.2.7 ->> http://debian-handbook.info/browse/wheezy/sect.apt-get.html

Код

GeSHi (Bash):
echo package_name hold | dpkg --set-selections

Това не се ли ползваше за задържане (заключване) на версията на пакет който не искаш да се ъпдейтва?

Мерси, ще хвърля едно око, че много ме дразни в последно време и все се каня да направя нещо по въпроса ама все забравям за това като приключа работата с apt.

Що се отнася до autocompletion-a аз съм дърт вече, едно време тия благинки не бяха толкова развити, а и гъз знае две и двеста -  доста вземане-даване съм си имал с машинки с различни шелове, та честно казано на практика го ползвам само да ми допълва имена на файлове и директории. Наистина нямах идея че може и с имена на пакети да го прави, обикновено го правя с wildcards и гледам какво вади. Между другото ми е интересно как точно го прави тоя номер, трябва да хвърля едно око на правилата.