slackware живо ли?

Bash тоже не все сразу знают.

Да, но unix-shell - это основа работы в командной строке (и если не писать сложных скриптов, то достаточно выучить основы любой shell и легко переходить с одной на другую). И, опять же, для массового переименования файлов мне не надо создавать и сохранять, а потом запускать отдельный скрипт.

А в целом винда - это просто базовая ОС + DE.

Об этом и речь. Как была когда-то графической надстройкой над DOS, так по сути тем же много лет и оставалась. Да, надёжность повышалась, на смену псевдо-многозадачности пришла истинная многозадачность, но в плане управления во многом оставалась просто графической оболочкой, т. к. развивался только графический интерфейс рабочего стола.

если бы не постоянные zero day в ядре, браузерах, сетевых службах. Так что с роллингом как-то спокойнее

Как раз уязвимости в Debian закрываются очень оперативно. А вот другие баги, не связанные с безопасностью, действительно могут оставаться вплоть до выхода новой стабильной версии. Но эта особенность тоже связана с повышением надёжности и безопасности, т. к. исправляя один баг, легко добавить другой. И если первый был связан с какой-то мелочью, а второй открывает огромную чёрную дыру, то вряд ли это можно считать улучшением. Отсюда и такая политика: все уязвимости исправляем как можно быстрее, остальное тщательно тестируем и обновляем только в следующем стабильном выпуске. Поэтому в плане 0day - Debian как раз одна из самых безопасных систем.

Да, но unix-shell - это основа работы в командной строке

В юниксах. В винде, говорят, теперь мощный PowerShell.

Вот как там теперь, по ходу, переименовываются файлы из командной строки: https://devblogs.microsoft.com/scripting/use-powershell-to-rename-files-in-bulk/
А вот так можно переименовать файлы из GUI: https://www.windowscentral.com/how-rename-multiple-files-bulk-windows-10

Как была когда-то графической надстройкой над DOS, так по сути тем же много лет и оставалась.

Смотря что чем называть. В MS DOS'е, например, у каждой софтины были свои драйвера. Win 9x/NT резко скакнули вперёд предоставив возможность не писать свои драйвера для всего зоопарка железа как это было в MS DOS'е.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166

В винде, говорят, теперь мощный PowerShell.

Теперь - да.

А вот так можно переименовать файлы из GUI: https://www.windowscentral.com/how-rename-multiple-files-bulk-windows-10

Что доказывает ущербность gui для любых мало-мальски нетривиальных задач.

Win 9x/NT резко скакнули вперёд предоставив возможность не писать свои драйвера для всего зоопарка железа как это было в MS DOS’е.

Разумеется. Там ещё много всего было. И новые ядра (в NT 3 даже частично микро-ядро, но потом от этого ушли), и частичная поддержка posix в NT 4, от которой потом тоже отказались, и много другого. Разумеется, я немного утрирую.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166

Т. е. удалось найти серьёзную уязвимость, специфичную исключительно для debian, только на конец 2006 – начало 2007 года? Это как раз доказывает моё утверждение об относительной безопасности Debian. А абсолютно безопасных систем не бывает по определению. В любом другом дистре или оси тоже можно найти специфические для них уязвимости. И, думаю, в большинстве дистров их будет больше, чем в Debian.

Шта? Какие суррогаты не молоко?

Всякие безлактозные подделки, это ж очевидно :)

Руками, в смысле? Сторонние? Я думал там у вас всё для этого есть. Так ещё и это отдельно? :)

Куплю новый комп из принципа попробую накатить слаку :)

Если молоко делается из молока, какие же это суррогаты? Так, порченное.

У Дебиана релиз-цикл предсказуемый и понятный. Фиксы безопасности выходят оперативно. Хорошая система для сервера. Не смотря на мою личную неприязнь к формату deb.

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

За счёт общей просты конструкции и удобной установки софта из AUR, хорошая система для домашнего компьютера.

Слака обоим вариантам проигрывает по разным критериям.

Парочку слакбилдов надо было-таки вытянуть, чтобы TeXLive был полным.

Все это маркетинговые разговоры в пользу бедных, это не молоко, а «молочный продукт» :)

Походу, молоко, с добавкой лактазы, витамина А и Д3. Лактаза переваривает лактозу или как-то так.

Lactase is an enzyme produced by many organisms. It is located in the brush border of the small intestine of humans and other mammals. Lactase is essential to the complete digestion of whole milk; it breaks down lactose, a sugar which gives milk its sweetness.

Если лактозу просто расщеплять, то молоко будет слишком сладкое. Так что вероятно отфильтровывают сахара к хренам, и остаётся жирненькая белковая фигня. Очень надо такое пить? Кстати, организм правильно делает, что сблевывает ненужно. Вы же не дитё уже.

Очень надо такое пить?

Дык, кальций и вкус молока от туда никто не удалял :3

Касательно дебиана и арча полностью согласен. Единственно, непонятно, чем не нравится единый для всех и неизменный уже около 2 десятилетий формат deb? Неужели зоопарк несовместимых между собой форматов под общим названием rpm лучше?

Про Слаку ничего не скажу - не пользовался. Но слаководы вроде в основном хвалят.

Под этими словами нет оснований. Это жуткая штука с кучей архитектурных промахов и тяжелая по сопровождению и эксплуатации

И сколько у тебя провайдеров во владении? %)

Провайдеры часто используют freebsd, openbsd. Потому что там небольшой список сервисов и потребности не очень большие. Я знаю одного провайдера, у которого всё работает на freebsd 4.2, т.е 20 лет. С небольшим списком ПО можно ставить любой дистрибутив и он будет работать. Хоть CRUX

Можешь погрепать его акк по словам debian, rhel, и почитать какие проблемы там возникают, в слаке такого нету.

Поэтому то, что у какого-то провайдера стоит slackware и оно работает - это не показатель. Далеко не показатель. И это не отменяет то, что это имеет архитектурные промахи и ужасное состояние и дорого в плане суппорта и эксплуатаци

кого ЕГО?

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

Оно работает лучше чем всякий шлак с системдой.

И это не отменяет то, что это имеет архитектурные промахи и ужасное состояние и дорого в плане суппорта и эксплуатаци

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

Автора того комментария, провайдер то его.

Окей, давай по-существу! Устанавливаем slackware. Какая цель? Сделать так, чтобы в системе не было мусора, а только нужное. Как быть в этом случае? Окей, мы не будем брать всякие там minimal cd alienbob. Берем офиц dvd

Имеем:

A	- 	The base system. Contains enough software to get up and running and have a text editor and basic communications programs.
AP	- 	Various applications that do not require the X Window System.
D	- 	Program development tools. Compilers, debuggers, interpreters, and man pages. It's all here.
E	- 	GNU Emacs. Yes, Emacs is so big it requires its own series.
F	- 	FAQs, HOWTOs, and other miscellaneous documentation.
GNOME	- 	The GNOME desktop environment.
K	- 	The source code for the Linux kernel.
KDE	- 	The K Desktop Environment. An X environment which shares a lot of look-and-feel features with the MacOS and Windows. The Qt widget library is also in this series, as KDE requires it to function.
KDEI	- 	Language support for the K Desktop Environment.
L	- 	System libraries.
N	- 	Networking programs. Daemons, mail programs, telnet, news readers, and so on.
T	- 	teTeX document formatting system.
TCL	- 	The Tool Command Language, Tk, TclX, and TkDesk.
X	- 	The base X Window System.
XAP	- 	X applications that are not part of a major desktop environment. For example Ghostscript and Netscape.
Y	- 	Games (the BSD games collection, Sasteroids, Koules, and Lizards).

Устанавливаем A, AP, F, N. Окей. Мы установили базовую систему. Далее мы ставим emacs через slackpkg. Запускаем. Видим, что он не устанавливается, потому как нет пакетов из L и X. Часть из этих пакетов нет в slackpkg, их нужно ставить из dvd. Далее я должен искать slackpkg search-file some.lib.so в каком пакете находится ВРУЧНУЮ. Я понимаю Патрика 15-летней давности, почему он решил сделать так, чтобы пакеты ставились без зависимостей. Потому как другие дистрибутивы, которые имели зависимости - часто ломались из-за того, что система управления пакетами заменяла часть бинарников\либ и приводила дистрибутив в состояние того, что он не загружался\переставал работать. А патрик решил сделать стабильный тулчаин(расширив его до практически всего дистрибутива), чтобы типа я поставил пакеты из стабильного тулчаина, а всё остальное ПО не заменяло эти пакеты. Ну так э…15 лет назад это было. Дистрибутивы с зависимостями починились за пять лет, а у слаки до сих пор надо это всё ручками-ручками(не надо сейчас о salix). Далее ваша слака ставит мне туеву хучу пакетов типа mariadb и прочего хлама. Зачем он мне? Попакетно сидеть выбирать при установке что ставить, а что нет - мне делать больше нечего. Я хочу минимал, чтобы грузился. А остальное хочу поставить сам. Но хочу поставить программы, которые работают, а не пакеты. Когда я ставлю emacs, то я хочу запустить emacs и работать в нём, а не факт установки emacs-x.y.z.txz. У меня список ПО, которым я пользуюсь - суммарно 3088 пакетов. Я не хочу эти 3088 пакетов прописывать вручную где-то в скрипте аля:

slackpkg install emacs libXft libsome1...libsome29
installpkg libsome1...libsome14 // т.к часть пакетов нет в пакетном менеджере, а только на cd

Это называется - архитектурная недоработка и вследствии чего тяжелая эксплуатация

И ПО в линуксе работает не так, как видится кому-то под тяжелыми наркотиками. Допустим, есть pidgin. Я ставлю

slackpkg install pidgin

И если я не поставил

slackpkg libicq

То pidgin запустится и будет работать, но не будет работать протокол icq. Всё не так.

По реалиям, если я поставлю dwm, но не поставлю libxinerama, то dwm не запустится, но не будет работать на нескольких мониторах, он ВООБЩЕ не будет работать. Что и видим с emacs. Если я поставил emacs, но не поставил все зависимости, то emacs - не программа, а тыква. Поставленный пакет в системе, а не работающая программа

Вот и получается, что то, что должен делать пакетный менеджер посредством железа, - должен выполнять тот, кто пользуется слакой. Я превращаюсь в пакетный менеджер. Биопакетный менеджер. Бинарный биопакетный менеджер. А в случае с CRUX - Сорс бейсед биопакетный менеджер

И не надо говорить «о Боже, как же это прекрасно!». Потому как это далеко не прекрасно. Прекрасно было 15 лет назад, когда было 15 программ и все эти зависимости можно было поставить ручками за несколько часов. А когда пакетов 3к+, - тогда такой подход, - архитектурный недостаток

Устанавливаем A, AP, F, N. Окей. Мы установили базовую систему

Нет, у тебя L пропущено, остальное не читал, вижу через строки что там тоже бред какой то, зачем ты это пишешь? Хоть что нибудь сначала узнай.

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

И как этому может помешать наличие зависимостей в пакетном менеджере?

1. Если ты удалил пакет, то зачем тебе на диске зависимости, которые не юзает не один другой пакет?

2. Если ты ставишь пакет, то ты в любом случае поставишь все зависимости, чтобы превратить из тыквы в работающую программу

3. если ты хочешь отвязать пакет от версий зависимостей, то логичней сделать систему объявления версий зависимостей по типу package.use в генте

Какой по итогу смысл в ручной установке зависимостей?

А какое отношение имеет к минимал секция L? Я какие-то пакеты ставил, которые используют библиотеки из L? А зачем мне они на диске, если я их не использую?

L - System libraries.

Устанавливаем A, AP, F, N. Окей.

Не, лучше слаку не мучай, это не твоё.

А зачем вообще нужны библиотеки, как считаешь? Может чтобы сторонний софт работал, не?

Прежде, чем я начну отвечать не твои вопросы, потрудись ответить на каждый заданный мной вопрос

Единственно, непонятно, чем не нравится единый для всех и неизменный уже около 2 десятилетий формат deb?

Во-первых, поддерживать пакеты под deb – ничего приятного.

Во-вторых, типично: Debian Gnome, APT/Aptitude -- как удалить пакет, не смотря на зависимости (аналог `pacman -Rdd` в ArchLinux)?

Вот после таких историй и приходится объяснять людям, что управление зависимостями в нормальной пакетной базе — это не больно; и что нормальные пакеты по зависимостям тянут только то, без чего исполняемый файл всё равно не запустился бы. А не пытаются изображать configuration management.

1. формат deb не плохой и не хороший. Он ровно такой, какой требуется для того, чтобы быть в итоге пакетом, а не тыквой, как в slackware

2. отсутствие инструментария и отсутствие знаний по работе с инструментарием - это совершенно разные сущности. В debian есть инструментарий, чтобы разрулить этот вопрос? Есть. Далее можно не продолжать

3. намного легче иметь пакетный менеджер, который корректно устанавливает ПО и с инструментарием работы с зависимостями, чем иметь slackpkg, который некорректно устанавливает ПО, но в плоскости которого можно вручную управлять зависимостями

отсутствие инструментария и отсутствие знаний по работе с инструментарием - это совершенно разные сущности. В debian есть инструментарий, чтобы разрулить этот вопрос? Есть. Далее можно не продолжать

О, так далеко можно зайти. Например:

«У тебя есть инструментарий, чтобы превратить Libre Office из куска говна в офисный пакет? Есть. Далее можно не продолжать.»

Героически бороться в дебиан с трудностями, которые в арче бы вообще не возникли – путь самурая? Не для меня.

slackware

Slackware тут ни при чём. Меня спросили про deb в контексте обсуждения debian vs arch.

Slackware — это просто противоположная крайность по сравнению с Debian.

Arch — срединный путь.

Под твоими кукаретическими кукареками вот точно нет оснований :)

Slackware — это просто противоположная крайность по сравнению с Debian.

Совершенно верно. Slackware - это когда ничего не работает. Debian - это когда всё работает. А arch - это когда вроде как работает, но на самом деле нет. Ролинг такой ролинг

Героически бороться в дебиан с трудностями, которые в арче бы вообще не возникли – путь самурая? Не для меня.

Так не было же проблем. Есть задача, апт имеет инструментарий, с помощью которого можно решить эту задачу. Причём тут геройство? Из сорсов кто-то заставлял что-то устанавливать? Где геройство?

Совершенно верно. slackware - это когда ничего не работает.

УМВР, а ты или /dev/ruki пересоберешь правильно, или женишься уже (возможно, не на дистрибутиве, но это не точно) :)

Slackware - это когда ничего не работает.

4.2

Debian - это когда всё работает.

4.2

А arch - это когда вроде как работает, но на самом деле нет. Ролинг такой ролинг

УМВР

Так не было же проблем. Есть задача, апт имеет инструментарий, с помощью которого можно решить эту задачу. Причём тут геройство? Из сорсов кто-то заставлял что-то устанавливать? Где геройство?

Вы в дебиане нахрена configuration management тащите на уровень пакетного менеджера? Вот эти все /etc/alternatives/gnome-www-browser и т.п.? Это же маразм в чистом виде.

Из сорсов кто-то заставлял что-то устанавливать?

Это абсолютно нормальное явление в свободой операционной системе — ставить что-то из сорцов. И в норме чтобы это сделать правильно, вовсе не требуется защищать диссертацию по устройству пакетной базы.

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

А arch - это когда вроде как работает, но на самом деле нет. Ролинг такой ролинг

Меня устраивает. У меня перестала болеть голова по поводу пакетов, как я 10 лет назад ушел на арч. Я готов заниматься пакетным спагетти в дебиане за деньги на сервере, но не у себя дома бесплатно.

Если я ставлю новую версию программы, и в ней что-то отомалось, – это нормальный, естественный процесс разработки софта. Отломалось, потом починят. Можно зарепортить баг. Отправить патч. Принять участие в жизни сообщества. Сделать что-то полезное.

Но когда на каждом грёбаном апдейте пакетный менеджер считает себя умнее админа, с этим ничего уже сделать нельзя. Это дизайн такой. Только удалить всю ОС целиком.

Машина должна быть тупой и послушной.

А дебиан послушен только своим сборщикам, а не мне, владельцу машины. Так что — на сервак, чтобы видеть его там раз в месяц, накатывая апдейты безопасности.

Не рассказывай тут сказки роллинг арчевод. Роллинг не применим не на серверах, не дома как девелоп т.к оно имеет тенденцию ломаться чаще, чем работать. Как и гента. Так что меня лично мало интересует, что там локально сделано «как надо», если глобально это - кусок чего-то там. Дебиан не идеален, но там всё решаемо. И если его сравнивать со слакой, с наркоманом во главе и его адептами, то дебиан - это идеал в степени зиллион

bryak ★★★★ (17.09.20 00:18:53) упорот

Спасибо, подписал.

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

Конечно-конечно, в секте арчлинукс, генты и слаки всё, что вне секты - от лукавого. А все кто против - упороты на 146%

А по поводу слаки - очень жаль. Там достаточно было сделать:

1. сделать livecd minimal, 1cd, dvd
2. выкинуть ненужный инсталятор
3. сделать установку через minimal торбол как в генте
4. добавить зависимости в пакеты, как это есть в salix
5. засунуть зависимости из dvd в репозитории, чтобы ставилось всё только по факту, а не предустанавливать зависимости с dvd
6. написать доки по типовым network connections
7. и вынести отдельно из реп gnome, xfce, kde, которые никому из вменяемых людей не нужны. А лучше вообще их перестать суппортить. Есть более достойные продукты типа fvwm и многое из google –> «compare tiling wm»

В итоге получился бы вполне юзабельный дистр с BSD init, у которого было бы по-больше юзеров, чем у наркомански построенной архитектуры слаки. Потому как в таком виде, в котором есть слака - она не интересна вообще никому. Не тем, кто юзает линукс для развлечения, не тем, кто хочет линукс изучать, не тем, кто держит сервера, не тем, кто использует линукс в качестве девелоп студии. Всё это крайне печально

https://www.linuxquestions.org/questions/slackware-14/donating-to-slackware-4175634729/#post5882751

Патрег занимался коммерцией 15 лет, а когда слака перестала приносить доход - тут же активизировался, написал слёзный пост, с просьбой комьюнити помочь шекелями. Кто бы сомневался. Для себя тему slackware закрываю навсегда

Ну что ж поделать, если слакварщики на ЛОРе в основном адекватный народ.

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

Во-первых, поддерживать пакеты под deb ничего приятного.

Я бы не сказал, что сильно сложнее, чем rpm.

Во-вторых, типично: Debian Gnome, APT/Aptitude – как удалить пакет, не смотря на зависимости (аналог pacman -Rdd в ArchLinux)?

В той теме тс’у же сказали: удалить метапакет gnome-core без остальных пакетов, затем пометить остальные пакеты установленными вручную командой apt-mark, затем удалить firefox и радоваться жизни. В чём проблема?

нормальные пакеты по зависимостям тянут только то, без чего исполняемый файл всё равно не запустился бы

Gnome-core – не нормальный, а метапакет. Там нет никаких файлов (ни исполняемых, ни неисполняемых), а только зависимости, которые он тянет. Если бы ТС в той теме вместо него поставил нормальные пакеты, то этой проблемы не возникло. Правда, поставить пришлось бы много. Но это несложно: копируем в буфер обмена зависимости gnome-core и вставляем их после apt install. Впрочем, скопипастить те же зависимости для apt-mark ничуть не сложнее.

Gnome-core – не нормальный, а метапакет. Там нет никаких файлов (ни исполняемых, ни неисполняемых), а только зависимости, которые он тянет.

Не требуется практически никогда. Для этого есть группы.

В чём проблема?

Здесь во всём проблема. В alternatives вынесенных на уровень ПМ, в бесконечных мета-пакетах, в общей оверинженернутости подхода и попытке чинить то, что не сломано…

Gnome-core не нормальный, а метапакет. Там нет никаких файлов (ни исполняемых, ни неисполняемых), а только зависимости, которые он тянет.

Не требуется практически никогда. Для этого есть группы.

Так кто ж заставлял ставить, если не треба?

В чём проблема?

Здесь во всём проблема. В alternatives вынесенных на уровень ПМ,

А чем безальтернативный подход лучше? Ну было бы написано там только firefox, а не или-или-или, тс’у от этого легче стало бы?

в бесконечных мета-пакетах,

Так никто не заставляет их ставить. В чём проблема? В описании написано, что это метапакет.

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

Не понял, что чинить? Есть пакетный менеджер с зависимостями. ТС’у объяснили, как это преодолеть. Не нравится? Никто не мешает ставить из исходников и превращать систему в помойку. Потому что основной смысл пакетного менеджера – предотвратить эту помойку. А если зависимости игнорировать, то предотвратить не получится, – за всем придётся следить самому.

Это была попытка этого товарища показать, что arch хороший, а debian - плохой. Но не вышло. Беда-беда