| 1.1, Аноним (-), 09:32, 04/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Все эти flatpak'и от протухщих реп. Была бы "база" с DE, а остальное rolling'ом бы обновлялось - не было б таких замут.
| | |
| |
| 2.7, Аноним (-), 11:10, 04/04/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Поддерживаю, товарищ анонимус. Плюс это очень помогает паковать свой мерзкий проприетарный софт под этот ваш линукс.
| | |
| 2.12, Аноним (-), 12:42, 04/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
В первой половине 00-х дефолт-линуксом был Red Hat и его производные: Fedora, Mandrake, SUSE. Году примерно в 2005 его решили сделать дефолт-линуксом вполне себе официально. Вышел документ LSB 3.0, подразумевающий что всю бинарщину надо собирать в CentOS 4. Вообще, LSB описывает совместимость старого редхата с новым, но идея так страшно всем понравилась, что это реализовали все дистры.
А потом была вирусная популярность убунты, которая хоть и тоже поддерживала стандарт, но авторы софта знать о нём ничего не знали, и компиляли в домашней ОС.
Если тебе интересно что за стандарт такой - вот: http://refspecs.linuxfoundation.org/lsb.shtml Суть в том что есть набор системных библиотек определённых версий. Это стек Xprg, стек GTK, libpng обязательно версии 1.2, libjpeg обязательно версии 62, libasound.so.2, libcups-не-помню-какой, libsane-тоже-не-помню. Исходя из этого:
1). Если в дистре libjpeg.so.8, а не 62, то версия 62 тоже должна лежать в /usr/lib. Даже если ни одна программа с ним не собрана. При установке флеш плеера или скайпа, библиотека будет задействована.
2). Стек GTK и Xorg не меняет ABI, поэтому названия файлов библиотек остаются прежними. Разработчики обязуются сохранять обратную совместимость с прогами, собранными со старыми версиями Xorg и GTK.
Собственно и всё. Собираешь в CentOS 6, потом прогоняешь ldd и смотришь, какие не входящие в стандарт либы нужны твоей программе. Кладёшь их вместе с программой, или прописываешь как зависимость для RPM/DEB.
Что касается rolling-а. Есть репозиторий EPEL с кучей либ последних версий. Я там беру boost. Есть репозиторий devtoolset с самым свежим на данный момент GCC.
| | |
| |
| 3.13, Аноним (-), 12:55, 04/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ты все правильно говоришь. Но еще нужно добавить, что популярность разработки гуя на Mono (давно), питоне, и аналогах, привела к тому, что либы нужны самые-самые _те_которые_на_машине_разработчика_, а компиляции-то нет, ldd не на что делать, да и разработчик не знает о таком.
| | |
| 3.18, Аноним (-), 14:13, 04/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Брат Анон, тут не про то. Тут вот про что. Поглядим на Debian или на Ubuntu LTS какую-нибудь. Ядро, glibc и X'ы какие-нибудь зафиксировать - ок. Но зачем мне Avidemux, или Pidgin какой-нибудь 5 летней давности? Пусть себе обновляется тихонько. Только силы maintainer'ов распылять на бекпортирование фиксов. Тогда бы сами maintainer'ы поддерживали актуальную версию пакета, а разработчики, которые не смогли / не удосужились собрать под _DISTONAME_ не ныли бы.
| | |
| |
| 4.20, angra (ok), 15:17, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Основная сфера для Debian это не локалхосты, а сервера. И если там тихонько обновится какой-нибудь php с 5.5 на 5.6 или 7.0, то минимум половина сайтов рухнет и оперативно исправить это будет некому. Поэтому и существует stable.
Но даже на десктопе средний юзер совсем не будет в восторге, если новая версия программы откажется работать из-за старой libc или иксов. А если отпустить иксы, то их обновление легко приведет к страшному черному экрану или как минимум переходу на vesa при следующей загрузке из-за несовместимости с драйвером видяхи.
| | |
| |
| 5.24, Вареник (?), 16:00, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Основная сфера для Debian это не локалхосты, а сервера. И если там
> тихонько обновится какой-нибудь php с 5.5 на 5.6 или 7.0, то
> минимум половина сайтов рухнет и оперативно исправить это будет некому. Поэтому
> и существует stable.
> Но даже на десктопе средний юзер совсем не будет в восторге, если
> новая версия программы откажется работать из-за старой libc или иксов. А
> если отпустить иксы, то их обновление легко приведет к страшному черному
> экрану или как минимум переходу на vesa при следующей загрузке из-за
> несовместимости с драйвером видяхи.
Вот именно. Смысл LTS - чтобы все работало.
Но народ хочет чтобы стабильность LTS и обновления как Генты, прямо с последним коммитом, но без крашей остальных частей системы.
| | |
| |
| 6.42, Нормальный (ok), 13:07, 05/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Но народ хочет чтобы стабильность LTS и обновления как Генты, прямо с
> последним коммитом, но без крашей остальных частей системы.
Ну и пусть ставят генту, в чем проблема?
| | |
|
| 5.43, пох (?), 20:33, 07/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Основная сфера для Debian это не локалхосты, а сервера.
серверу ничто не мешает быть чьим-нибудь локалхостом. Судя по популярности спама с затрояненных "серверов" массхостеров, процентов 90 "серверов" ими и являются.
> И если там тихонько обновится какой-нибудь php с 5.5 на 5.6 или 7.0
у вас на сервере стоит php из поставки дебиана(rh/ubuntu/etc), который от этого может сломаться? Нет, вы серьезно?
Может у вас еще и php-шные модули из пакетиков?
отдельно хотелось бы поинтересоваться сроком жизни ваших серверов. У меня вот, к примеру, есть в области доступности (я уже не админ) сервер, который я застал живым но не вполне здоровым в 1999м. Не знаю, когда его устанавливали, надо у dmarck' спрашивать.
Он, конечно, ползучеапгрейдится, и попутно уже давно выброшен на периферию конторы, которой принадлежит, плюс там ни разу не php, но, тем не менее, его вроде не собираются еще отправлять на свалку.
Свои у меня живут поменьше, лет по десять, что тоже далеко за пределами сроков жизни самого живучего L из TS.
Так что основное назначение LTS - все ж таки именно десктопы. Срок жизни трогательно коррелирует со сроком жизни средневзятого десктопного ящика - после пяти лет уже, пожалуй, и правда пора в утиль, ползучим апгрейдом тут уже не поможешь.
| | |
|
|
| 3.28, freehck (ok), 19:30, 04/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > В первой половине 00-х дефолт-линуксом был Red Hat и его производные: Fedora, Mandrake, SUSE.
Интересно, по каким это критериям он был "дефолт-линуксом".
Первый Debian вышел на 2 года раньше Red Hat Linux, и до сих пор почти во всём опережает RHEL.
> Году примерно в 2005 его решили сделать дефолт-линуксом вполне себе официально. Вышел документ LSB 3.0, подразумевающий что всю бинарщину надо собирать в CentOS 4
LSB - это была замечательная попытка заставить Linux выглядеть более приятно для разработчиков проприетарных программ. Однако, как показала практика, попытка провалилась.
> А потом была вирусная популярность убунты, которая хоть и тоже поддерживала стандарт, но авторы софта знать о нём ничего не знали, и компиляли в домашней ОС.
Ну, убунту Вы за уши притянули и повесили на неё все грехи. :)
LSB не выстрелил потому, что нанять разработчиков, которые понимали, что такое LSB, могли только большие компании. А для большой компании "omnia mea mecum porto" не проблема.
| | |
| |
| 4.30, Аноним (-), 21:37, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А для большой компании "omnia mea mecum porto" не проблема.
Всегда умиляли люди пытающиеся показаться умнее чем они есть на самом деле.
Если вы приводите цитату, то хотя бы смысл этой цитаты нужно понимать.
| | |
| |
| 5.41, freehck (ok), 11:56, 05/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
Да, не прав, извиняюсь. Перевожу на нормальный язык:
Большая компания, производящая большой программный комплекс, обычно в составе этого комплекса тащит все используемые ими библиотеки.
То есть LSB - это по сути попытка сделать платформу привлекательной для небольших проприерастов, в то время как большие прекрасно обходились (и обходятся) без LSB.
Небольшие не оценили, потому что не смогли. А большим это нафиг не надо.
| | |
|
|
| 3.29, Ergil (ok), 19:49, 04/04/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Анон, я тебе сейчас порву шаблон. SuSE хоть и rpm-based, но не RH-based, а вовсе даже Slackware-based. Учи историю и не позорься перед теми, для кого это — живые воспоминания.
| | |
| |
| 4.31, Аноним (-), 21:41, 04/04/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Анон, я тебе сейчас порву шаблон. SuSE хоть и rpm-based, но не
> RH-based, а вовсе даже Slackware-based. Учи историю и не позорься перед
> теми, для кого это — живые воспоминания.
> Ergil, я тебе сейчас порву шаблон. У дистрибутива есть номер релиза. И если версия 1.0 основана на слаке, то версия 18.0 не обязана быть основана на слаке. | | |
| 4.36, fi (ok), 00:19, 05/04/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
 А давай я тебе порву…? S.u.S.Е в своей молодости металась как мышь ужаленная- под этой маркой собирались не совместимые друг с дугом довольно странные дистрибутивы (с тремя bootpd за раз!!!) - пока не поняли что надо делать свою ОС, а не сборную солянку - дистрибутив. И SLES, a затем SLED стали вполне себе RH-подобные системы, с равнением на LSB.
так что про слаку - мимо, там похоже до сих пор rc.local :))))
| | |
|
| 3.34, Аноним (-), 22:51, 04/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
сюська от красношляпы ???
не поверишь, но от слаки она изначально была
| | |
|
|
| 1.8, nobody (??), 11:38, 04/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Оставить apt для базовой системы, пользовательские приложения перевести на универсальный пакетный менеджер - и настанет...
http://flatpak.org/apps.html
лучше чем ничего, но с библиотекой Steam не сравнить. В какой версии догадаются сделать интеграцию с платёжными системами?
| | |
| 1.10, Аноним (-), 12:26, 04/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я считаю что эти флатуляции-пуки - не нужны. Кто не плюётся на Red Hat, у того и так норм бинарники получаются. А кто собирает в домашней убунточке 17.04, а потом удивляется что у других не работает - ССЗБ.
| | |
| |
| 2.11, Аноним (-), 12:31, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
С программами на C, С++ все нормально. А вот всякие козлопитоны, иногда ява, требуют всяких либ, которые из-за зоопарка актуальных мажорных версий отсутствуют. Поэтому "nix-env -i calibre" - и нет забот. А флатпак для проприетарщины.
| | |
| |
| 3.14, Аноним (-), 13:03, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
А почему тогда youtube-dl с официального сайта везде работает? Я в разных дистрах пробовал запускать примерно так: "python youtube-dl -f 137+140 URL"
| | |
| |
| 4.21, дАноним (?), 15:44, 04/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А почему тогда youtube-dl с официального сайта везде работает? Я в разных
> дистрах пробовал запускать примерно так: "python youtube-dl -f 137+140 URL"
Потому что хипстеризм и умный вид не заменяют реальных знаний.
Это видно хотя бы по "С++ все нормально". Насмешил, че:
> /usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found
> /usr/lib/libstdc++.so.6: version 'CXXABI_1.3.8' not found | | |
| |
| 5.26, Аноним (-), 17:18, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Когда я скомпилировал последний GCC в Debian, у меня так и было. Приходилось вместе с дистрибутивом программы распространять также и libstdc++.so.6. Прямо как msvcp60.dll.
В CentOS в репозитории devtoolset лежит волшебный GCC, который собирает прогу так, что она не хочет новый libstdc++.so.6. Я не знаю как это делается, но подозреваю что этот GCC собран с чем-то вроде --enable-libstdxx-compat Хочу такой GCC в Debian :-(
| | |
| |
| 6.46, пох (?), 08:16, 08/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> В CentOS в репозитории devtoolset лежит волшебный GCC
поколение флэтпака...
все им волшебные gcc нужны.
rm твой libstdc++.so* - и программа, волшебнейшим образом, соберется с libstdc++.a
Альтернатива, пригодная процентов для 90 сиплюсовых программ - make LD=/usr/bin/gcc и аналогичный хак для либтула (там сложнее, патчить в ста местах порождения этого уродища) - в большинстве случаев эта прослойка для совместимости незнамочего незнамо с чем (это давно уже не std) для работы совершенно не нужна, ее автоматически линкует g++ если его вызвать вместо линкера.
Но раз даже до этого ты не додумался (и нет, для этого не нужно было заглядывать в исходник gcc) - иди, качай свежий флэтпак, там о тебе позаботились.
| | |
|
|
|
| 3.23, Вареник (?), 15:55, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> С программами на C, С++ все нормально. А вот всякие козлопитоны, иногда
> ява, требуют всяких либ, которые из-за зоопарка актуальных мажорных версий отсутствуют.
> Поэтому "nix-env -i calibre" - и нет забот. А флатпак для
> проприетарщины.
Ява на удивление универсальна. JDK 1.5.x можно запустить на современном дистрибутиве Linux, на последней винде и даже не ругнется. Будет работать. Это JDK, помимо переносимости жарников.
Какой еще фреймворк можно так гладко стартануть, с разницей либ в 12-15 лет?
| | |
| |
| 4.32, Аноним (-), 21:46, 04/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> С программами на C, С++ все нормально. А вот всякие козлопитоны, иногда
>> ява, требуют всяких либ, которые из-за зоопарка актуальных мажорных версий отсутствуют.
>> Поэтому "nix-env -i calibre" - и нет забот. А флатпак для
>> проприетарщины.
> Ява на удивление универсальна. JDK 1.5.x можно запустить на современном дистрибутиве Linux,
> на последней винде и даже не ругнется. Будет работать. Это JDK,
> помимо переносимости жарников.
> Какой еще фреймворк можно так гладко стартануть, с разницей либ в 12-15
> лет?
это интерпрайс, у NET неплохая совместимость, но до jrm там конечно далеко.
| | |
| |
| 5.45, пох (?), 20:49, 07/04/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> это интерпрайс, у NET неплохая совместимость, но до jrm там конечно далеко.
угу, неплохая (печально глядя на мешанину из 2, 3.5кактамего 4.5 и местами отдельно 4.6).
Версий jre, причем с точностью до третьей цифры релиза, приходится держать гораздо больше.
| | |
|
| 4.44, пох (?), 20:47, 07/04/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Ява на удивление универсальна. JDK 1.5.x можно запустить на современном дистрибутиве
и кому вот от этого счастье?
> помимо переносимости жарников.
так вот ее-то как раз в помине нет.
> Какой еще фреймворк можно так гладко стартануть, с разницей либ в 12-15
> лет?
кому нужен фреймворк, если апликуха выдает "socket error" (привет, asdm)? И что будешь делать с "фреймворком", если апликуха таки нужна (встроена в железяку за $k, нет, мало за $m) ?
Отдельный привет передает то, что она вебовская, а твой супер-модный-защищенный браузер на попытку запустить тут нужную версию jre заявляет, что она очень несекьюрна, идите-ка лесом.
И мы банально ставим очередную стодесятую виртуалку с раз и навеки прибитыми гвоздями версиями софта и этой жабы, закрываем ее внутри периметра, и vpn-логины выдаем после подписания соглашения о продаже души.
flatpack, в общем-то, лекарство от примерно той же самой болезни, только вывернутой наизнанку - как правило, его используют, когда девелоперам вштырило употребить завтрашний релиз какой-нибудь очередной мега-фигни. Ну или когда оно так случайно получилось из-за убунты на столе девелопера, да, а статическую сборку он ниасилил, ибо сплошной npm и node.js (да и с "простыми c/c++" сломана она давно и прочно - в том числе, борцунами с проприетаризмом исключительно ради светлой идеи. Кто там жаловался на stdc++? Это вы еще libgcc_s не видели во всей ее безобразной красе!)
| | |
|
|
|
| 1.16, jOKer (ok), 13:55, 04/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 Вот читаю в очередной раз об очередных самодостаточных пакетах и думаю себе: "Если они такие самодостаточные, то может они обойдутся как-нибудь без Линукса, а мы без них?" Не, ну в самом деле, ну зачем они? Для игр? Так есть Стим как образец для подражания. Для всего остального? Так это все остальное почти что все отлично компилируется и не нуждается в такой самодостаточности. Для проприетарщины, которую ее создателям взападло сделать открытой, а запихать в облако просто лениво или дорого? Ну разве что... И что, вот ради этих пяти с половиной проприетарных пакетов нужно было городить огород?! Ну, блиин, кааампот!
| | |
| |
| 2.33, Аноним (-), 21:49, 04/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Вот читаю в очередной раз об очередных самодостаточных пакетах и думаю себе:
> "Если они такие самодостаточные, то может они обойдутся как-нибудь без Линукса,
> а мы без них?" Не, ну в самом деле, ну зачем
> они? Для игр? Так есть Стим как образец для подражания. Для
> всего остального? Так это все остальное почти что все отлично компилируется
> и не нуждается в такой самодостаточности. Для проприетарщины, которую ее создателям
> взападло сделать открытой, а запихать в облако просто лениво или дорого?
> Ну разве что... И что, вот ради этих пяти с половиной
> проприетарных пакетов нужно было городить огород?! Ну, блиин, кааампот!
Вам их насильно пихают, также как докер? Делают это ради удобства.
Посмотрите как в Mac OS X происходит установка приложений. (это не про brew)
| | |
| |
| 3.40, Andrey Mitrofanov (?), 10:18, 05/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну разве что... И что, вот ради этих пяти с половиной
>> проприетарных пакетов нужно было городить огород?! Ну, блиин, кааампот!
> Вам их насильно пихают, также как докер? Делают это ради удобства.
> Посмотрите как в Mac OS X происходит установка приложений. (это не про
> brew)
Очень правильная аналогия. Бандлить проприертарный ш%т -- решает.
"Especially elegant from an end-user perspective are Mac OS’s application bundles, which are directory trees containing all files belonging to an application. Generally, such bundles are self-contained, except for operating system component dependencies. Contrary to typical Windows applications, they do not have other environment dependencies such as registry settings. This means that bundles can be copied or moved around in the file system arbitrarily. For instance, the whole of Microsoft Office X on Mac OS X can be copied between machines by dragging it from one disk to another. Again, the limitation of this approach is that it falls apart when components have dependencies on each other. That is, the bundle approach works only for “top level” components, i.e., end-user applications[*4].
---
[*4] For instance, the management of Mac OS X’s BSD-based Unix foundations is a complete mess, which has prompted the development of tools such as Fink [138], which is based on Debian’s APT system [,,,]" ++p.12 https://nixos.org/~eelco/pubs/phd-thesis.pdf
| | |
|
|
|
