Нещата наистина са навързани грубо. Наричат се зависимости. Инсталиран пакет с множество зависимости от едно издание в друго. Несъвместими пакети.

Прекрасно, сега остава да обясниш как системата от зависимости е дефинирана толкова добре, че по-нова версия на питонска библиотека води до инсталация на нова инит система. Ама се постарай, защото ще стана циничен буквалист, повярвай ми

offtopic: Ми да, чудя са аз кога ще се сетят и ще почнат да правят монолитни пакети, кой го боли вече за повечето място ... поне донякъде проблема ще се реши с такива недомислици. Особено като става дума за development върви си настройвай машината за нуждите на някой стар проект ...

Някой ползвал ли е този инструмент?
http://anyfs-tools.sourceforge.net/man8/anyconvertfs.8.html
 
Или изобщо някакъв друг читав инструмент който може да конвертира NTFS към EXT ( може и EXT2 да е, аз ще си вдигна журнала после ).
Имам 1TB на единия диск на лаптопа (5400 оборота) и нямам голямо желание да прехвърлям данни.
Ако някой има наблюдения по темата, ще съм благодарен, ако сподели.

Видиш ли xml, изтрелвай се като бясно куче....

Някъде мярнах, че systemd решили дори да ползват javascript в конфиг файловете. Това вярно ли е или е просто легенда? Не мога да го проумея ако е истина.

Ако става въпрос за json какъв е проблема?
Чудесно се чете и редактира от човек и лесно се парсва. Отделно имаш много по-малък по обем файл, отколкото xml-a.

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Просто името на правилото е променено от udev 209 на 80-net-setup-link.rules

Ами и ти си прав. Само че, ако се погледне от друга гледна точка ( на RedHat ), пичовете искат да сменят начина по който работят нещата.
За да се случи това в даден момент трябва да се потроши обратната съвместимост / инструментите / начина на конфигурация и т.н. ( дали е за добро не се знае, ама ще видим ). От там нататък RedHat са големи, ползват се масово, стандартизирани са и бачкат с големите играчи ... демек - могат да си го позволят.
Оттам нататък другите големи Debian/Suse решиха и те да се включат. От тук следва, че software като цяло за Линукс, ще се пише, като се съобразява с тях и конфигурирането ще става по този начин - щем нещем.
Сега проблема идва в дистрибуции, които се дърпат. Ама то това пак не е проблем. Предполагам ще се fork-ва софт, ще се пише нов специално за тях - което в крайна сметка е хубаво. От една страна имаш някаква стандартизация, на по-големите ( до колко всичко ще е ОК, ще видим ), отдруга страна другите, дето не ги кефи ще си създадат алтернативи ( макар, че според мене ще са ощетените в случая ).

п.с.
Така като гледам за logwatch има пач от март месец: http://sourceforge.net/p/logwatch/patches/34/
Не е мърджнат все още, ама, ако някой иска предполагам - може да го ползва.

Някой беше споменал, че UDEV се траел (не се сещам кой беше, просто треда стана много дълъг). Та точно UDEV ми е идеален пример за Пьотерингщина и уиндолз талибанщина. Понеже ползвам Gentoo (който е ролинг ъпдейт дистрибуция) някои от нещата които скъсяват живота на мейнтейнърите на нормални дистрибуции се проявяват и при крайните потребители. Може би на никой не му е направило впечатление, но преди време някой гений в пристъп на "иновационно" прозрение реши, че мрежовите интерфейси вече не е нужно да с eth0-1, а нещо "по-истинско". Като основен аргумент беше изтъкнато, че видиш ли, при много мрежови интерфейси не е ясно кой ще се инициализира първи и ще бъде съответно eth0. Това си беше определено проблем но си имаше простичко решение - в конфигурационен файл се пишеше кой е мак адреса на картата съответстващ на съответното /dev/eth0. Дистрибуциите си го правеха автоматично и никой не забелязваше.
От както udev беше прилапан в systemd. Първо се появи някаква схема за "предвидими" имена която подреждаше интерфейсите по шините на които са закачени и им даваше някакви невероятностни имена или пък към етх се прибавяше мак адреса (някой от вас знае ли си мак адресите на картите наизуст, че да му е лесно да се ориентира). Имаше я и възможността нещата да са си по старому, като във файлче просто се пишеше съответният мак адрес за кое етх работи.
Както се казва "да ама не". След като udev попрестоя под крилото на великият Пьот решиха, че от една версия нататък вече настройките за мак адрес ще се игнорират и трябва или да се примириш с въртенето на интерфейси при всеки рестарт или да минеш на великата им схема с предвидими имена. Държах около година новият udev маскиран но накрая реших, че няма как - ще мигрирам към предвидими имена и се почна... Първо - научи как се казват новите интерфейси. После виж кой интерфейс кой е. Накрая променяй абсолютно всички скриптове, файърлоли и мрежови конфигурации. Принудих се няколко пъти да търча до офиса и да конфигурирам физически машината докато видя кое къде е закачено. Беше велико приключение.
Като друг пример на велика Пьотерингщина можа за посоча изискването /usr да не е на отделен дял, а част от / защото вече udev имал зависимости в /usr/lib (предполагам разбирате какво значи това на практика). За тези които са си форматирали дисковете и си ползват системите от години единствената възможност е да си правят initrd. Лично аз сам си компилирам кернела и никога не съм се занимавал с подобни глупости, защото в моя случай беше напълно излишно. Уви, вече трябва и с това да се занимавам като компилирам кернел.
Просто неща които са много на брой и дребни на пръв поглед се събират и правят живота ти черен. Това е systemd манталитетът.

net.ifnames=0 и biosdevname=0 към кърнала не ти ли решават проблема с имената на адаптерите?
Мен ми беше странно под centos 7 първоначално, ама не е проблем да се бачка с NetworkManager-a.

Разгледай CASE/IF/COUNT/SUM функциите на MySql.

Когато приложния софтуер стане зависим от системД, тогава и слакерите няма къде да ходят освен в киреча.

Точно това ще е най-добре от цялата работа. Нещо да се ползва от всички искат не искат. И ако някой не го кефи да се карат вътрешно и заедно да се взимат решенията, кое, как и защо да работи. Не да има 5000 вариации с които да трябва да се съобразяваш при писане/администриране на софтуер.

Аз пък съм твърдо за.
Изобщо не ме бърка дали ще е systemd или някоя друга боза, стига да получи adoption от най-голям брой дистрибуции (най-вече по-разпространените).
Трябва да има най-накрая някаква стандартизация и като седнеш да правиш нещо да не трябва да се съобразяваш, къде ще се run-ва.
Тази фрагментация при Линукс, вече почна да става голяма простотия. Примерно wayland/mir/xorg и накрая нищо не работи като хората.
Systemd не знам до колко е зле ( ползвам го само на една машина с fedora и си работи), ама поне внася някаква стандартизация.
Иначе това предложение ми харесва http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Междудругото, това, че Lennart Poettering бил немарлив откъм писане, не значи ще софтуера е shit, до колкото съм запознат има доста други програмисти, които бачкат по него, просто около Poettering се вдига шум.

@geroy какво точно не ти е наред с вдигането на service в systemd ( освен простотията, че не отговаря на *nix принципите и ала-бала )?

п.с. Мен единственото, което ми е неудобно ( ама по-скоро е до свикване ) са логовете.

WHERE не, но при ON минимално да окажеш поле на релацията.

Тоя INNER можеш ли да ми кажеш защо точно го използваш?
В случая ти трябва LEFT JOIN (LEFT за да имаш все пак резултат, ако липсват данни в някоя от таблиците).
След това сложи alias-i на самите имена та таблиците в WHERE и JOIN и в SELECT-a описвай нужните колони с tablealias.columnname

п.с.
@laskov Не е много-препоръчително ползването на SELECT-и от темп таблици без да е наложително (макар, че имаш optimizer при MySQL при по-стара версия от 5.6 е супер дървен), за такова Query изобщо няма файда.

В freebsd портът на bash се инсталира в /usr/local/bin, така че е защитен от скриптове с shebang, който сочи към /bin/bash

Е ти това нещо верно ли го казваш? ... Супер защита е. Ами ако го изпълняваш през env (както междудругото е в по-голямата част от случаите), май защитата пада

Какъв е проблемът? Нали говорихме за freebsd и случая със скриптове, които почват с #!/bin/bash

Да, тези скриптове могат да започват с /usr/bin/env bash

Хах, ами тук нямам идея. Със csh не съм много запознат.
Ама или и той е уязвим на същата атака или env вдига по някакъв начин bash subshell или нещо от сорта.
Някой, ако има идея да каже.

Нямам идея как стои въпроса с freebsd, предполагам че е както в убунту - в двата случая това че bash не е дефолтския шел не те спасява от проблема. Първият шел скрипт с #!/bin/bash отгоре на който можеш да му контролираш environment-а, ще даде въпросния проблем. Решението не е в смяната на дефолтния шел, решението е или в премахването на bash, или в пачването му.

В freebsd портът на bash се инсталира в /usr/local/bin, така че е защитен от скриптове с shebang, който сочи към /bin/bash

Е ти това нещо верно ли го казваш? ... Супер защита е. Ами ако го изпълняваш през env (както междудругото е в по-голямата част от случаите), май защитата пада

@gat3way Някакъв успех с exim-a?
Спрях cgi-ите на всички стари машини и мисля да прекомпилирам bash-a остана една стара машина с freebsd 8 нещо-си, която търкаля само един exim и се чудя дали изобщо има смисъл.

п.с.
BSD-то си идва с csh по default, ама това специално е модвано от бивш колега и слага bash по с default инсталацията.

То това си е официален бъг.
Ето малко линкове, които обясняват за какво става въпрос.

https://bugzilla.redhat.com/show_bug.cgi?id=995271
https://groups.google.com/forum/#!topic/linux.kernel/DY988quNrlg

Това са решенията уж ...
http://www.it3.be/2013/10/16/write-same-failed/
https://bbs.archlinux.org/viewtopic.php?id=164377

Ако имаш желание да прекомпилираш ето и пач.
http://marc.info/?l=linux-scsi&m=138252394614920&w=2