The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск системной библиотеки Glibc 2.29

01.02.2019 10:13

После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.29, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В состав нового выпуска включены исправления от 55 разработчиков.

Из реализованных в Glibc 2.29 улучшений можно отметить:

  • Добавлена функция getcpu(), позволяющая получить сведения о используемых в настоящий момент CPU и узлах NUMA;
  • Для разработчиков дистрибутивов предложены сборочные команды "make localedata" и "make install-locale-files", дающие возможность собрать и установить все имеющиеся локали в форме раздельного набора каталогов с файлами;
  • В математические функции exp, exp2, log, log2, pow, sinf, cosf, sincosf и tanf внесены неспецифичные для конкретных аппаратных платформ оптимизации;
  • Добавлена поддержка 32-разрядной процессорной архитектуры C-SKY (ABIv2), развиваемой одноимённой китайской компанией для создания SoC для различных потребительских устройств. Для работы требуется наличие binutils 2.32, gcc 9.0 и ядра Linux 4.20. Поддерживается два варианта ABI: "C-SKY ABIv2 soft-float little-endian" и "C-SKY ABIv2 hard-float little-endian";
  • Функция reallocarray() перенесена из набора "_BSD_SOURCE" (интерфейсы BSD, которые конфликтуют с POSIX), в набор "_DEFAULT_SOURCE" (интерфейсы, которые включены по умолчанию);
  • Добавлены функции posix_spawn_file_actions_addchdir_np и posix_spawn_file_actions_addfchdir_np, применяющие вызовы posix_spawn и posix_spawnp для запуска нового процесса в другом каталоге. Функции добавлены в секцию расширений GNU;
  • В функциях popen() и system() прекращён вызов обработчиков atfork, вызываемых до и после выполнения fork(). Данное поведение возможно нарушает стандарт POSIX, который в документации на pthread_atfork предписывает в обработчиках atfork обрабатывать состояние мьютекс после выполнения форка в многопоточных процессах, но вызовы popen и system не имеют прямого доступа к пользовательским мьютексам;
  • Механизм блокировок Transactional Lock Elision (позволяет увеличить масштабируемость блокировок на системах с поддержкой инструкции HTM) теперь включается для процессоров powercp64le, только если применяются новые версии ядра Linux, собранные в режиме PPC_FEATURE2_HTM_NOSC на процессорах с поддержкой HWCAP2 (т.е. если выполняется сброс транзакции перед входом в ядро). Ранее для совместимости со старыми ядрами, не сбрасывающими транзакции, Glibc производил данную операцию самостоятельно, что приводило к снижению производительности на новых ядрах;
  • В функции strftime изменено применяемое по умолчанию форматирование альтернативного представления года с учётом локали ("%Ey"), которое теперь включает как минимум две цифры (без отбрасывания нулей) по аналогии с "%y". Изменение заметно только для японских локалей, в которых регулярно встречаются годы меньше 10. Для возвращения старого поведения вместе с "%EY" следует использовать флаги '_' и '-', определённые как расширения GNU;


  • Пространство имён glibc.tune переименовано в glibc.cpu, а glibc.tune.cpu в glibc.cpu.name;
  • Типы элементов pr_uid и pr_gid в структуре elf_prpsinfo из sys/procfs.h приведены в соответствие с типами, используемыми в ядре Linux (размер структуры изменится только для архитектур MicroBlaze, MIPS (n64 ABI), Nios II и RISC-V). Аналогично к типам ядра приведены типы элементов pr_sigpend и pr_sighold структуры elf_prstatus и pr_flag из elf_prpsinfo, но данное изменение затрагивает только MIPS n32 ABI;
  • Устаревшие GNU-расширения форматирования в scanf ('%as', '%aS' и '%a[...]') теперь доступны только при сборке в режимах C89 и C++98 с флагом _GNU_SOURCE, так как они конфликтуют со спецификациями C99 и C++11. В соответствии с рекомендациями POSIX.1-2008 вместо '%as', '%aS' и'%a[...]' следует использовать '%ms', '%mS' и '%m[...]'. Для выявления применения устаревших расширений форматирования можно использовать режим "-Wformat" в GCC;
  • Для сборки Glibc теперь требуется наличие GCC 5 и Python 3.4 или более новые версии (для сборки программ, использующих Glibc, ограничения на версию GCC не накладываются);
  • Устранены уязвимости:
    • CVE-2018-19591 - устранена утечка файловых дескрипторов в if_nametoindex, которая могла привести к отказу в обслуживании из-за исчерпания доступных дескрипторов. Утечка проявляется при вызове функции getaddrinfo() с передачей специально оформленного имени хоста;
    • CVE-2019-6488 - устранено переполнение буфера при выполнении функции memcpy, проявляющиеся только в окружениях с архитектурой x32 (не путать с x86 IA-32). Проблема вызвана ошибкой в ассемблерной вставке, из-за которой параметр size_t записывается в нижние 32 бита 64-разрядного регистра без обнуления оставшихся верхних 32 бит;
    • CVE-2016-10739 - блокирована возможность разбора в функции getaddrinfo() адресов IPv4, содержащих произвольный набор символов в конце (например, "127.0.0.1\nTEST"). С одной стороны данное изменение нарушает сложившееся поведение и может привести к нарушению работы приложений, в которых осуществлялся разбор значений из /etc/hosts без разделения адресов. Но с другой стороны, указанная особенность приводила к уязвимостям в приложениях, которые используют getaddrinfo для проверки корректности адресов (getaddrinfo не возвращал ошибку и приложение считало адрес корректным, даже если после него указывались произвольные символы). В атаках данная особенность использовалась для подстановки HTTP-заголовков в приложения на базе Python-библиотеки httplib через передачу в поле адресов значений вида "127.0.0.1\r\nHttp-заголовок". В некоторых web-интерфейсах домашних маршрутизаторов в форме ping-проверки можно было запустить произвольные команды через передачу значений "127.0.0.1;cat /etc/passwd".


  1. Главная ссылка к новости (https://sourceware.org/ml/libc...)
  2. OpenNews: Выпуск системной библиотеки Glibc 2.28
  3. OpenNews: Конфликт между Ричардом Столлманом и командой разработчиков Glibc
  4. OpenNews: Выпуск системной библиотеки Glibc 2.27
  5. OpenNews: Уязвимость в Glibc, позволяющая поднять привилегии в системе
  6. OpenNews: Уязвимость в Glibc ld.so, позволяющая поднять свои привилегии в системе
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50068-glibc
Ключевые слова: glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (67) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Ilya Indigo (ok), 10:56, 01/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +19 +/
    > Для сборки Glibc теперь требуется наличие GCC 5 и Python 3.4...

    Для сборки glibc нужен python!?
    Дожили...

     
     
  • 2.4, leap42 (ok), 11:17, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А почему нет? Python при всех своих минусах - эффективный инструмент, который здорово повышает продуткивность.
     
     
  • 3.6, Аноним (6), 11:36, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В какой-то момент зацикливание побороть не смогут, и выяснить почему ошибки
     
  • 3.8, Аноним (8), 11:38, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Питон при всех своих скромных возможностях тут явный оверкилл.
     
  • 3.10, Ilya Indigo (ok), 11:47, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +21 +/
    > А почему нет?

    openSUSE прекрасно продемонстрировала, насколько это быстро и замечательно!
    openssl 1.1.1 и glibc 2.28 не могли быть приняты, из-за python. Python не мог быть принять из-за кучи его говноподелий, вроде python-tornado, который до сих пор не может работать с TLS 1.3, из-за которого не мог быть принят openssl 1.1.1, а также его говноподелия просто не могут работать с новой версией, пока их не исправят, а их сотни!
    Если с очередной версий python будут проблемы пр обновлении, то он может заморозить обновления нужных системных пакетов.
    А такое встречается всё чаще и чаще! Даже при обновлении gcc7 время заняло меньше, python 3.7 и его основные говноподелия чинили 7 месяцев, и судя по тому, что творится сейчас в Factory (285 ошибок, из которых более 200 по вине python), то полностью до сих пор не дочинили.

    Вот почему нет!

    > эффективный инструмент, который здорово...

    ... превращает любую ОС в помойку!

     
     
  • 4.24, grsec (ok), 15:06, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отчасти все верно, и c perl, ruby не лучше.
    Но тем не менее

    eselect python list
    Available Python interpreters, in order of preference:
      [1]   python2.7
      [2]   python3.5 (uninstalled)
      [3]   python3.4 (uninstalled)
      [4]   python3.6 (fallback)

    И python_targets_pythonX_X решает. Просто этим надо заниматься тем, кто делает дистрибутив.

     
     
  • 5.34, Crazy Alex (ok), 18:48, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, гента может себе подзволить вещи, которые в бинарях в принципе не лечатся. Тем более с use-флагами и слотами.
     
  • 5.38, nrndda (ok), 19:46, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    eselect python cleanup
     
  • 4.35, Crazy Alex (ok), 18:51, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А принять торнадо таким, какой он есть, без TLS 1.3 - что мешает? Или выкинуть его, в конце концов - что мешает? Что мешает не рваться за последней версией питона, и использовать рабочую? У других дистров этов вполне получается.
     
     
  • 5.61, Ilya Indigo (ok), 12:22, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А принять торнадо таким, какой он есть

    Python 3.6 Не работает с openSSL 1.1.1, для его поддержки нужен 3.7.
    > без TLS 1.3 - что мешает?

    Тем, что ради TLS 1.3 и нужен openSSL 1.1.1
    > Или выкинуть его, в конце концов - что мешает?

    Выкинуть нельзя, он нужен другим говноподелиям.
    Старый оставить нельзя, так как он не работает с Python 3.7.
    С торнадо пришлось откатить на старую версию, пропачить чтобы он работал с новым пихоном и отключить ему TLS 1.3 тесты.
    > Что мешает не рваться за последней версией питона, и использовать рабочую?

    Тем, что старая, как минимум, openSSL 1.1.1 не поддерживает, и с glibc 2.28 какие-то проблемы были.

     
     
  • 6.75, Crazy Alex (ok), 16:31, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На вид - совершенно стандратные дистропроблемы. Решение тоже стандартное - там остались на старой версии, здесь слегка пропатчили. Примерно для того дистрибутивы и нужны, чтобы такие штуки разруливать, и питоном они ни разу не ограничиваются. Я бы сказал, что если " glibc 2.28 какие-то проблемы" решаемы (скорее всего - да) - то самым логичным было бы остаться на питоне 3.6 достаточно долго, чтобы всё подтянулось.
     
  • 6.76, Gentoofan (?), 21:32, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Python 3.6 Не работает с openSSL 1.1.1, для его поддержки нужен 3.7.

    Забавно, а в генте вполне себе вот прямо сейчас у меня стоит Python-3.6.5 и openssl-1.1.1a.

     
     
  • 7.78, Ilya Indigo (ok), 10:52, 05/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А glibc какая?
     
  • 4.57, Аноним (57), 06:47, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В SRPM для Firefox для CentOS 5 применили хитрый трюк. В системе - GCC 4.1 и 4.4, надо 4.7. В системе - Python 2.4 и 2.6, надо 2.7. Разработчики просто положили арзивы с исходниками GCC и Python в SRPM-ку Firefox!

    Может с пакетом Glibc в openSUSE поступить так же? Костыль, но ведь решение же...

    Я так сделал в домашнем OBS-репозитории так сделал - тоже для Firefox, только для SLES 11. А в Ubuntu 12.04, например, GCC 4.6 - там создали зависимость gcc-mozilla

     
     
  • 5.62, Ilya Indigo (ok), 12:24, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А просто выкинуть пихон из glibc не проще?
    А ещё проще было его не впихивать его туда.
     
     
  • 6.65, пох (?), 13:22, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, потому что альтернативно-одаренное Оно поднимет писк, что его притесняют.

    "а других разработчиков у меня для вас нет"

     
  • 6.77, Gentoofan (?), 21:34, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы ещё не видели зависимости webkit-gtk, например - perl, python, ruby
     
  • 3.14, Аноним (14), 12:05, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А почему нет?

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

    Отдельно взятый python как интерпретатор - неплохой инструмент, но лишь до тех пор, пока не начнешь задаваться вопросом, а какой он версии. И пошло-поехало... Это совсем не sh!

     
  • 2.5, Аноним (-), 11:19, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > Для сборки glibc нужен python!?

    это конечно уродство..

     
     
  • 3.46, KonstantinB (ok), 04:47, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уж всяко меньшее уродство, чем m4.
     
     
  • 4.47, Аноним (47), 07:13, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Но всяко хуже с точки зрения деплоймента. А для glibc - это более критично.
     
  • 2.7, Аноним (8), 11:37, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тоже резануло. Они там теперь либц хипстерским ninja собирают? Makefile это недостаточно молодёжно?
     
     
  • 3.9, Аноним (8), 11:46, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Самопочин: посмотрел. Не прав. Они перловые и awk'шные генераторы/верификаторы на питонячьи переписали. Ладно, перл непопулярен (хотя код там был читаемый и понятный), но awk-то за что?
    Выглядит как изменения ради изменений. Смысла примерно 0.
     
     
  • 4.15, llolik (ok), 13:19, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Выглядит как изменения ради изменений. Смысла примерно 0.

    Ну привлечение молодняка/сторонних рук. Тоже цель. Хоть я и не против питона в разработке, но всёже соглашусь, что для системообразующих вещей, вроде glibc / gcc, это какой-то всё-таки перебор.

     
  • 4.26, FedeX (ok), 15:43, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так от перла-то хоть в итоге полностью избавились? или он все еще тоже нужен?
     
     
  • 5.52, псевдонимус (?), 15:13, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лучше выбросить питон и оставить перл. А наворотить на любом языке можно.
     
  • 4.27, Аноним (27), 16:50, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Выглядит как изменения ради изменений. Смысла примерно 0.

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

     
  • 4.36, Crazy Alex (ok), 18:53, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Например, за то, что по сравнению с awk perl - это образец читабельности? Может, просто не нашлось психов, готовых в этом копаться?
     
     
  • 5.39, Анонимчжан (?), 20:34, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    согласен перл ... ну это перл.))) там такого можно наворотить, что другой перловод может не разобраться)) проще переписать.
     
     
  • 6.54, Аноним (54), 15:23, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вы так говорите как-будто это нельзя сделать в любом другом Тьюринг-полном ЯП
     
     
  • 7.55, Анонимчжан (?), 16:09, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    знаю . в питоне тоже на одних спецсимволах в регулярках такое можно написать, что это будет смотреться как абракадабра. но перл все же в этом плане круче))
     
     
  • 8.58, Аноним (-), 10:57, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что perl круче во всем, т к представляет свободу разработчику Как испол... текст свёрнут, показать
     
  • 6.56, Crazy Alex (ok), 19:52, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я как бы о том, что awk страшнее. А перл... там всё плохо, если пытаться что-то средне-крупное пытаться на нём писать. Это я как перловод говорю :-) До тысячи строк - никаких проблем.
     
  • 4.59, пох (?), 11:32, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    с awk точно так же как и с перлом - модные-современные-sjw-псевдоразработчики не умеют ими пользоваться и учиться не хотят. Вместо того чтобы не допускать подобных скудоумков в проект - им создают условия. А потом вы удивляетесь, почему я ненавижу пихон и его апологетов и стараюсь использовать винду везде, где меня интересует результат, а не процесс.


     
     
  • 5.63, Ю.Т. (?), 13:13, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > с awk точно так же как и с перлом - модные-современные-sjw-псевдоразработчики не
    > умеют ими пользоваться и учиться не хотят. Вместо того чтобы не

    По справедливости, awk губила и продолжает губить ужасно невнятная документация (т.е. man-страница).
    В остальном - синтаксис наполовину си-шный, и оформление функций не страшнее, чем во многих прочих.
    Издавна делаю на нём малую автоматизацию, если нужно что-то посложнее шелла.

     
     
  • 6.66, пох (?), 13:27, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По справедливости, awk губила и продолжает губить ужасно невнятная документация (т.е.
    > man-страница).

    man страница g++ почему-то ни разу не помогает мне программировать на C++. И даже info не помогло.

    А книжку Кернигана и Пайка (и для совсем уж двинутых - http://shop.oreilly.com/product/9781565922259.do) таки да, читать немодно, немолодежно и неинтересно, и Camel Book тоже. Надо скорее-скорее понакопипастить в проект питоновского мусора со stackoverflow, чукчи ведь писатели.

    Вот зачем этим неосиляторам дали зеленый свет в столь критичный проект - спросите у Встолмана и прочих.

     
  • 3.16, pripolz (?), 13:33, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Makefile это недостаточно молодёжно?

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

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

    Так что, аутомэйк

     
     
  • 4.17, pripolz (?), 13:43, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    enjoy
    https://github.com/cisco/openh264/blob/master/Makefile
     
  • 4.18, анонн (?), 13:50, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > копиляцией под разные ОС

    А по факту, для поддержки непингвина все равно нужна туева хуча патчей.

    > Попробуй написать мэйкфайл, с десятком опций конфигурации, и кросс-копиляцией под разные ОС, архитектуры и т.д. А ещё лучше поотлаживать такой мэйкфайл, когда он что-нибудь натворит.
    > Имеется ввиду конечно же мэйкфайл сгенерированный каким-нибудь баш-скриптом, иначе придется все новые сишные файлы и хедеры добавлять туда в зависимости ручками,
    > иначе неправильно будет пересобираться. И не забыть про статические либы.

    Старые перд^W "бздуны" почему-то справились:
    https://github.com/freebsd/freebsd/blob/master/lib/libc/Makefile



    Pick the current architecture directory for libc. In general, this is
    # named MACHINE_CPUARCH, but some ABIs are different enough to require
    # their own libc, so allow a directory named MACHINE_ARCH to override this.

    .if exists(${LIBC_SRCTOP}/${MACHINE_ARCH})
    LIBC_ARCH=${MACHINE_ARCH}
    .else
    LIBC_ARCH=${MACHINE_CPUARCH}
    .endif


     
  • 4.48, Ю.Т. (?), 09:23, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Такие вещи делались 20 лет назад.
     
  • 4.60, пох (?), 11:40, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    стесняюсь спросить -в каком месте у вас унылоglibc под разные ос, и в каком таком особом месте _мэйкфайлы_ (а не одна-единственная переменная в них) зависят от архитектуры.

    единственное, для чего там используется по делу автомэйк - для указания --prefix, и еще пары ненужно-параметров, используемых либо при разработке, либо в необычных окружениях, либо неработающих. Остальное - героическая борьба с самим себе придуманными трудностями - как и в 95% случаев остальных использований gnu autotools.

    > Имеется ввиду конечно же мэйкфайл сгенерированный каким-нибудь баш-скриптом

    а, то есть вы просто не умеете пользоваться мэйком.

    если в модных-современных линуксных ядрах еще не доломали make dep, можете посмотреть, как это делают без всякого автомейка те, кто умеют.

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

    Сколько новых функциональных сишных файлов вы добавляете в проект? Дайте угадаю - обычно ноль, редко при больших изменениях - пару десятков. Это охрененно сложная работа - аккуратно написать в мэйкфайл что от чего зависит?

     
  • 4.64, Ю.Т. (?), 13:16, 03/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Makefile это недостаточно молодёжно?
    > Попробуй написать мэйкфайл, с десятком опций конфигурации, и кросс-копиляцией под разные

    Присоединяясь к предыдущему оратору, добавлю, что все эти многочисленные опции конфигурации очень-очень часто не стоят выеденного яйца, поскольку исходник рассчитан под одну-единственную (конфигурацию).

     
  • 3.41, Аноним (41), 21:48, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ниндзя - это сборочный бекенд. Без фронтенда в виде CMake бесполезен.
     
     
  • 4.69, Аноним (69), 00:49, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Чаще перед ниндзей всё-таки мезон ставят, хотя симейку всё равно что генерить, насколько я помню.
     
  • 2.19, псевдонимус (?), 13:53, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так рэдхэт всюду его пропихивала.
     
     
  • 3.23, Ilya Indigo (ok), 14:33, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    К сожалению, да! :-(
    RH с каждым годом превращается во всё большего паразита!
     
     
  • 4.28, MLP (?), 17:18, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В IBM же он превращается!
     
  • 2.31, R2J97 (?), 18:14, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Посмотри на Mesa, Gnome и его побочные проекты - все они собираются с помощью Meson. В ближайшее время он станет единственным инструментом для сборки этих проектов. Теперь без Python никуда.
     
     
  • 3.51, псевдонимус (?), 14:34, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Посмотри на Mesa, Gnome и его побочные проекты - все они собираются
    > с помощью Meson. В ближайшее время он станет единственным инструментом для
    > сборки этих проектов. Теперь без Python никуда.

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


     
  • 2.40, Аноним (41), 21:43, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    CMake предлагали?
     
  • 2.49, Аноним (69), 11:50, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Давно пора было. Python - современный и развивающийся язык, дружелюбный к разработчику и пользователю. awk и perl - write-only кошмар из восьмидесятых, где их и следует оставить.
     
     
  • 3.50, Ю.Т. (?), 12:40, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Давно пора было. Python - современный и развивающийся язык, дружелюбный к разработчику
    > и пользователю. awk и perl - write-only кошмар из восьмидесятых, где
    > их и следует оставить.

    Лет 15-20 назад примерно так же восторгались перлом, примерно с той же обоснованностью (т.е. её величество мода).
    И под каким пистолетом/веществом называют питон "языком, дружелюбным к пользователю" (???!!!)
    Это как это - дружелюбный байт-код? Хвостиком виляет, руки облизывает?

     
     
  • 4.67, Аноним (69), 00:39, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Двадцать лет назад слаще редьки ничего не едали, и после упражнений по обходу всех граблей шелла даже перл казался адекватным. Но время идёт, CS развивается с учётом ошибок и неудачных решений прошлого и люди к хорошему привыкают быстро, а на убогое легаси даже смотреть не хотят.
     
     
  • 5.70, Ю.Т. (?), 09:20, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Двадцать лет назад слаще редьки ничего не едали, и после упражнений по
    > обходу всех граблей шелла даже перл казался адекватным. Но время идёт,

    Ну и сидит шелл как посажен, а уж перла с нами "нет", и питона, я так полагаю, скоро в том же смысле "не будет".

    > CS развивается с учётом ошибок и неудачных решений прошлого и люди

    CS по факту не наука, а техника. Соответственно, объём "учёта" прошлого" лишь чуть менее, чем полностью, предопределён конъюнктурой.

    Погоня за самыми "хорошими" инструментами не имеет конца, правда?

     
  • 3.53, псевдонимус (?), 15:19, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Давно пора было. Python - древний и убогий  язык для ничего, дружелюбный к кодеру пожиратель памяти и кошмар для пользователя.

    Починил.

    Ах да! Питон не тормо...не ест память как не в себя!

     
     
  • 4.68, Аноним (69), 00:47, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно пример недревних и неубогих с вашей точки зрения языков программирования? Спасибо.
     
     
  • 5.80, псевдонимус (?), 02:12, 10/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно пример недревних и неубогих с вашей точки зрения языков программирования? Спасибо.

    Tcl  lua


     

  • 1.12, немезидеЦ (?), 11:57, 01/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > архитектурой x32

    Так ведь на эту архитектуру - забили?

     
     
  • 2.21, Аноним (21), 13:59, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы забить на архитектуру, надо чтобы она хотя бы была.
     
     
  • 3.29, Анонимчжан (?), 17:32, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    он не понял разницу между физической архитектурой 32 бит и программной реализацией x32. ну это нормально.
     

  • 1.25, Георгий (??), 15:16, 01/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Musl лучше.
     
     
  • 2.37, Аноним (37), 19:46, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тем, что тормознее и поддерживает меньше фич?
     
  • 2.42, Аноним (42), 22:07, 01/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Musl меньше.
     
  • 2.44, Cloudflare (?), 02:39, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На продакшене в любом случае только glibc
     
     
  • 3.74, Аноним (74), 16:09, 04/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В облаках всех теснит Alpine. На musl и без systemd.
     
  • 2.45, Анонимчжан (?), 02:45, 02/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    поскольку musl не обкатана так как glibc её редко кто отважится брать в оборот. так как менее предсказуемо.
     
     
  • 3.79, Аноним (-), 12:25, 06/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >поскольку musl не обкатана так как glibc её редко кто отважится брать в оборот. так как менее предсказуемо.

    Void Linux использует musl. Из тех кто редко отваживается - ты один.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру