Разработчики openSUSE сообщили (https://kubic.opensuse.org/blog/2019-01-30-kubiconaarch64/) об обеспечении поддержки архитектуры AArch64 в инструментарии Kubic (https://kubic.opensuse.org/), позволяющем развернуть и поддерживать кластер для запуска приложений в изолированных контейнерах. Для загрузки предлагается (http://download.opensuse.org/ports/aarch64/tumbleweed/iso/) iso-образ (1.1 Гб), предоставляющие готовое решение для создания систем CaaS (Container as a Service) на серверных платах с процессорами на базе архитектуры AArch64. Решение собирается из единой кодовой базы (https://github.com/kubic-project), также используемой для формирования сборок (http://download.opensuse.org/tumbleweed/iso/) для архитектуры x86_64.
Из ограничений редакции для AArch64 отмечается недоступность некоторых пакетов, специфичных для систем x86_64, например, не поддерживается kubernetes-dashboard. Базовый загрузочный образ сформирован для 64-разрядных ARM-плат с поддержкой UEFI c достаточно большим объёмом ОЗУ (более 1 Гб), таких как Overdrive 1000 (https://en.opensuse.org/HCL:Overdrive_1000), D05 (https://en.opensuse.org/HCL:D05) и ThunderX2 (https://en.opensuse.org/HCL:ThunderX2).
Для плат без UEFI, таких как Pine64 и Raspberry Pi 3, подготовлен (https://en.opensuse.org/Kubic:Installation#Images_for_non-UE...) отдельный образ (https://download.opensuse.org/repositories/devel:/kubic:/ima.../) на базе MicroOS (https://en.opensuse.org/Kubic:MicroOS) (урезанный дистрибутива с атомарной установкой обновлений, настройкой через cloud-init, доступным только для чтения корневым разделом с Btrfs, runtime Podman/CRI-O и Docker). Возможна огранизация автоматизированной установки на большое число машин с использованием типового профиля AutoYaST или загрузка узлов по сети (PXE/tftpboot).
Окружение Kubic построено на базе дистрибутива openSUSE (репозиторий Tumbleweed), инструментария Docker, платформы оркестровки кластера изолированных контейнеров Kubernetes и системы централизованного управления конфигурацией Salt. Для управления кластером предлагается интерфейс Velum (https://github.com/kubic-project/velum), который позволяет в один клик развернуть кластер на базе Kubernetes и организовать управление им, в том числе добавлять и удалять узлы, осуществлять мониторинг сбоев, определять политики установки обновлений. Запуск Kubernetes на узлах осуществляется в виртуальных машинах, развёрнутых на базе libvirt или OpenStack. Поддерживается запуск контейнеров, подготовленных при помощи инструментария Docker. Образы контейнеров распространяются в виде RPM-пакетов.URL: https://kubic.opensuse.org/blog/2019-01-30-kubiconaarch64/
Новость: https://www.opennet.dev/opennews/art.shtml?num=50062
Хорошая новость :-) Я думал, что я один слежу за этим. Но оказывается, что кому-то из тех, кто пишет новости, эта тема тоже интересна
> контейнеров распространяются в виде RPM-пакетовВсе правильно, деб не нужен
- Вы что-то сказали, сэр?
- А настоящему джентльмену всегда есть что сказать !
- Ну что, разомнёмся?
- Ну что ж, пожалуй...
(с)
Впрочем, как и всё остальное с systemd.
Декларативное описание юнитов, параллелизация загрузки на pure C...
Нет, давайте все выкинем и вернем всё взад, калякать портянки на тормозном однопоточном интерпретируемом языке
> Декларативное описание юнитов, параллелизация загрузки на pure Cа теперь попробуйте объяснить, нахрена это нужно.
> Нет, давайте все выкинем и вернем всё взад
да, вместе с любителями модных баззвордов и неосиляторами тривиальных скриптов.
Которые, разумеется, и в си коде ничего поправить не смогут, но тут они неодиноки - в ЭТОМ коде поправить ничего не может в общем-то уже никто.
> в си коде ничего поправить не смогутПо себе не судят, мой юный любитель жава-скрипта, баш-скрипта и прочих скриптов на выброс.
Ну исправишь ты код в системдне.Прилетит обновление и всё( А если куплена поддержка там вообще трогать ничего нельзя, пожилой любитель лёнятварений.
да не исправит ничего эта болтушка, повторяющая как дятел набор заклинаний "декларативное описание", "параллелизация", "портянки" (как вижу - значит это му...к)любой человек, на самом деле попытавшийся что-то по мелочи исправить в этом куске дерьма, например, заменить безумные таймауты по умолчанию (и бесконечные в некоторых псевдо-юнитах которые юнитами не являются) из-за которых иногда шатдаун приходится делать ресетом ("зато у нас параллелизация") будет безумно рад его целиком выбросить даже не выкрашивая, потому что он уж точно умеет делать то что ему надо на баш-скриптах, и это занимает у него минуты, а не часы.
> на баш-скриптах, и это занимает у него минуты, а не часыПогоди-ка, меня тут горячо убеждали, что баш надо ОСИЛИТЬ. А тут получается, НЕОСИЛЯТОРАМИ выходят сами же баш-портянщики. Скрипткиддисы-электронщики-баш-портянщики не осиливают простейший синтаксис ини-файлов?
Скрипткиддисы-электронщики-баш-портянщики
> не осиливают простейший синтаксис ини-файлов?Ты прикидываешься? Системда делает то же, что и шелл-скрипты и горсть утилит но её налету не поправишь. При чём тут юнит-фэёлы, эти дурацкие крутилки торчащие из уродливой аморфной туши системды? Как ты на них сделаешь то, что не предусмотрел графоман горшочников? А никак.В том числе и для этого делалось системдно (какой-то сюр: графоман пишет "защиту от дурака").
> Как ты на них сделаешь то, что не предусмотрел графоман горшочников?Приведи пример, что у тебя там такое нестандартное, что 100500 настроек системды не хватило.
К счастью у меня его нет, а есть бсд-скрипты. А примеры невменяемой работы системды ты можешь найти на любом форуме. Последний раз я щупал его на дебиан 8. Мне было бы плевать, если бы к нему не прибивали программы.
ну то есть жалуешься на то, что системда тебе чего-то не дает (so called "нестандартное"), но когда тебя просят сказать, что же именно тебе там не хватает, уходишь в туман. Ожидаемо.Вообще, заметил, что "системда vs башпортянщики" - спор из разряда "эволюционизм vs креационизм". Если со стороны системдосников логика и последовательность, то башпортянщики в основном виляют жопой и бессистемно скакают с одной темы на другую.
Системдауны и есть креационисты, поэтому вокруг неё который год идёт непрекращающийся с-чь Конкретно у меня в восьмом дебиане она не могла выключить компьютер,причём иногда могла,а иногда нет.Рандомно.>со стороны системдосников логика и последовательность,
Где можно посмотреть? Покажи, пусть мне будет стыдно.
>то башпортянщики в основном виляют жопой и бессистемно скакают с одной темы на другую.
На этом сайте есть подборка с критикой системд. За конкретикой иди на форумы, даже ЛОР подойдёт.Свою проблему с ним я озвучил.
> Конкретно у меня в восьмом дебиане она не могла выключить компьютер,причём иногда могла,а иногда нет.РандомноА у меня в федоре такой проблемы нет. Изучай логи. Или это слишком сложно для нпм-лефтпад-башпортянщиков?
> На этом сайте есть подборка с критикой системд. За конкретикой иди на форумы
Ну в общем классический креационист. Ссылки на каких-то там "все большее число ученых отказываются от эволюционизма".
У меня нет Дебиана, потому что я его не использую с тех времён, потому что я понял что он рипнулся.
И федора со свежайшим го..софтом мне не впёрлась.>А у меня в федоре такой проблемы нет.
Ага, "УМВР".
>Ну в общем классический креационист.
Я вижу, что ты креационист.
>Декларативное описание юнитов, параллелизация загрузки на pure C...
Это вот это вот "логика и последовательность"?
Ну его после лени немного подзалатали, что он стал хоть как то работать. И пользовать системд вполне себе можно в девятке. в 8 да еще оставались проблемы. У меня он вообще тупо крашился.
> Ну в общем классический креационист. Ссылки на каких-то там "все большее число
> ученых отказываются от эволюционизма".Да нате, мне не жалко:
https://www.opennet.dev/openforum/vsluhforumID3/110746.html#21
...
Пункт первый - качество кода/архитектуры:
Перлы в коде, типа магических строк и прочего:
arg_header = strdup(option+7);
strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), «XXXXXX»);
if (path_is_absolute(option+15))
ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
...
это еще не задаваясь вопросом, зачем вообще понадобилось изобретать велосипед вместо использования того же re2/lemonparser. Ну или хотя бы, если уж так зудит NIH-синдром, почитать классику и сделать сц*ко _нормальный_ токенизатор и парсер (благо, там грамматика простейшая и простого recursive descent парсера должно хватить за глаза) , а не велосипедить что-то с strchr/strspn, распихивая все это действо по всему коду.
...
там еще есть интересный пунктик с проверками входных данных - они довольно бессистемны и дубли-"триплируются".
...второй пункт претензий - запихивание всего, чего можно:
https://www1.opennet.ru/opennews/art.shtml?num=41301
> В Systemd добавлен код для разбора формата JSON
> В дополнение к уже присутствующей поддержке формата XMLПро классику типа QR кодов и встроенного httpd скромно умолчим. Тот же ресольвер по фунциональности хромает на обе ноги, зато с дырами там все нормально https://www.openwall.com/lists/oss-security/2017/06/27/8
Третий:
https://lists.freedesktop.org/archives/systemd-devel/2016-Fe...
> * Most configurable timeouts in systemd now expect an argument of "infinity" to turn them off, instead of "0" as before.А чтобы жизнь медом не казалась
> To maintain backwards compatibility, "0" continues to turn off previously existing timeout settingsили
https://lwn.net/Articles/490413/
> you can still build it for usage outside of systemd systems, and we will support these builds
> officially. In fact, we will be supporting this for a long timeДа, лонг-тайм оказался периодом аж в два года.
Или очередной велосипедизм с элементами гвоздеприбивания колес:
https://lists.freedesktop.org/archives/systemd-devel/2015-Fe...
> When the user presses Ctrl-Alt-Del more than 7x within 2s an immediate reboot is triggered.
>Ну и "мытеперьвашновыйстандарт!":
https://github.com/systemd/systemd/issues/825#issuecomment-1...
>poettring:
> Long story short: "su" is really a broken concept. It will given you kind of a shell, and it's fine to use it for that, but it's not a full login, and shouldn't be mistaken for one.https://github.com/systemd/systemd/issues/5644
> tmpfiles: R! /dir/.* destroys root-
> poettering commented Mar 30, 2017
> I am not sure I'd consider this much of a problem. Yeah, it's a UNIX
> pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
>===========
Еще конкретики? Их есть у нас:
https://www.opennet.dev/openforum/vsluhforumID3/110746.html#82
https://github.com/systemd/systemd/blob/master/src/basic/mac...
> На 238 пушка просто: /* We override the glibc assert() here. */. Молодец, Леня!
> В макросе на 323 ошибка: не учитывается знак минуса для отрицательных чисел (а они, судя по комментарию
> для соседнего макроса на стр. 313-316, ожидаются).
> Опасный макрос на 333.
> Какой-то ад на строках 335-361.
>
> https://github.com/systemd/systemd/issues/5644
>> tmpfiles: R! /dir/.* destroys root
> -
>> poettering commented Mar 30, 2017
>> I am not sure I'd consider this much of a problem. Yeah, it's a UNIX
>> pitfall, but "rm -rf /foo/.*" will work the exact same way, no?Ахахаххахах! В десятку, блин! :D
И этот ламер разрабатывает системный менеджер, подумать только. А нас потом спрашивают "почему вы не хотите им пользоваться?" :D
>> https://github.com/systemd/systemd/issues/5644
>>> tmpfiles: R! /dir/.* destroys root
>> -
>>> poettering commented Mar 30, 2017
>>> I am not sure I'd consider this much of a problem. Yeah, it's a UNIX
>>> pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
> Ахахаххахах! В десятку, блин! :D
> И этот ламер разрабатывает системный менеджер, подумать только. А нас потом спрашивают
> "почему вы не хотите им пользоваться?" :DА он всегда действует так, будто до него ничего не существовало, а то что существовало было УГ, потому не опускается до чтения манов. Мания величия во всей красе.
Системд не виноват , виноваты пропитоеристы которые сделали третий питон и выше , как доказательство поставьте weston окружение и зайдите , сразу фантастика скорость повышается , а hdd диск перестаёт играть музыку сверчков , системд это лишь ключ зажигания , проблемы кроются в третьих питонах
Виноваты те, кто вообще сделал важные компоненты зависящими от пистон.
> ну то есть жалуешься на то, что системда тебе чего-то не дает (so called "нестандартное"), но когда тебя просят сказать, что же именно тебе там не хватает, уходишь в туман. Ожидаемо.Боюсь, что человеку просто лень привести пример, потому что за ними на самом-то деле далеко идти не надо. Конкретно в юнитах не хватает одной простой вещи: хуков. Вот самый первый пример, который в голову пришёл:
https://mirror.yandex.ru/debian/pool/main/d/dnsmasq/dnsmasq_...
На случай, если Вы не с дебом по жизни работаете, упрощу Вам задачу:
dpkg -x <file>.deb .
тебе привели пример, но твои слабенькие мозги не осилили дочитать сообщение даже до середины - сразу повели тебя писать что-то о чужом неосиляторстве.Я же говорю - как вижу "баш портянки" - автор м-к и не умеет ни баш, ни си, ничего. Читать и то не умеет. Умеет поискать в гугле "каким заклинанием в юнитфайле сделать зае..сь", не найдя - выбрасывает проблему как не стоящую решения и продолжает весело верещать что системда рулез, баш для лохов.
> псевдо-юнитах которые юнитами не являютсяТы видимо покопался в кишках этого у..программного продукта, можешь про эти недоюниты рассказать?
> Ты видимо покопался в кишках этого у..программного продуктая ногой попинал - там ад, трэш и п-ц, нет единого кода этого дерьма, оно ровным слоем по всем исходникам и обвешано уродливым взаимодействием с udev еще.
Плюнул и решил на него время не тратить. Просто внес в регламенты что перезагрузка системы может занимать до 20 минут и добавил чудо-юнит, намертво оверрайдящий оверрайд kern.sysrq обратно в 1 (потому что штатные механизмы макаки раз в неделю "улучшают"). Ну а чо, модное, стильное, молодежное, новый стандарт. К тому же пять из них инициализируется память энтерпрайзной железяки.
>нет единого кода этого дерьмаНу так это ожидаемо: они объявляли о слиянии кодовой базы с удавом и, вероятно, дбусом. Естественно сильно они их переделывать не стали, скрепили "портянками" на С.
>время не тратить. Просто внес в регламенты что перезагрузка системы может занимать до 20 минут и добавил чудо-юнит, намертво оверрайдящий оверрайд kern.sysrq обратно в 1 (потому что штатные механизмы макаки раз в неделю "улучшают").
-((...
>>нет единого кода этого дерьма
> Ну так это ожидаемо: они объявляли о слиянии кодовой базы с удавом
> и, вероятно, дбусом. Естественно сильно они их переделывать не стали, скрепили
> "портянками" на С.Ну дык, разумеется! Слияние-то было, само собой, не улучшения качества ради, а для взаимопроникновения кода: в целях обеспечения неразрывной связи с одним из основных компонентов любой linux-системы.
Так поцер давно перестал скрывать, что главная цель системды - "стандартизация" линукс.
Слушай, а у тебя в работе центось или прочие РХ-производные? Неужели и там на горячую улучшают?!
вокруг центоси и прочих редхатов у меня аутсорсеры прыгают, к тому же они виртуальные, там особо ломаться нечему, и в другую сторону тоже нечему - там жаба с томкэтом, если от системы ничего кроме загрузчика не требовать, она в общем как-то и будет работать, поэтому и вони от них не бывает. А улучшают там в другую сторону - cockpit, вот это вот все - то есть они реально настолько $@!лись, что действительно думают что энтерпрайз-системой будут управлять через уеб-интерфейс, причем вот через это недоразумение, а не какой-нибудь действительно работавший, хоть и с кучей проблем, сто лет назад webmin.А свой "корпоративный стандарт" бубунточка ("патамушта наши разработчики только ее и знают". На деле, понятен, ничего они не знают). Но я тебя уверяю, что если я ее щас выпилю и заменю редхатом - оный точно так же не загрузится без ручного пинка там где мультипас, а техподдержка заявит мне что "это неподдерживаемая конфигурация". Ну или может придется подождать 8.2 - а ведро 3.10 еще загрузится как-то, только это, понятно, временно, а вот эта вся помойка - она уже навсегда.
>cockpit,В печь. Нет, вот так: В ПЕЧЬ!!! 1000 окошек и 100000 кнопок не.... ну ты понял.
>А свой "корпоративный стандарт" бубунточка
А центосюшка сильно лучше? То же самое, только типа "от разработчиков" и пакетов меньше.
ЗЫ: интересно, почему в цисках и джуниперах до сих пор есть командная строка. Нужно этим дятлам сказать, что нужен кокпит и вообще без сраузера интернетов не бывает. Это тупик. Одноразовое железо, одноразовая ось, одноразовый специалист.
Ну а так, если всё как ты говоришь, то это очень грустно.
ЗЗЫ:Так начальство твоё там своими черепушками что-нибудь думает или тупо "а все так делают! Ы-Ы-Ы". Ты им сказку "О попе и работнике его Балде" прочитай, вдруг сработает.
> А центосюшка сильно лучше? То же самое, только типа "от разработчиков" искорее сильно хуже - напоминаю, эти деятели в версии 8 (!) наконец-то nginx осилили внести в штатный набор пакетов (ну, понятно, у центоси все то же только с опозданием на три месяца), а до того его из epel или еще там откуда ставили. И так у них все. Потому что у их типичного покупателя в вакууме - изнутри tomcat, а снаружи какой-нибудь big-ip/f5
> ЗЫ: интересно, почему в цисках и джуниперах до сих пор есть командная
> строка. Нужно этим дятлам сказать, что нужен кокпит и вообще безвредные пережитки прошлого, с ними борются.
кокпит у них уже есть, правда, у младших моделей в основном.А wlc какой-нибудь без гуя настраивать так себе удовольствие.
> ЗЗЫ:Так начальство твоё там своими черепушками что-нибудь думает или тупо "а все
> так делают! Ы-Ы-Ы". Ты им сказку "О попе и работнике егооно думает "у нас все работает, зачем что-то менять?"
Ну и меня вот наняли, чтоб дальше работало, отнюдь не за вареную полбу, тоже неплохо в общем получилось.
А я всех одинаково ненавижу, поэтому зачем выдергивать из под них привычную табуреточку.
Все что вы описали, уже было до этого в том-же InitNG, только оно никому не нужно было, а вот как начали все к systemd гвоздями прибивать так оно внезапно понадобилось! -_-
> однопоточном интерпретируемом языкеМолодёжь даже не в курсе основной фишки shell. Однопоточном, ага. Shell как раз и нужен для того, чтобы организовывать конвееры из параллельно запущенных задач, запускать пулы задач (см. xargs/parallel), чтобы всё оно работало в *несколько* потоков.
> давайте все выкинем и вернем всё взад
И-мен-но! Наш выбор -- Devuan.
Да там другая главная новость!
Не прошло и пол года (хотя может и прошло), они вчера python 3.7 наконец-то в Factory приняли, который блокировал принятие openssl 1.1.1 и glibc 2.28!А вы тут про какие-то кубики...
> Не прошло и пол года (хотя может и прошло) ...https://build.opensuse.org/package/view_file/openSUSE:Factor...
Thu Jun 28 10:42:15 UTC 2018 - mimi.vx@gmail.com- update to python 3.7.0
Не! Точняк 7 месяцев прошло!
это говорит как о востребованности модного пихона3.9 или сколько там он у вас, так и о востребованности не менее модных openглюкал1.1.1.1.1.1
Буквально в каждой теме ты называешь питон "пихоном" и хейтишь его, почему?
Потому что пишет на perl, очевидно же
Что мешает писать на обоих языках, или по крайней мере не ругать один из них?
бррр, нет! то есть когда-то давно, конечно, было дело, но это ж давно и по принуждению.Но вот разбираться в чужой писанине - знаешь, лучше бы она была на перле.
Питон же понятнее, там даже отступы обязательны
> Питон же понятнее, там даже отступы обязательныДа ладно …
https://ideone.com/wKZwIJ
https://ideone.com/9vJy2P
def letshavesomefun(_, __ = type({( )})): __ = type("""
.-=-. .--.
__ .' '. / " )
_ .' '. / .-. \ / .-'\
( \ / .-. \ / / \ \ / / ^
\ `-` / \ `-' / \ `-` /
jgs`-.-` '.____.' `.____.'""", (__,),
{'_'
:__.__dict__[
filter(lambda _: '_' not in _,sorted(__
.__dict__))[:
:-1].pop()]})( {( )} ); return [_
for _ in _ if _ not in __ and
not __._(_)]print letshavesomefun(
"hello world"
)
На Перловке или каком-то другом языке как будто нельзя так написать. Какие-нибудь конкретные претензии к питону может кто озвучить?
> На Перловке или каком-то другом языке как будто нельзя так написать."Нельзя написать" и "понятнее, там даже отступы обязательны" -- две большие разницы.
> Какие-нибудь конкретные претензии к питону может кто озвучить?
Так выше вон, отличная демонстрация костыльного синтаксиса:
{} - dict
{()} - set
_ - конкретное значение в зависимости от контекста, более упрощенный пример:
__ = [1,2]; _= range(10);[_ for _ in _ if _ not in __]
[0, 3, 4, 5, 6, 7, 8, 9]
subset = [1,2]; some_range = range(10);[x for x in some_range if x not in subset]
[0, 3, 4, 5, 6, 7, 8, 9]
lambda - умеет только выражения, хотя ЯП императивный, что [невозможность безкостыльно присвоить или изменить значение] частенько "доставляет". Т.е. передать "my_val = 3.14; for i in range(...) if i == my_val" в качестве анонимной функции не выйдет.Дефолтные значения в аргументах:
__ = type({( )})
"сохраняется" между вызовами.
демонстрирую:
>>> def f(x, y=list()):... y.append(x)
... print y
...
...
>>> f(1)[1]
>>> f(2)[1, 2]
>>> f(1,[])[1]
>>> f(1)[1, 2, 1]
Непонятно, нафига ввели синтаксис **kwdargs "def x(**myargs): "
когда оно по сути является словарем (который так же можно было передать)ну и всякие мелочи:
>>> class F(object):... def noself(): return "hello"
... def __init__(self):
... self.self = lambda: "world"
...
>>> F().self()'world'
>>> F().noself()Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: noself() takes no arguments (1 given)>>> 1, + 2,
(1, 2)
>>> (1,) + (2,)(1, 2)
>>> (1,) + 2,Traceback (most recent call last):
File "<input>", line 1, in <module>
(1,) + 2
"однородность" синтаксиса аж "изо всех щелей".При попытках использовать динамизм на всю (манкипатчинг) начинают вылезать особенности реализации:
>>> d={1:2,2:3}
>>> d.__getitem__ = lambda: "d"Traceback (most recent call last):
File "<input>", line 1, in <module>
d.__getitem__ = lambda: "d"
>>> int.__add__ = lambda: "d"Traceback (most recent call last):
File "<input>", line 1, in <module>
int.__add__ = lambda: "d"
Рад наконец-то встретить конструктивную критику. Однако же стоит ли отказываться от питона, и если да, то в пользу чего? Разве в других языках нет несовершенств?
> Рад наконец-то встретить конструктивную критику. Однако же стоит ли отказываться от питона,отказываться, если уже начал писать - наверное, нет, но и любить его особенно не за что.
а если писал не ты - то и выбора нет, приходится ковыряться в том, что уже понаписали. Если не повезет, это будет php.
с перлом в этом плане было, кстати, гораздо проще - если код - эта самая субстанция, и его проще выбросить чем пытаться починить, это было видно сразу, а совсем плохие проекты вообще не доживали до релиза.
> Рад наконец-то встретить конструктивную критику. Однако же стоит ли отказываться от питона, и если да, то в пользу чего? Разве в других языках нет несовершенств?Конечно же, в других языках тоже есть свои несовершенства. Но давайте будем честными: синтаксис -- это лишь малая толика. Даже с питоновским синтаксисом возможно работать. Вот что действительно важно при работе с языком, так это его библиотеки. А у питона с ними довольно паршиво. Да и за примерами далеко ходить не надо.
Вот Вы алгоритмы учили в институте? Надеюсь, что да. Ну так вот. Пожалуйста, попробуйте найти какой-нибудь элементарный само собой разумеющийся модуль, типа Stream. К чёрту даже всякие итераторы, счётчики и прочее. Пусть будут просто три обязательные операции: create-stream, get-next-element и null-checker. Нету? Надо же. А сколько лет языку.
Конечно, можно везде лепить генераторы. Но абстракция потока гораздо читабельнее, нежели синтаксис генераторов. Однако её нет. А если сообщество за столько лет не посчитало её необходимой, значит любой код, написанный за все эти годы, будет её лишён. Это, мягко говоря, очень неприятно.
О, это же скриптовый язык. Скриптовать можно много чего, но пожалуй одно из самый частых применений -- это работа с ФС. Окей. Пожалуйста, найдите библиотеку для работы с ФС, которая способна повторить функционал команды cp полностью (я даже сохраню Вам время и скажу прямо: cp -R). Нету? Ну надо же. А ведь это вещи, которые, казалось бы, должны бы уже давно быть, за столько-то лет.
Не, я понимаю, что "может быть не было необходимости"... Но если я начну писать на питоне, мне что, от этого легче, что ли, будет? В общем, мне хватило того небольшого погружения, что у меня было. И критика у меня простая: очень незрелые библиотеки.
Касаемо вопроса: если отказываться от питона, то я бы рекомендовал посмотреть в сторону Perl5, как на скриптовый язык общего назначения. Для большинства случаев работы с ФС хватает shell. Если же вам питон интересен в основном обвязками для сторонних библиотек (очень частое применение питона), то есть например OCaml -- язык семейства ML с прекрасным CFFI.
Меня Python интересовал главным образом для написания вебприложения.Почему же тогда Python стал настолько популярен, если у него плохо с библиотеками. Почему тот же Perl5 был им вытеснен (ведь на Perl сейчас довольно мало программируют, хоть он и не умер полностью). Почему в машинном обучении доминирует Python.
> если отказываться от питона, то я бы рекомендовал посмотреть в сторону Perl5, как на скриптовый язык общего назначения.
А вебсайты тоже на перле писать? Сейчас же так никто почти не делает, питон всех вытеснил почему-то
> сли же вам питон интересен в основном обвязками для сторонних библиотек, <...> то <...> OCaml...
Возможный вариант, ML-подобные мне нравились в университете, хотя у них и есть ореол заброшенности (мы на Standard ML фигачили). Почему вот только в машинном обучении (самой, наверное, прорывной отрасли подобного применения) Python почти везде, а OCaml - ну как минимум не на слуху (уж не скажу, что совсем не в ходу, потому что не знаю, мб используют где)?
> Меня Python интересовал главным образом для написания вебприложения.
> Почему же тогда Python стал настолько популярен, если у него плохо с
> библиотеками. Почему тот же Perl5 был им вытеснен (ведь на Perl
> сейчас довольно мало программируют, хоть он и не умер полностью). Почему
> в машинном обучении доминирует Python.Ну дык. Академический язык же. Обучение на нём ведут. Когда-то вели на Pascal -- он тоже был дико популярен. Настолко, что даже на всяческих Delphi много чего понаписали.
>> если отказываться от питона, то я бы рекомендовал посмотреть в сторону Perl5, как на скриптовый язык общего назначения.
> А вебсайты тоже на перле писать? Сейчас же так никто почти не
> делает, питон всех вытеснил почему-тоВытеснил ли? А как же nodejs и php? На perl не знаю, как обстоят сейчас дела, но раньше сайты на нём вполне себе клепали.
>> сли же вам питон интересен в основном обвязками для сторонних библиотек, <...> то <...> OCaml...
> Возможный вариант, ML-подобные мне нравились в университете, хотя у них и есть
> ореол заброшенности (мы на Standard ML фигачили). Почему вот только в
> машинном обучении (самой, наверное, прорывной отрасли подобного применения) Python почти
> везде, а OCaml - ну как минимум не на слуху (уж
> не скажу, что совсем не в ходу, потому что не знаю,
> мб используют где)?В основном, думаю, виной тому высокий порог вхождения в ocaml и большое количество студентов, которых обучали на python-е. Хайповость темы machine learning-а в частности сыграла свою роль.
> Вытеснил ли? А как же nodejs и php?Да, это я неправильно выразился, не вытеснил один. Но пришёл вместе с другими на замену вытесняемому perl. Вопрос только, на чём ныне лучше писать сайты всё-таки
>> Вытеснил ли? А как же nodejs и php?
> Да, это я неправильно выразился, не вытеснил один. Но пришёл вместе с
> другими на замену вытесняемому perl. Вопрос только, на чём ныне лучше
> писать сайты всё-такиНа чём *лучше* -- сказать по нашим временам сложно. Насколько я вижу, во всех серьёзных проектах используется jamstack (или что-то похожее). То есть ты статику в виде js и картинок отдаёшь, и всё это дело взаимодействует с бэкендом через api. Бэкенд же работает на любом языке.
Мне пока видится это наиболее разумным сочетанием. Так что, если отвечать на Ваш вопрос общО, то видимо сайты лучше писать таки на js.
Вот и пришли к тому, что бэкэнд таки на любом языке, в т.ч. и на Питоне. Хотя вопрос был именно в том, что если не питон раскритикованный тут, то кто?
> Вот и пришли к тому, что бэкэнд таки на любом языке, в
> т.ч. и на Питоне. Хотя вопрос был именно в том, что
> если не питон раскритикованный тут, то кто?Я так скажу: если Вы правильно выдержали архитектуру, можно наверное и с питоном выехать. Хотя жрать он будет, конечно, дай боже. Да и тяжело будет с питоном правильно её выдержать. Столько грамотных питонистов Вы никогда не найдёте.
Серьёзные проекты с питоном в бэкенде не делаются -- это факт.
Вот просто по личному опыту хотя бы (хотя это, конечно, субъективно):
Я участвовал в разработке DLP-систем. Там бэкенд был на Racket и Clojure (плюс местами на Ocaml и Scala -- проект с боооольшущей историей).
Я участвовал в национальном проекте, связанном с товарооборотом. Там бэкенд был на Scala.
Текущий проект -- система процессинга платежей. В бэкенде Elixir.А Python-а нигде не видно.
Я не отрицаю, что в принципе, можно на питоне что-то построить. Но стоимость поддержки и развития этого добра будет очень большой. Слишком большой, чтобы связываться. Если магазинчик какой, может ещё можно подумать. А если чего-нибудь покрупнее, то наверное не стоит.
Ого, кложура таки жива
> Почему же тогда Python стал настолько популярен, если у него плохо с
> библиотеками. Почему тот же Perl5 был им вытеснен (ведь на Perlон в основном phpой был вытеснен - догадываешься, почему?
> сейчас довольно мало программируют, хоть он и не умер полностью). Почему
> в машинном обучении доминирует Python.потому что им (успешно) занимаются люди с хорошим математическим образованием, но профнепригодные как программисты. При этом им не нужна ни эффективность кода, ни простота его сопровождения. Наляпали и выбросили, ценность в модели а не в коде.
> А вебсайты тоже на перле писать? Сейчас же так никто почти не
а почему, собственно, нет? Ну, правда, с FCGI придется мучаться. Проблема только что это будет очень низкоуровневое программирование, никакого тебе ни битрикса, ни дрюпалки, ни хотя бы Typo. Ну и сколько лет ты собираешься копаться?
> делает, питон всех вытеснил почему-то
вообще-то это был php. Ну и жаба-ее в ентер-прайсе.
джанга - труп смердящий, да и при жизни не отличалась особой ароматностью, а больше как-то популярного на пихоне ничего и не напихали.
> а почему, собственно, нет? Ну, правда, с FCGI придется мучаться. Проблема только что это будет
> очень низкоуровневое программированиеРазве это правильно? Все говорят, что лишняя низкоуровневность - зло, да и правда - может у меня не так много времени и я хочу побыстрее именно бизнес-логику написать, а не всю эту обработку запроса. А то в случае сложного приложения из низкоуровнености в итоге будет наговножен собственный недофреймворк, который бажен чуть более, чем наполовину. Для поделки мб и норм, но, скажем, энтерпрайз-то весь на фреймворках
>> делает, питон всех вытеснил почему-то
>вообще-то это был php. Ну и жаба-ее в ентер-прайсе.Ладно, да, питон не вытеснил всех, я согласен. Но он был одним из тех, кто стал приходить на замену вытесняемому perl.
> джанга - труп смердящий
Неужели с ней так всё плохо? И что лучше (не обязательно питоновское)? Рельсы? Spring? Нода? На опеннете так-то все эти фреймворки и технологии недолюбливают, а на чём вот только сайт писать, если надо фреймворк, не хочется низкоуровневой возни?
Какие контейнеры? Мы обсудим systemd лучше :)
Да, точно! И заодно ритуально похороним питон. Уже скоро тридцать лет будем традиционно хоронить.