| 1.1, Фуррь (ok), 10:14, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хм, интересно, будет ли прирост быстродействия на моём нетбуке, если перекатиться на это с glibc?
| | |
| |
| |
| 3.5, Игорь (??), 11:34, 20/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
нашли кого слушать
а ниче что это данные многолетней давности ?
да и сравнение некорректно, т.к. либы собраны
с разной опцией производительности
glibc -O2, а остальные -O0
| | |
| |
| 4.23, Аноним (-), 16:10, 20/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
У musl простой код и малое потребление ресурсов. Но это не способствует рекордной производительности. Хотя-бы по причине того что бывает speed vs memory tradeoff.
| | |
| |
| 5.34, Аноним (-), 20:22, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> У musl простой код
Посмотрим, сколько еще дыр найдется в этом простом коде.
| | |
|
|
|
| 2.7, anonimus (?), 12:19, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Не то спрашиваете. Нужно спрашивать, а можно ли нетбук перекатить на это вообще.
Но вообще да, конечно будет. Потому что нетбук будет не занят. Потому что ни че не будет работать.
| | |
| |
| |
| |
| 5.48, Аноним (-), 11:20, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
https://wiki.gentoo.org/wiki/Project:Hardened_musl
> Unlike the situation with uClibc, where pretty much every package in the Gentoo portage tree "just builds," musl's adherence to standards means that many packages which deviate from those standards, primarily POSIX, need some patching.
Новые библиотеки игнорируют сложившиеся ошибочные практики. Это их сильно упрощает, но перекладывает на мэйнтэйнеров работу, которую обычно автоматически делает glibc. В долгосрочной перспективе так, конечно, правильнее.
| | |
|
|
|
|
| |
| 2.8, Иван (??), 12:27, 20/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может выполнить произвольный код на моём роутере?
Веселуха, чо.
| | |
| |
| 3.13, Аноним (-), 12:47, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может
> выполнить произвольный код на моём роутере?
Теоретически может. На практике это пока не доказано. Но да, обновляться надо.
| | |
| 3.44, twilight (ok), 07:54, 21/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Я правильно понимаю, что, если LEDE использует Musl, значит, мой провайдер может выполнить произвольный код на моём роутере?
>
> Веселуха, чо.
Вы так говорите, как будто это что-то плохое.
| | |
|
| 2.11, Аноним (-), 12:40, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Предыдущие два фикса вышли оперативно. Но при такой тенденции им придётся каждую неделю фиксы выпускать.
| | |
| |
| |
| 4.33, Аноним (-), 20:20, 20/10/2017 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> Они и так очень часто релизятся.
Надо бы им перейти на хромовскую систему непрерывной нумерации. Потому что xx.yy.zz.aa, крутящиеся как в одометре - это трешЪ и угарЪ.
| | |
|
|
|
| 1.6, Аноним (-), 12:15, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чото она за последнее время два раза прилезла в обновлениях, а новость только одна. Наверное уязвимость только в одном обновлении исправляли.
| | |
| |
| 2.10, Аноноим (?), 12:32, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Обычно второе обновление - это regression fix, когда в первом дыру закрыли так, что софтина начала чудить.
| | |
|
| 1.9, Аноноим (?), 12:31, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> В новой версии устранена уязвимость (CVE-2017-15650) в коде разбора ответов от DNS-сервера, которая может потенциально привести в выполнению кода при использовании функции getaddrinfo()
Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у него беззастенчиво таскает.
| | |
| |
| 2.12, Аноним (-), 12:45, 20/10/2017 [^] [^^] [^^^] [ответить]
| +6 +/– |
Этого ашаурка любой недостаточно флегматичный человек ненавидит, а дыра небось из восьмидесятых кочует.
| | |
| |
| 3.18, Аноним (-), 14:08, 20/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Этого ашаурка любой недостаточно флегматичный человек ненавидит
С годами это обычно проходит. После восемнадцатого-двадцатого дня рождения уже как-то пофиг.
> а дыра небось из восьмидесятых кочует
Но ведь musl - это инновационная, не имеющая аналогов, полностью написанная с нуля библиотека. Какие там дыры из восьмидесятых?
Или Фелкер таки копипастил не глядя из glibc?
| | |
| 3.20, Stax (ok), 14:53, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
 .. но в данном случае ситуация иная - Рич Фелкер вообще очень много чего ненавидит, в частности практически любые фичи/удобства, существующие ценой хотя бы крошечной потери производительности - даже там, где здравый смысл говорит о том, что кроме железа 10-летней давности разницы в производительности нет, а фича нужна всем. Также любые усложнения - даже если они нужны для последующих доработок - ненавидит с маниакальной педантичностью. В общем, скорее всего он половину из того, что использует 90% пользователей линукс ненавидит :)
| | |
| |
| 4.21, Аноним (-), 15:35, 20/10/2017 [^] [^^] [^^^] [ответить]
| –12 +/– |
Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов в критике системды - что системда не умеет reexec на лету.
Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу про systemctl daemon-reexec даже мой хомяк может найти.
| | |
| |
| 5.24, Onanon (?), 16:25, 20/10/2017 [^] [^^] [^^^] [ответить]
| +7 +/– |
> Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов
> в критике системды - что системда не умеет reexec на лету.
> Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу
> про systemctl daemon-reexec даже мой хомяк может найти.
Цитата:
"With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted. This could perhaps be used to switch to a new version without rebooting. Various programs already use this technique, such as the IRC client irssi which lets you /upgrade without dropping any connections. Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic)."
(http://ewontfix.com/14/)
Кажется, про daemon-reexec он в курсе, это просто ты читать не умеешь.
| | |
| |
| 6.31, Аноним (-), 20:16, 20/10/2017 [^] [^^] [^^^] [ответить]
| –6 +/– |
Это он уже потом жoпкой вилять начал.
Сначала было "sysvinit может reexec, а systemd нет, и поэтому он отcтой".
| | |
| |
| 7.38, Onanon (?), 22:01, 20/10/2017 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Это он уже потом жoпкой вилять начал.
> Сначала было "sysvinit может reexec, а systemd нет, и поэтому он отcтой".
Где он такое писал? Можно ссылку? В мэиллистах busybox, из которых родился его пост, на ewontfix, на который я сослался, ничего такого нет.
Или ты про это:
"Inability to upgrade all the functionality that's been moved into
systemd without rebooting, due to the inability to kill and restart
pid #1."?
(http://lists.busybox.net/pipermail/busybox/2014-February/080405.html цитата не полная)
Если прочитать трэд дальше, видно, что речь о том, что нельзя НАДЁЖНО и ГАРАНТИРОВАННО обновить systemd, ибо есть много причин, по которым reexec может закончиться провалом, что приведёт к падению init и kernel panic. А не о том, что он утверждает, что systemd не умеет reexec в принципе.
Чтобы он топил за sysvinit я также не видел.
В посте на ewontfix он приводит пример идеального init в его понимании, и только.
Суть его претензий к systemd в том, что куча лишнего засунуто в PID 1, что черевато. Как я понимаю его подход, он предлагает делать init максимально простым, статически слинкованный бинарником, который нет даже необходимости обновлять когда либо, а все остальные fancy-возможности делать сбоку от PID 1, чтобы он никогда не упал.
В BSD системах (по крайней мере в FreeBSD и OpenBSD) init - это как раз статически слинкованный бинарник. Аналогичное, ЕМНИП, в клонах daemontools и/или runit (могу врать, давно на них не смотрел).
Это пример адекватного подхода.
Засовывать всё в PID 1, ошибка в котором грозит крахом системы - пример неадекватного.
Всё просто, не?
| | |
|
|
| 5.27, Аноним (-), 16:44, 20/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Меня больше впечатлила его техническая безграмотность. Например, один из главных его аргументов
> в критике системды - что системда не умеет reexec на лету.
> Чувак не удосужился даже минимально погуглить, не то что ман почитать. Инфу
> про systemctl daemon-reexec даже мой хомяк может найти.
ашаурок не осилил читать логи и написал жорналдэ, это гораздо круче
| | |
| |
| 6.32, Аноним (-), 20:18, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> ашаурок не осилил читать логи и написал жорналдэ, это гораздо круче
Разработчики Ъ юниксов (Solaris/HP-UX/AIX) придумали бинарные логи задолго до него.
| | |
| |
| 7.45, Аноним (-), 08:45, 21/10/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Знаю, и потому очень сильно озабочен грядущей смертью обычного мейснтримного линукса. Слава таким парням, как разработчики musl и openrc.
| | |
|
|
|
| 4.22, Аноним (-), 15:37, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> .. но в данном случае ситуация иная - Рич Фелкер вообще очень
> много чего ненавидит, в частности практически любые фичи/удобства, существующие ценой
> хотя бы крошечной потери производительности - даже там, где здравый смысл
> говорит о том, что кроме железа 10-летней давности разницы в производительности
> нет, а фича нужна всем. Также любые усложнения - даже если
> они нужны для последующих доработок - ненавидит с маниакальной педантичностью. В
> общем, скорее всего он половину из того, что использует 90% пользователей
> линукс ненавидит :)
А можно какие-то примеры публичных высказываний Рича про удобства/производительность?
| | |
| |
| 5.29, Stax (ok), 18:27, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Можно погуглить рассылки mplayer где-нибудь 10-15 давности, он много кода там ревьюил и комментировал.
| | |
| |
| 6.42, Аноним (-), 01:22, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Можно погуглить рассылки mplayer где-нибудь 10-15 давности, он много кода там ревьюил
> и комментировал.
Так почему бы не погуглить, если можно?
Ты, в отличие от меня, хотя бы примерно знаешь, что и где искать.
А то ведь хорошо получается, назвал человека ретроградом, а пруфов нема.
| | |
| |
| 7.43, Stax (ok), 04:38, 21/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Нет, более детально выискивать пруфы я не собираюсь - писал он (в mplayer-dev) в то время очень много, немало и по делу (собственно, он был один из разработчиков), но реакции, как я описал проявлялись тут и там достаточно ярко. Но в массе постов выискивать их я не хочу, не хотите - не верьте )
Я, строго говоря, не скажу прямо так уж про ретроградство. Просто есть такие люди, которые в описаниях любых технологий и разработок заявляют, что мол на их втором пеньке в кладовке с 256 мегами памяти это не нормально заработает, поэтому разработчики должны удавиться и научиться программировать и вообще писать все на асме, а потом уже в люди лезть и какие-то разработки миру показывать. Вот у него подобные проявления были, что - в отличие от просто троллей в интернете - необычно смотрелось на фоне того, что он сам разработчик и код пишет и свои вещи знает вроде бы хорошо. Но готов отвергнуть любую, сколько-либо желанную фичу из-за неидеальной реализации - как в плане скорости, так и (например) объема кода. Glibc, кстати, он в первую очередь за последнее не терпит, и по фигу, насколько там универсальные и полные реализации - кода много, значит априори плохо и надо переписать. Ну да, много. Ну да, плохо. Но обычно это менее важно, чем полнота и фичастость реализации. А для него - нет, фичастость для пользователей менее важна, чем идеальность кода.
| | |
|
|
|
| 4.25, Аноним (-), 16:43, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> кроме железа 10-летней давности разницы в производительности нет
Ты про какое железо сейчас, про роутеры?
| | |
|
|
| 2.14, Аноним (-), 12:52, 20/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у
> него беззастенчиво таскает.
Шта? Поттеринг-то тут каким боком?
| | |
| |
| 3.15, Andrey Mitrofanov (?), 12:54, 20/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Что характерно, автор Musl Рич Фелкер люто ненавидит Поттеринга, однако дыры у
>> него беззастенчиво таскает.
> Шта? Поттеринг-то тут каким боком?
Он теперь Главнюк по DNS-ам. BIND фсйо.
| | |
| |
| 4.19, Аноним (-), 14:09, 20/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Он теперь Главнюк по DNS-ам. BIND фсйо.
BIND еще поставить надо. А resolved/musl обычно идет из коробки (на разных системах конечно, но все же).
| | |
| 4.55, Аноним (-), 17:18, 21/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Шта? Поттеринг-то тут каким боком?
> Он теперь Главнюк по DNS-ам. BIND фсйо.
А это слово, точно и емко характеризующее Горшечника, точно с 'л' пишется?
| | |
|
|
|
| 1.30, Васян (?), 19:36, 20/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется, то меньше памяти занимают программы и быстрее работают?
Извините за глупый может вопрос.
| | |
| |
| 2.35, Аноним (-), 20:24, 20/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется,
> то меньше памяти занимают программы
В некоторых случаях действительно могут занимать меньше места. Но абсолютное большинство программ, помимо libc, используют и другие библиотеки, так что на практике выигрыш может быть незаметен.
> и быстрее работают?
Это вряд ли. Обычно либо меньше памяти, либо быстрее работать.
| | |
| |
| 3.36, Аноним (-), 21:24, 20/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> В некоторых случаях действительно могут занимать меньше места. Но абсолютное большинство программ, помимо libc, используют и другие библиотеки, так что на практике выигрыш может быть незаметен.
На самом деле абсолютно все библиотеки в таком случае прийдётся линковать с musl. Поэтому выйгрыш может быть значительный. В противном случае будет статическая линковка.
> Это вряд ли. Обычно либо меньше памяти, либо быстрее работать.
Не забывайте про буфер TLB. Чем больше памяти используется, тем чаще будут попадания мимо кеша TLB, тем меньше будет производительность. Скорее всего частично по этой причине продукты, написанные на java очень медленно работают по сравнению с аналогами на Си или даже C++.
| | |
| |
| 4.37, Аноним (-), 21:42, 20/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> На самом деле абсолютно все библиотеки в таком случае прийдётся линковать с musl. Поэтому выйгрыш может быть значительный.
Во-первых, "вы*и*грыш" и "придётся". Во-вторых, нет никакой разницы, с какой libc слинкована библиотека, сама-то она столько же памяти откушает (в пределах погрешности).
> В противном случае будет статическая линковка.
В противном чему случае? И почему она непременно будет?
| | |
| |
| 5.47, Аноним (-), 11:06, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> В противном чему случае? И почему она непременно будет?
Если Вы захотите в дистрибутиве, где используется одна libc-библиотека использовать другую libc-библиотеку. И то, будут большие проблемы, если вы попытаетесь использовать стандартные библиотеки дистрибутива.
| | |
| |
| 6.51, Аноним (-), 13:26, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю, где ты нашёл какие-то проблемы.
$ ldd hello_glibc
linux-vdso.so.1 (0x00007ffe5cbbc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf069ba000)
/lib64/ld-linux-x86-64.so.2 (0x000055e8aa317000)
$ ldd hello_musl
./hello_musl: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
$ musl-ldd hello_musl
/lib/ld-musl-x86_64.so.1 (0x5560ca667000)
libc.so => /lib/ld-musl-x86_64.so.1 (0x5560ca667000)
$ ./hello_glibc
hi!
$ ./hello_musl
hi!
$
| | |
| |
| 7.53, Аноним (-), 15:21, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
И? Я не вижу использования какой-либо библиотеки, зависимой от libc у Вас в hello_musl. Hello World на musl и я могу написать, тут проблем никаких не будет.
| | |
| |
| 8.58, Аноним (-), 23:43, 21/10/2017 [^] [^^] [^^^] [ответить] | +/– | Библиотеки, разумеется, тоже надо будет пересобрать А видеть надо было не их ис... текст свёрнут, показать | | |
| |
| 9.61, Аноним (-), 11:41, 22/10/2017 [^] [^^] [^^^] [ответить] | +/– | Ага, а теперь подумаем дальше Предположим Вам требуется фреймворк какой-то, ну ... текст свёрнут, показать | | |
|
|
|
|
|
| 4.39, asdasdasd (?), 23:07, 20/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Только вот в той-же libc есть математическая библиотека, где используется векторизация, SSE, AVX и прочее и прочее. Так вот, если делать так, чтоб максимально меньше памяти занимало, то все это идет лесом.
| | |
| |
| 5.40, asdasdasd (?), 23:08, 20/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Только вот в той-же libc есть математическая библиотека, где используется векторизация,
> SSE, AVX и прочее и прочее. Так вот, если делать так,
> чтоб максимально меньше памяти занимало, то все это идет лесом.
А ну еще выравнивание памяти сильно память отъедает, только вот в скорости выигрывает. Оптимизации под конвеер (пустые nop'ы все дела) тоже память не экономят.
| | |
| |
| 6.46, Zarat (ok), 11:05, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > А ну еще выравнивание памяти сильно память отъедает, только вот в скорости
> выигрывает. Оптимизации под конвеер (пустые nop'ы все дела) тоже память не
> экономят.
Ну есть мнение, что выравнивание за счет увеличения памяти, на архитектурах с внешним CISC-ом и внутренним RISC-ом (практически все современные i386 x86-64), в скорости не выигрывают (за исключением некоторого небольшого подмножества случаем). И выравнивать - это просто дань традиции и потому, что в gcc не поменяны настройки по умолчанию для режимов оптимизации в соответствии с вовременными реалиями
| | |
|
|
|
|
| 2.41, angra (ok), 01:09, 21/10/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Друзья, а подскажите пожалуйста, с этой либой если вместо glibc всё линкуется,
> то меньше памяти занимают программы и быстрее работают?
В случае _статической_ линковки занимают меньше места, работают в среднем чуть медленнее или в редких случаях могут не работать вовсе. Однако сравнение не совсем корректно, так как статическая линковка с glibc является проблемой, ряд функций из нее требуют наличия отдельно установленной glibc той же версии в системе. Так что дело не столько в меньшем размере, сколько вообще в наличии возможности полноценной статической линковки.
Основное предназначение musl это контейнеры и embed. Использовать ее для "улучшения" полноценного десктопа удел условного "школоло"
| | |
| |
| 3.49, Аноним (-), 11:26, 21/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы, наверное, ошиблись, - занимают больше места. Потому как вероятность, что другой такой библиотеки (в зависимостях установленного ПО) не будет в дистрибутиве - нулевая.
| | |
| |
| 4.50, angra (ok), 12:58, 21/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Еще раз для особо одаренных. Оно не для замены glibc в ваших дистрах, оно совсем для другого, ключевые слова(статическая линковка, контейнеры, embed) можешь погуглить, но если не поймешь, то спрашивай, объясню с примерами.
| | |
| |
| 5.54, Аноним (-), 15:27, 21/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Еще раз для особо одаренных. Оно не для замены glibc в ваших
> дистрах, оно совсем для другого, ключевые слова(статическая линковка, контейнеры, embed)
> можешь погуглить, но если не поймешь, то спрашивай, объясню с примерами.
Я Вам не про замену, а про статическую линковку говорил. Для каждого приложения статически слинкованная libc приведёт к огромному размеру установленного ПО.
А вот Вам про замену в наших дистрибутивах:
https://alpinelinux.org/posts/Alpine-Linux-has-switched-to-musl-libc.html
https://ru.wikipedia.org/wiki/Alpine_Linux
Я использую Docker, поэтому использую как минимум один дистрибутив, который уже перешёл на musl.
| | |
| |
| 6.57, angra (ok), 23:26, 21/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Я Вам не про замену, а про статическую линковку говорил. Для каждого приложения статически слинкованная libc приведёт к огромному размеру установленного ПО.
Спасибо, кэп, я же за двадцать лет опыта программистом ни за что не догадался бы. А теперь напряги извилины и подумай, зачем всё-таки иногда используют статическую линковку.
> Я использую Docker, поэтому использую как минимум один дистрибутив, который уже перешёл на musl.
И как и большинство любителей докера неспособен смотреть в корень. Во-первых, в alpine по прежнему есть glibc, так как не все программы нормально работают с musl, о чем я говорил с самого начала. Во-вторых, причина малого размера контейнера alpine в первую очередь в busybox, а не в musl. Поставь туда весь набор софта из debootstrap и получишь совсем небольшую разницу. musl же экономит 7.4MB однократно на .so и целых 28KB на каждую программу.
Ну и отдельно отмечу, что я говорил про десктопные дистры, к коим alpine не относится. А относится он как раз к задаче контейнеров. Или ты не в курсе даже о том, что докер это одно из решений контейнеризации?
| | |
| |
| 7.59, Led (ok), 00:40, 22/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Во-первых, в alpine по прежнему есть glibc
Нет.
| | |
| |
| 8.60, angra (ok), 04:47, 22/10/2017 [^] [^^] [^^^] [ответить] | –4 +/– | Посмотрел, действительно уже нет Приходится людям с какой-нибудь из реп на гитх... текст свёрнут, показать | | |
| |
| 9.63, Аноним (-), 12:00, 22/10/2017 [^] [^^] [^^^] [ответить] | +/– | Зачем Посмотрел, вроде поддерживаются GNU-расширения языка Поэтому никто даже ... текст свёрнут, показать | | |
|
|
| 7.62, Аноним (-), 11:57, 22/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
У Вас может быть и есть 20 лет опыта, но я не вижу профессионализма. То, что Вы не можете признавать свои ошибки и спокойно это воспринимать (попытки доказать, что всё равно были правы, но Вам неправильно поняли), а также не задаёте вопросов в духе "имелось в виду это, либо это?" и "почему?". Это уже показатель, что у Вас merge request'ы не используются. А дальше логические цепочки доведут и до качества кода. Прав я?
| | |
| |
| 8.67, angra (ok), 09:38, 23/10/2017 [^] [^^] [^^^] [ответить] | +/– | И где же у меня ошибка, кроме как с наличием glibc в современном alpine, которую... текст свёрнут, показать | | |
| |
| 9.70, Аноним (-), 21:15, 23/10/2017 [^] [^^] [^^^] [ответить] | +/– | Мне было интереснее узнать ответ на свой последний вопрос Насчёт merge request ... большой текст свёрнут, показать | | |
| |
| 10.72, angra (ok), 03:50, 24/10/2017 [^] [^^] [^^^] [ответить] | +/– | Молодец, следуешь правилам демагога, когда нечего ответить по сути, надо либо пе... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
