Да, но unix-shell - это основа работы в командной строке (и если не писать сложных скриптов, то достаточно выучить основы любой shell и легко переходить с одной на другую). И, опять же, для массового переименования файлов мне не надо создавать и сохранять, а потом запускать отдельный скрипт.
А в целом винда - это просто базовая ОС + DE.
Об этом и речь. Как была когда-то графической надстройкой над DOS, так по сути тем же много лет и оставалась. Да, надёжность повышалась, на смену псевдо-многозадачности пришла истинная многозадачность, но в плане управления во многом оставалась просто графической оболочкой, т. к. развивался только графический интерфейс рабочего стола.
если бы не постоянные zero day в ядре, браузерах, сетевых службах. Так что с роллингом как-то спокойнее
Как раз уязвимости в Debian закрываются очень оперативно. А вот другие баги, не связанные с безопасностью, действительно могут оставаться вплоть до выхода новой стабильной версии. Но эта особенность тоже связана с повышением надёжности и безопасности, т. к. исправляя один баг, легко добавить другой. И если первый был связан с какой-то мелочью, а второй открывает огромную чёрную дыру, то вряд ли это можно считать улучшением. Отсюда и такая политика: все уязвимости исправляем как можно быстрее, остальное тщательно тестируем и обновляем только в следующем стабильном выпуске. Поэтому в плане 0day - Debian как раз одна из самых безопасных систем.
Как была когда-то графической надстройкой над DOS, так по сути тем же много лет и оставалась.
Смотря что чем называть. В MS DOS'е, например, у каждой софтины были свои драйвера. Win 9x/NT резко скакнули вперёд предоставив возможность не писать свои драйвера для всего зоопарка железа как это было в MS DOS'е.
Что доказывает ущербность gui для любых мало-мальски нетривиальных задач.
Win 9x/NT резко скакнули вперёд предоставив возможность не писать свои драйвера для всего зоопарка железа как это было в MS DOS’е.
Разумеется. Там ещё много всего было. И новые ядра (в NT 3 даже частично микро-ядро, но потом от этого ушли), и частичная поддержка posix в NT 4, от которой потом тоже отказались, и много другого. Разумеется, я немного утрирую.
Т. е. удалось найти серьёзную уязвимость, специфичную исключительно для debian, только на конец 2006 – начало 2007 года? Это как раз доказывает моё утверждение об относительной безопасности Debian. А абсолютно безопасных систем не бывает по определению. В любом другом дистре или оси тоже можно найти специфические для них уязвимости. И, думаю, в большинстве дистров их будет больше, чем в Debian.
У Дебиана релиз-цикл предсказуемый и понятный. Фиксы безопасности выходят оперативно. Хорошая система для сервера. Не смотря на мою личную неприязнь к формату deb.
У Арча апдейты выходят ежечасно. Общее состояние системы и её уровень безопасности зависят напрямую от апстрима каждого отдельного компонента. Есть шанс поймать свежую уязвимость. Но так как никто не крутит арч на сервере, маловероятно, что кто-то будет специально целиться в такую уязвимость.
За счёт общей просты конструкции и удобной установки софта из AUR, хорошая система для домашнего компьютера.
Слака обоим вариантам проигрывает по разным критериям.
Походу, молоко, с добавкой лактазы, витамина А и Д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.
Если лактозу просто расщеплять, то молоко будет слишком сладкое. Так что вероятно отфильтровывают сахара к хренам, и остаётся жирненькая белковая фигня. Очень надо такое пить? Кстати, организм правильно делает, что сблевывает ненужно. Вы же не дитё уже.
Касательно дебиана и арча полностью согласен. Единственно, непонятно, чем не нравится единый для всех и неизменный уже около 2 десятилетий формат deb? Неужели зоопарк несовместимых между собой форматов под общим названием rpm лучше?
Про Слаку ничего не скажу - не пользовался. Но слаководы вроде в основном хвалят.
Провайдеры часто используют freebsd, openbsd. Потому что там небольшой список сервисов и потребности не очень большие. Я знаю одного провайдера, у которого всё работает на freebsd 4.2, т.е 20 лет. С небольшим списком ПО можно ставить любой дистрибутив и он будет работать. Хоть CRUX
Поэтому то, что у какого-то провайдера стоит 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к+, - тогда такой подход, - архитектурный недостаток
А какое отношение имеет к минимал секция L? Я какие-то пакеты ставил, которые используют библиотеки из L? А зачем мне они на диске, если я их не использую?
Вот после таких историй и приходится объяснять людям, что управление зависимостями в нормальной пакетной базе — это не больно; и что нормальные пакеты по зависимостям тянут только то, без чего исполняемый файл всё равно не запустился бы. А не пытаются изображать configuration management.
формат deb не плохой и не хороший. Он ровно такой, какой требуется для того, чтобы быть в итоге пакетом, а не тыквой, как в slackware
отсутствие инструментария и отсутствие знаний по работе с инструментарием - это совершенно разные сущности. В debian есть инструментарий, чтобы разрулить этот вопрос? Есть. Далее можно не продолжать
намного легче иметь пакетный менеджер, который корректно устанавливает ПО и с инструментарием работы с зависимостями, чем иметь slackpkg, который некорректно устанавливает ПО, но в плоскости которого можно вручную управлять зависимостями
отсутствие инструментария и отсутствие знаний по работе с инструментарием - это совершенно разные сущности. В debian есть инструментарий, чтобы разрулить этот вопрос? Есть. Далее можно не продолжать
О, так далеко можно зайти. Например:
«У тебя есть инструментарий, чтобы превратить Libre Office из куска говна в офисный пакет? Есть. Далее можно не продолжать.»
Героически бороться в дебиан с трудностями, которые в арче бы вообще не возникли – путь самурая? Не для меня.
slackware
Slackware тут ни при чём. Меня спросили про deb в контексте обсуждения debian vs arch.
Slackware — это просто противоположная крайность по сравнению с Debian.
Slackware — это просто противоположная крайность по сравнению с Debian.
Совершенно верно. Slackware - это когда ничего не работает. Debian - это когда всё работает. А arch - это когда вроде как работает, но на самом деле нет. Ролинг такой ролинг
Героически бороться в дебиан с трудностями, которые в арче бы вообще не возникли – путь самурая? Не для меня.
Так не было же проблем. Есть задача, апт имеет инструментарий, с помощью которого можно решить эту задачу. Причём тут геройство? Из сорсов кто-то заставлял что-то устанавливать? Где геройство?
Так не было же проблем. Есть задача, апт имеет инструментарий, с помощью которого можно решить эту задачу. Причём тут геройство? Из сорсов кто-то заставлял что-то устанавливать? Где геройство?
Вы в дебиане нахрена configuration management тащите на уровень пакетного менеджера? Вот эти все /etc/alternatives/gnome-www-browser и т.п.? Это же маразм в чистом виде.
Из сорсов кто-то заставлял что-то устанавливать?
Это абсолютно нормальное явление в свободой операционной системе — ставить что-то из сорцов. И в норме чтобы это сделать правильно, вовсе не требуется защищать диссертацию по устройству пакетной базы.
Если вы считаете, что пользователь должен сидеть на списке пакетов, который ему накидали составители дистрибутива, это огороженность покруче айфона.
А arch - это когда вроде как работает, но на самом деле нет. Ролинг такой ролинг
Меня устраивает. У меня перестала болеть голова по поводу пакетов, как я 10 лет назад ушел на арч. Я готов заниматься пакетным спагетти в дебиане за деньги на сервере, но не у себя дома бесплатно.
Если я ставлю новую версию программы, и в ней что-то отомалось, – это нормальный, естественный процесс разработки софта. Отломалось, потом починят. Можно зарепортить баг. Отправить патч. Принять участие в жизни сообщества. Сделать что-то полезное.
Но когда на каждом грёбаном апдейте пакетный менеджер считает себя умнее админа, с этим ничего уже сделать нельзя. Это дизайн такой. Только удалить всю ОС целиком.
Машина должна быть тупой и послушной.
А дебиан послушен только своим сборщикам, а не мне, владельцу машины. Так что — на сервак, чтобы видеть его там раз в месяц, накатывая апдейты безопасности.
Не рассказывай тут сказки роллинг арчевод. Роллинг не применим не на серверах, не дома как девелоп т.к оно имеет тенденцию ломаться чаще, чем работать. Как и гента. Так что меня лично мало интересует, что там локально сделано «как надо», если глобально это - кусок чего-то там. Дебиан не идеален, но там всё решаемо. И если его сравнивать со слакой, с наркоманом во главе и его адептами, то дебиан - это идеал в степени зиллион
А по поводу слаки - очень жаль. Там достаточно было сделать:
сделать livecd minimal, 1cd, dvd
выкинуть ненужный инсталятор
сделать установку через minimal торбол как в генте
добавить зависимости в пакеты, как это есть в salix
засунуть зависимости из dvd в репозитории, чтобы ставилось всё только по факту, а не предустанавливать зависимости с dvd
написать доки по типовым network connections
и вынести отдельно из реп gnome, xfce, kde, которые никому из вменяемых людей не нужны. А лучше вообще их перестать суппортить. Есть более достойные продукты типа fvwm и многое из google –> «compare tiling wm»
В итоге получился бы вполне юзабельный дистр с BSD init, у которого было бы по-больше юзеров, чем у наркомански построенной архитектуры слаки. Потому как в таком виде, в котором есть слака - она не интересна вообще никому. Не тем, кто юзает линукс для развлечения, не тем, кто хочет линукс изучать, не тем, кто держит сервера, не тем, кто использует линукс в качестве девелоп студии. Всё это крайне печально
Патрег занимался коммерцией 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, а не или-или-или, тс’у от этого легче стало бы?
в бесконечных мета-пакетах,
Так никто не заставляет их ставить. В чём проблема? В описании написано, что это метапакет.
в общей оверинженернутости подхода и попытке чинить то, что не сломано…
Не понял, что чинить? Есть пакетный менеджер с зависимостями. ТС’у объяснили, как это преодолеть. Не нравится? Никто не мешает ставить из исходников и превращать систему в помойку. Потому что основной смысл пакетного менеджера – предотвратить эту помойку. А если зависимости игнорировать, то предотвратить не получится, – за всем придётся следить самому.