LINUX.ORG.RU

Сообщения byko3y

 

Переводы денег по СНГ в 2023

У меня осталось большое числое знакомых линуксоидов и просто родственников по другую сторону баррикад. Мало того, что на Россию наложены санкции, так вдобавок изнутри тоже затягиваются гайки выискаванием иноагентов под каждым кустом и тотальным запретом обезличенных платежных систем для переводов более 50 рублей в месяц. Единственным надежным вариантом остаются криптовалюты, но биткоин на хлеб не намажешь, а правовой статус у криптовалют остается спорный.

В моем случае речь идет про довольно смешные деньги, порядка нескольких тысяч рублей, которых хватит разве что для того, чтобы не приходилось воровать в магазине еду и торговать телом — ни про какое отмывание и спонсирование терроризма речи не идет. Сам я не скрываюсь, достаточно внимательные местные обитатели знают и мое имя, и где я живу (жил).

Вариант ехать в Грузию/Армению рабочий, но очень геморный (и меня не выпустят). Кто как решает проблему/может помочь? Если не готовы озвучить публично — можете написать на мойник@gmail.com.

 , ,

byko3y
()

Обратная сторона Эльбруса

https://www.youtube.com/watch?v=mm4B5nBtuFQ&t=395s

Я сначала не мог понять, что это за фигня вокруг Эльбруса, но сейчас логические цепочки выстроились: некие коррумпированные круги под соусом «отечественный импортонезависимый процессор» распилили астрономическое число денег, получив чудовищно дорогостоящий процессор, который может производиться только в Тайвани. Когда люди наконец узнали стоимость сего чуда, то логично сказали «пошли вы на с таким импортозамещением». На что им ответили: «ах так? А вот мы обяжем все гос конторы ставить только Эльбрусы». Результат — из-за резкого роста стоимости всей авиакосмической продукции произошло резкое сокращение производства БПЛА и ракет. Причем, производить в России эти процессоры тупо негде.

Вот я и удивляюсь: почему в каждом треде про Эльбрус не говорится, что это совершенно бесперспективный проект с нулевым выхлопом с целью тупого попила?

 , ,

byko3y
()

Существуют ли эргономичные смартфоны без зондов?

Ну типа да, есть кучу смартфонов с возможностью поставить LineageOS+Aurora, но проблема в том, что 99% смартфонов на рынке делаются под 75-77 мм ширину, руки соответствующего размера в комплекте не идут, а теми, что есть у меня, держать 75 мм девайс чудовищно неудобно. Меня забавляют тяновны, которые вообще держат девайс на кончиках пальчиков, как блюдечко. Еще пошла мода на безрамочные устройства, чтобы ты не дай бог не вздумал держать их пальцами за край.

Даже если брать не адроидсовместимые девайсы, вроде соснофона и либрема, там тоже 75 мм, а раскладушку Пиру уже 7 лет пилят-пилят, пилят-пилят, а до сих пор Preorder.

 , ,

byko3y
()

Индустрия вообще выпускает автономные мобильные устройства?

Меня поражает современная мода на устройства, автономности которых хватает лишь на то, чтобы успеть проехать на автобусе от одной розетки к другой. Особенно меня удивляют ноутбуки, которые почему-то идут по пути уменьшения массы ниже 2 кг, а не повышения автономности. Да, я понимаю, что генеральная идея заключается в том, чтобы привязать всех к зондам, что ты должен быть подключен к сети, а там, где есть сеть, есть и розетка для подзарядки. Но я абсолютно уверен, что куче людей автономности стандартных устройств не фатает. Поясните мне, кто и как толкает движет индустрию по пути снижения автономности. Какие-то идиоты же покупают ультратонкие ноуты? Я уверен, что некоторые даже тут сидят — поясните, что вами движет?

inb4: таскай с собой дизель-генератор повербанк.

 , ,

byko3y
()

Gajim перестал показывать историю чата

Поставил через flatpak 1.4.1, запускаю через:

flatpak run org.gajim.Gajim -c /home/user/.var/app/org.gajim.Gajim/profile

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

Как вариант — посоветуйте jabber клиент или посоветуйте свалить на телеграм. Но телеграм тоже такое-себе.

 , ,

byko3y
()

Кто как борется с фактическим отсутствием приватных объявлений в C++?

Как мы все знаем, private объявления де-факто являются частью интерфейса класса, их изменение приводит к перекомпиляции зависящего кода. Кто как обходит проблему? Из того, что я перепробовал:

 — непрозрачные ссылки на forward-объявления структур и функции для работы с ними;
 — публичная структура, которая агрегируется в класс-реализацию;
 — абстрактный класс, он же «интерфейс», от которого наследуется реализация.

Но у всех них есть свои недостатки. Есть ли какие-то иные приемы, которые я упустил?

 , ,

byko3y
()

Есть ли где-то архив видео Gary Bernhardt/Destroy All Software

Например, не могу нигде найти:
https://www.destroyallsoftware.com/talks/useing-youre-types-good
Чел просто взял и удалил его со своего сайта. Видео было публично, но на ютьюбе оно не выложено, и по итогу остались только рассказы в реддите про «ах, какой хороший был слон».

 , , ,

byko3y
()

AWS и в частности S3 как vendor lock

N месяцев назад мне ставили в упрек то, что якобы аналоги сервисов AWS есть у кучи других провайдеров. Ну есть же да? Сколько альтернативных реализаций S3, да? Как бы не так. Который месяц ковыря S3, я прихожу к однозначному выводу: интерфейсы AWS определены через реализацию, то есть, нет никаких общих абстрактных протоколов, разработанных для конкретных задач. Вместо этого протекает деталь реализации здесь, протекает костыль тут, здесь устаревший параметр, которым уже давно никто не пользуется, а здесь новый параметры, которым ЕЩЁ никто не пользуется, и по итогу портирование минимально сложной системы на базе S3 с одной площадки на другую требует целой команды макак с напильниками.

Раньше я не решался высказать эту мысль, потому что у меня небыло железных пруфов, но сейчас они есть, по крайней мере по отношению к S3. Даже достаточно продвинутые реализации S3 API в Yandex.Cloud или Ceph имеют огромное число несовместимостей с AWS.

Как бы это не могло звучать странно, тем не менее, эту картину я вижу далеко не первый раз. Это не тупая ошибка, а точный расчет — так развивали свои решения как минимум Oracle, SAP, Microsoft, а именно — холили и лелеяли каждый маленький костыль, для поддержки которого приходилось выделять отдельного программиста, ровно для одной цели — чтобы никто не мог реверс-инженернуть твою софтину и написать альтернативу, таким образом уведя клиентов. IBM сделало независимый от реализации стандарт PC? Intel сказал огромное спасибо и монопольно основался в нише.

К тому же, с маркетинговой точки зрения чем больше пунктов с фичанеймами в брошюрках — тем лучше смотрится продукт. Почесать левой рукой левое ухо — замечательная фича. Клиент приходит с запросом «мне нужно почесать левое ухо правой рукой» — «извините, поддержка такой фичи у нас не планируется».

И только не нужно мне говорить, что вот же есть где-то Джон и Фрэнком, которым позарез нужен ваш костыль 1997 года выпуска, без которого они не могут жить. Могут. Разработчик мог сэкономить на поддержке этого костыля, потеряв лояльность пары клиентов — это допустимая жертва. Однако, фактор vendor-lock-а за счет бесконечной поверхности интерфейса В УСЛОВИЯХ ИЗБЫТКА ФИНАНСИРОВАНИЯ слишком привлекателен. Я хочу подчеркнуть фактор избытка финансирования, потому что при недостатке финансирования клиенты Джон с Фрэнком будут мгновенно посланы, руководство ни одной минуты не будет размышлять про какую-то совместимость, доверие клиентов, и прочие пустые слова, лишь поддержка будет отвечать дежурное «мы работатаем над этим, оставайтесь пожалуйста на связи». Всё, о чем будет думать руководство — это как сократить издержки. чтобы выйти на прибыль.

Мне удивляет только тот факт, что подобные соображения никто не пишет на каждом заборе. Ведь это просто священные заповеди коммерческой разработки, но даже я до недавних пор не рисковал оглашать их публично. Страшно то, что эти заповеди «с молоком матери» впитали многие разработчики, и следуют им, даже не понимая, что эти заповеди существуют. «Я должен поддерживать совместимость ради совместимости. Моя совместимость должна быть совместимой. Даже если я обосрался в минорном релизе, который скачало 10 человек — я буду эту ошибку тащить следующие 10 лет разработки, потому что могу».

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

 , , ,

byko3y
()

Советы несчастным пользователям MS Teams

Которые вынуждены этой сранью пользоваться под линем. Так сказать «новое дно пробито». Я уже молчу про проблемы плана «не работает видео», «не работает звук». Мне удалось побороть проблему автостарта через «rm ~/.config/autostart/teams.desktop» в ~/.profile (этот кусок дерьма отказывается работать, если не пропишется в автостарте).

Но есть вещь более страшная. Это пустое окошечко с крестиком закрытия, которое захватывает фокус ввода, делая все иксы фактически неюзабельными. Я сижу на Xfce, включил в настройках «focus stealing prevention», но это не помогает. В интернетах говоря, что помогает режим «фокус следует за мышкой» — но этот режим не устраивает меня сам по себе.

 ,

byko3y
()

Кто пользовался ClickUp?

Достала меня реклама на ютьюбе... потому я принес ее на LOR. Ведь правы ребята в рекламе, это и есть то самое единственное, чего в Jira нет и никогда не будет — гибкости. Как бы хорошо она не была настроена, как бы удобна эта настройка здесь и сейчас не была для конкретного человека — уже завтра возникнет потребность настроить ее по другому.

К сожалению, сам я этот ClickUp в бою пока не тыкал. Из того, что я видел, это похоже на Тот Же Сорт Говна Reloaded, то есть, без старого наследия, но с «новым наследием».

А может быть у кого-то есть мысли по поводу того, как вырваться из этого порочного круга©? Я слыхивал, что в том же Google™ пользуются чем ни попадя для прожект менеджмента — так может в этом и есть счастье? Ну то есть не иметь конкретного инструмента.

 , , ,

byko3y
()

Когда линь перестанет виснуть при исчерпании памяти? (2022)

Сколько я пользуюсь компами с виндой и линем, столько испытываю эти проблемы. Некая десктопная софтина жрет оперативу. потом еще немного жрет, и еще немного, и потом внезапно система висит, бешенно читая SSD накопитель. OOM не срабатывает, потому что память в медленном сценарии не исчерпана. Хуже всего то, что при отсутствии свопа данный сценарий наступает очень резко, лавиннобразно, система работает как ни в чем ни бывало, а потом за несколько секунд замирает.

Прописал vm.vfs_cache_pressure = 20 в /etc/sysctl.conf — ничего не поменялось. Systemd до недавних пор в этом плане тоже была поломатое, вроде в бунте 21.10 пофиксили, но у меня деб 11: https://github.com/systemd/systemd/issues/10581

 , ,

byko3y
()

За что я люблю никсовую консоль

rm /opt/db/ *

 , , ,

byko3y
()

Откуда берутся требования «программист Go 12+ лет стажа» [тупятница]

В очередной раз читая статьи успешнилы, у меня внезапно появился ответ на этот вопрос. Как когда-то заметил ixrws, есть два мира: реальный сектор, который производит товары и оказывает услуги, и спекулятивный сектор, который делает вид, что что-то делает, но на самом деле ничего не делает, а лишь встраивается в потоки денег/валют (в том числе ценных бумаг и байтиков в БД) с целью выуживания прибыли из этих потоков. Именно последние формируют такие замечательные аномалии, как отрицательная цена на нефть, которая в реальном секторе не имеет никакого смысла, если это нефть не загрязнена плутонием.

В чем фундаментальная особенность крайних проявлений двух миров? Мир реального сектора тут надолго, он долго завоевывает репутацию и дорожит ею, у него есть средства производства, у него есть костяк квалифицированного штата и доверенные партнеры. Потому разработка ПО для реального сектора часто отличается умеренным финансированием, долгими сроками реализации, ориентацией на долгосрочную перспективу. Пример чисто айтишного реального сектора — это гугл, который на долгосрочную перспективу развивает опенсорсную инфраструктуру. Питон и линукс по большему счету поднялся именно за счет гугла: cgroups именно в гугле разработали, а ведь на нем держатся все линуксовые контейнеры; TensorFlow, опять же, разработка гугла.

В противовес этому, спекулятивный сектор стартапов, на 95% состоящий из заведомо провальных проектов, абсолютно точно разорится, рано или поздно, поскольку сам по себе не генерирует прибыли. Даже успешные стартапы в итоге сводятся к «продать гуглу/фейсбуку и уехать в закат». Примерно для таких проектов Дональд Норман сформулировал свой закон: «The day the product team is announced, it is behind schedule and over its budget». Смысл как раз в том, что стартап уже разорился в тот момент, как только получил инвесторов.

Следствие такого экономического подхода — решение/продукт нужны ПРЯМО СЕЙЧАС. В идеале реализацию нашего клона AWS нужно завершить к обеду, а к ужину мы уже раскатаем его по всему земному шарику и начнем продавать. Потому что есть ненулевая вероятность, что эту неделю стартап уже не переживет.

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

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

Мне всё это в диковинку. потому что я большую часть карьеры работал с продуктовиками, и для меня особенности стартапной экономики кажутся безумными. А кто-то привык работать в сплошных финансово-медико-бигдатово-микросервисовых стартапах, и потому видит совершенно естественным подход «я изучил вышедший пять минут назад фреймворк и уже имею пять лет экспертизы в нём, которые и продаю очередному стартапу». Отсюда эксперты по Cassandra, которые ничего не понимают в принципах проектирования распределенных БД — они продают кассандру, потому что стартапу нужна кассандра прямо сейчас, потому что инвестор заплатил именно за кассандру, ему не нужно грамотное проектирование БД, потому что инвестор все равно ничего не понимает в БД, а стартап гарантировано разорится и разница заключается лишь в том, насколько быстро это произойдет.

PS: кто-то может удивиться, почему экономика 100% разоряющихся стартапов работает. Есть два фактора: казино помноженное на тупость, то есть, МММ; и эмиссия, которая изначально подразумевалась просто для притягивания инициативных людей со всего шарика в штаты, просто чтобы эти люди остались в штатах, а не начали внезапно создавать перспективные проекты в других регионах.

 , , ,

byko3y
()

log4j — уязвимость на сервисах AWS, Cloudflare, iCloud, Minecraft, Steam

https://habr.com/en/company/mvideo/blog/599689/

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

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

Уже обсуждалось тут: Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

UPD: https://habr.com/en/news/t/599865/ — Автор faker.js и colors.js намеренно сломал свои пакеты

Еще один аноним из зимбабве недоволен, что корпорации используют его библиотеки, и потому, воспользовавшись привелегией лицензии MIT про отказ от ответственности, автор взял и намеренно испортил код библиотеки — дошло до блокировки его аккаунта GitHub-ом!

Разработчик внёс деструктивные изменения в NPM-пакеты colors и faker, применяемые в 20 тысячах проектах

 , ,

byko3y
()

Amazon S3

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

Недавно Амазон объявил о переходе с модели eventual consistency на strong consistency, то есть read-after-write consistency.
А также есть статья в блоге некоего высокопоставленного манагера из Амазона:
https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html — Diving Deep on S3 Consistency

Первое, что думается в ответ на эти новости: а как же теорема CAP? Подсказки для этого ответа ищутся в гугле:

https://news.ycombinator.com/item?id=25271791

So they claim performance and availability will remain same while claiming strong consistency. I was confused at first but then “same” availability isn’t 100% availability. So it indeed CP.
https://www.scalefactory.com/blog/2020/12/03/s3-small-announcement-big-impact/
In this paper about Spanner, we learn that it’s possible to build a CA system (one which prioritises Consistency and Availability) and also build a network so good that the risk of Partitions to be Tolerant of is negligible enough to effectively ignore.

Короче говоря, CAP никуда не делось, вечного двигателя, сверхсветовой передачи информации, или телепорта в амазоне не изобрели. Амазон пошел по логичному пути: пока нет ни единого разрыва сети, БД дает consistency+availability гарантии, когда сеть рвется — запросы на запись перестают выполняться, имеющиеся данные замораживаюся в том систоянии, в котором они были до разрыва.

Теперь по самой реализации. Инфа в гугле крайне скудная, пока что лучшее, что удалось найти:
https://www.reddit.com/r/aws/comments/k4yknz/s3_strong_consistency/gecdohv/

If I had to guess, s3 synchronously writes to a cluster of storage nodes before returning success, and then asynchronously replicates it to other nodes for stronger durability and availability. There used to be a risk of reading from a node that didn't receive a file's change yet, which could give you an outdated file. Now they added logic so the lookup router is aware of how far an update is propagated and can avoid routing reads to stale replicas.

Судя по всему, ключевым архитектором сего чуда был некто Нихил Шах:
https://www.linkedin.com/in/nikhiljshah/

DATA ITEM AND WITNESS SERVICE PARTITIONING IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P73159-US01

TRANSACTION MANAGEMENT FOR MONOTONIC WRITE CONSISTENCY IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P74530-US01

Первое, что находится в гугле по запросам «strong consistency witness» и «monotonic writes witness» — это статьи:

http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf - Voting with Witnesses: A Consistency Scheme for Replicated Files
https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

Первая статья делает акцент на quorum-based консенсусе — это весьма медленная штука и я сомневаюсь, что амазон смог бы отрапортовать про бесплатный апгрейд согласованности данных, если бы оная для простого чтения требовала еще одной круговой задержки по всему кластеру. Из этой же оперы идет статья с модификацией Apache ZooKeeper:

https://www.usenix.org/system/files/fast20-ganesan.pdf - Strong and Efficient Consistency with Consistency-Aware Durability

Здесь авторы просто отложили операции записи, за счет чего уменьшили время ответа по запросам записи до уровня асинхронной репликации (и потеряли гарантии сохранности при исчезновении питания, но кого это волнует в 2022?). Монотонность чтений без необходимости опроса всего кластера «гарантировали» списком активных узлов, которые получили актуальные изменения и знают об этом. Можно спорить по поводу того, вовремя ли отвалившиеся узлы поймут, что у них уже нет актуальных данных, и потому сериализуемы ли чтения по кластеру, но ведь чтения несериализуемы даже в оригинальном ZooKeeper по абсолютно той же причине (узел может продолжать думать, что он лидер, хотя в кластере выбран новый лидер) — так что вроде как ухудшения нету.

Вот я сидел-сидел, думал-думал, и подумал «а зачем здесь полный консенсус?». Соответственно, взор мой возвращается снова на

https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

где авторы используют свидетелей просто как избыточное eventual consistency хранилище. Вам ничего это не напоминает? Мне напоминает устройство S3 до введения строгой согласованности.

Лично я склоняюсь к тому, что Амазон под капотом S3 оставил тот же самый eventual consistency, работающий на типичной для той же Amazon DynamoDB модели «sloppy consensus», например, когда у вас 10 узлов в сети и для подтверждения записи достаточно подтверждения от 3 узлов (а не шести, как это было бы в строгом консенсусе). Данные со временем будут раскопированы асинхронно на остальные узлы. Естественно, sloppy consensus никак не защищает от split brain, когда у вас две части кластера теряют связь и начинают независимо изменять файлы (в обоих частях есть по три узла для успешного подтверждения), и потому не знают про изменения в другой части кластера. Очевидно, при восстановлении связи нужно как-то конфликтные изменения разруливать. Amazon DynamoDB и Riak уже давно используют решение «в лоб» — оставлять запись с самым последним timestamp. Ту же политику декларирует S3:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#Consistenc...

Amazon S3 does not support object locking for concurrent writers. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins.

Совпадение? Не думаю. По итогу воображается что-то такое:

https://habrastorage.org/webt/ve/c9/ua/vec9uatqx1zht2814ljj-ipvipm.png

То есть, по сути то же самое DynamoDB плюс подобие процессорного кэша. Успешный ответ на операцию PUT возвращается только после успешного сохранения на достаточное число персистентных хранилищ и после оповещения кэшей. Операция оповещения кэша требует передачи данных по сети, но лишь самого минимума, и кэш может мгновенно ответить на этот запрос, так что синхронность не является проблемой.

Как можно заметить, я нарисовал четыре стрелки от кэша к хранилищу — это минимальное количество связей, которое нужно для гарантированного получения данных, залитых на 2 из 5 хранилищ. В принципе, используя информацию из оповещения кэш может стучаться только в два первых хранилища, в которые данные будут размещены раньше всего. Конечно, может оказаться так, что данные уже нужны, а они даже в первые хранилища не залиты — это достаточно редкая ситуация, которую можно разрулить через запрос «отдай мне данные версии XXX, если они у тебя уже есть».

Здесь возникает множество подводных камней при потери связи между узлами. Например, кэш может так и не дождаться ответа на «отдай мне данные версии XXX». Но проблема может быть еще серьезнее: что если кэш вообще не получил уведомления и до сих пор считает, будто данные остались в своей старой версии? Вот это и есть вся фишка CAP и недосказанности со стороны Амазона — а ничего не делать, тупо выдавать старую версию файла, хотя уже давно есть новая. Скрестим пальчики и будем надеяться, что ситуация февраля 2017 года больше никогда не повторится.

 , , ,

byko3y
()

Спрос на питонистов [теория тупости]

Сопсоставил я факты, и поразился одной вещи, которую отправлю вам в виде твитта.

На рынке труда сложилась абсурдная ситуация, когда зарплаты питонистов вышли почти на уровень крестовиков. Питоносеньоры стоят $5500-7000. WTF, если учесть, что изначально смысл питона заключался в том, чтобы посадить на нем кодить макаку за еду? Неужели я был прав год назад, когда писал, что кодинг на питоне не проще, чем кодинг на C++? Или же это очередной рынкоабсурд плана:

-- На чём будем делать новый проект?
-- На питоне. На нем проще писать и больше кодеров...
Спустя год...
-- Почему до сих пор ничего не работает и где нам найти норм индуса-питониста дешевле чем за $5000?

 , , ,

byko3y
()

Имел неосторожность посерфить инет со слабого ноута [теория тупости]

Одноядерный Celeron 2 ГГц образца эдак 2010 года, аш целых 4 Гб оперативы — для своего времени это был достойный экземпляр с солидным временем автономной работы. В свое время на ноуте писался код, игралась дота и CS, смотрелся ютьюб и твитч. В 2022 году я попытался посмотреть трансляцию, зайти в фейсбук — мамачки, даже ссаный фейсбук довольно неспешно перекатывается в браузере. Как там разрабы реакта говорили... «fast enough»? Они только не добавили, что «fast enough for 4 cores and 16 Gb RAM». Вся эта реактная параша просто не работает. В принципе, я это знал, но я просто не подозревал, насколько всё плохо, НАСКОЛЬКО ВСЁ ПЛОХО. И самое страшное то, что совсем недавно я примерно это же и писал, только не на реакте, а не Vue. Пошёл ставить свечку и молиться. С новым годом. Мы все умрём.

 , , ,

byko3y
()

Есть ли годные гайды по стилю для питона

Я внезапно осознал, что толком не могу сформулировать, какие фичи питона стоит использовать, а какие — нет (как в последнем треде по крестам). Ситуация усложняется тем, что нынче каждая вторая собака считает себя гуру питона и готова учить других, но только единицы умеют по-настоящему хорошо пользоваться языком. Я могу открыть очередную сессию экспертов LOR следующими правилами:

  • Не используй monkey patching (изменения классов и функций в процессе работы приложения) без крайней необходимости;
  • Не используй классы, если это не навязывает библиотека и тебе не нужно переопределить операторы, предпочитай duck typing. Следствие — статическая типизация в питоне не работает;
  • Лямбды — говно, и функциональная парадигма в питоне близка к неюзабельности из-за трудности передачи блока кода аргументом. Язык изначально ориентирован именно на импертивный код аля «башпортянка», потому предпочитай list comprehension/generator expression вместо filter-map;
  • Предпочитай пересоздавать простые значения с нужным типом, а не передавать их как есть или по ссылке. При изменении значения ячейки используй новые значения, а не изменяй старые обьекты. Под капотом CPython уже создает-высвобождает объекты на каждый чих. Создать строку из строки в питоне стоит примерно ничего, но если внезапно вместо строки подвернется непонятный тип или None, то код рискует свалиться со стэком в неожиданном месте.

PS: мои прошлые работы по теме, которые дают советы «как не делать», но не дают советов «что же делать»:

Объектная модель питона
https://habr.com/ru/post/481782/ - О проблемах транслятора Python и переосмысление языка

Перемещено leave из talks

 , ,

byko3y
()

Опрос: Три-пять лучших фич C++

Поскольку я с недавних пор устроился на работу, то простыни временно закончились. Тем не менее, каждый раз при работе с сишным кодом снова и снова всплывает мысль «блин, как же здесь не фатает крестов». Но в остальном сишки мне более чем хватает, мне не нужны геттеры-сеттеры, классы-интерфейсы под single responsibility, и прочая мура. Пару источников вдохновения:

https://google.github.io/styleguide/cppguide.html
https://yosefk.com/c fqa/

Итак, назовите от трех до пяти фич крестов, которые бы вы взяли с собой на необитаемый остров Си. Можно несуществующие или из будущих стандартов. А я чуть позже назову те, которые взял бы я. (назвал)

И да, я в курсе, что где-то год назад ведьмак создавал тред на схожую тему, но мое знание крестов с тех пор выросло настолько, что меня чуть не взяли работать крестовиком. Так что теперь тред вести буду я. Как обычно, «для себя из прошлого», чтоб гештальты позакрывать.

Итоги по состоянию на 24.12.2021 22:00 (MSK): https://pastebin.com/bxamaGDY

 , ,

byko3y
()

Почему решая литкод ты никогда не станешь архитектором (но на самом деле никогда не хотел им быть)

Специальный выпуск для linux.org.ru.

Когда я был юношей, то они мне говорили «вырастешь — поумнеешь». Я вырос, но не поумнел. Но иногда я жалею, что не знал тогда того, что знаю сейчас — так и хочется написать тому юноше письмо из будущего, что я и намерен импровизировать в виде треда на LOR.

Среди взрослых людей есть довольно ярко выраженная дихотомия в способе принятия решений: люди, которые знают решение, и люди, которые это решение всегда способны найти за достаточно продолжительное время; те, кто ни за что не признают ошибку, и те, кто ошибаются на регулярной основе даже если уже знают решение; те, чей максимальный интервал принятия решений составляет «между двумя глотками смузи» (ведь «моё время дорого стоит»), и те, кто тщательно выстраивает цельную картину проблемы и неспешно обсасывают ее со всех сторон.

Поскольку первых людей сильно больше, чем вторых (соответственно спросу), то массовый программист, как правило, оценивается по тому, как много решений он может выдать между двумя глотками смузи. Индустрии нужно зарабатывать деньги на массовом конвеерном фуфле, индустрии не нужны оригинальные решения. Как решить большую сложную задачу на подобном конвеере? Взять больше смузи и хлебать чаще, посадить дополнительных смузихлебов на тестирование этого дела. Самое страшное — когда в подобном духе начинает работать Boeing, и самолеты начинают падать. Можно радоваться тому, что упал не ваш самолет, а можно подумать о том, что завтра ваше авто с вами за рулем может внезапно оказаться не ваше, потому что его хакнет 7-летний китайский ребенок, и единственная реальная защита — это тот факт, что Илон Маск платит всем денеги только чтобы уязвимостями в автомобилях и инфраструктуре не пользовались злоумышленники.

Мне вспоминается старый-престарый эпизод моей жизни, как я еще будучи школьником выиграл олимпиаду по информатике. Задача была на поиск кратчайшего пути (пардон, точного условия уже не помню, это было давно и неправда). Грамотный программист быстро выдаст вам «правильное» решение O(N log N) по алгоритму Дейкстры. Но поскольку на тот момент я не знал алгоритма Дейкстры и не был грамотным программистом, то вместо «правильного» решения выдал асимптотику O(N), заэксплуатировав некоторые особенности конкретных условий той задачи.

И второй эпизод, современный. Меня выбесило одно из недавних моих собеседований: некая контора дала мне тестовую задачку, являющуюся также одной из фундаментальных задач, решаемых их продуктом. Мне просто забыли сказать, что «правильный» метод должен быть O(N^3), и я случайно потратил целый день на разработку метода O(N^2), который оказался настолько неожиданным для «сеньоров», что им понадобилась целая неделя для анализа моего решения на 500 строчек (inb4: фу-фу, лапшемес), а на собеседование со мной собрали всю верхушку — на минуту у меня сложилось ощущение, будто меня собеседуют в гугл, а не в местную помойку. Я не удивлюсь, если вся их шарашка уже работает над интеграцией моего метода, и в скором времени получит премию, мол «наш отдел провел тщательные исследования предметной области...», а тебе, мартыха, хрен с маслом. И это собравшееся начальство на собеседовании было серьезно намерено развести меня на решение еще одной важной для их помойки задачки. Большая часть их штата джуно-мидлов занимается обвязками-прокладками-интерфейсами-тестированием, короче говоря, теми задачами, под которые можно нанять горсть рабов с улицы хоть прям щас — но эти люди в жизни не смогут выдать оригинального решения, а только будут ждать команд сверху.

Вишенка на тортике — под конец мне дали задачку с литкода, которая была будто специально подобрана так, чтобы быстрое решение требовало от меня знание специфичных фич стандартной либы, которое я им изначально честно заявил как «слабое». Те функции выучиваются наизусть за пару дней, а аналитическое мышление развивается годами, но нет «ты слабоват, мы можем тебя взять, но на ЗП в два раза меньше». Вот так вот: «не подскажешь, как пройти к вокзалу?... А теперь встань раком и вези меня туда».

Что мы всё про меня да про меня. С точки зрения массовой индустрии Дуглас Крокфорд — посредственный программист, и в недавнем треде большое число отписавшихся доходчиво пояснило, почему это так. Да, подумаешь, он создал какой-то там JSON, на котором работает половина индустрии, а еще создал JSLint, который ведь оказался так себе и был вытеснен ESLint-ом, и вообще «я могу сделать лучше, просто оно мне не надо». Но печальная истина в том, что тысячи смузихлебов писали на JS безо всякого линта, и, я уверен, при возникновении онного долго противились новой технологии. Проходит время, и вот уже каждый школьник считает своим долгом задействовать ESLint и JSON, а пишет, естественно, на ES2015, добрая половина фич которого была реализована при непосредственном участии Крокфорда (кстати, мало кто знает, что Object.keys/Object.values еще в ES5 было внесено по инициативе Крокфорда) — но этот школьник понятия не имеет, откуда взялись «мои любимые технологии».

Я хочу подчеркнуть, что это не одиночный пример мнения отдельной макаки — это закономерность, которую заметил не только я, и не только эту. Такие люди, как Крокфорд, могут бесконечно выдавать оригинальные идеи, но как исполнитель они так-себе, у них вечно шило в попе, толкающее на приключения, потенциально грозящие сорвать сдачу проекта (которая назначена на вчера, как обычно). Я задумался: а кому могут быть в самом деле нужны такие люди? Да, в силиконовой долине можно себе пригреть местечко — по этому пути успешно прошелся Крокфорд. А что делать, если я не хочу развивать силиконовую долину? Я в молодости отказался ехать туда, и сейчас не особо горю желанием (но и не предлагают уже). Вот такое вот я капризное животное.

Более того, если допустить, что Крокфорд выдал некое супер-пупер классное решение для вашей фирмы, то возникает проблема — кто его будет поддерживать/развивать? А также так называемый Bus factor — что делать, если Крокфорда убьют Крокфорд уйдет? Типовой сеньор-помидор, посмотрев на код Крокфорда, выпучит глаза и закричит «ты где такое видел? Кто так делает? У тебя своя голова на плечах есть?».

Всё ли так безнадежно, и есть ли более-менее прикладные задачи, которые не сможет решить сеньор-принципал-архитектор даже в обнимку с цистерной смузи, даже выдавая по два заученных решения литкода в секунду? А может быть и есть. Например, быстрой инкрементальной Agile Scrum Kanban Fast-shipping Test Driven методикой постепенной разработки невозможно реализовать распределенную отказоустойчивую БД со строгой согласованностью данных. Отказоустойчивость — это бинарное свойство, БД либо отказоустойчива, либо нет. Не бывает почти отказоустойчивой приблизительно распределенной БД которая чуть ли не сохраняет все подтвержденные транзакции (привет разработчикам MongoDB). Ну то есть она в таком случае не отказоустойчива и не дает гарантий.

Даже Clickhouse можно почти сделать при достаточном стратегическом запасе смузи (только для единственного хоста), но яндекс так и не осилил аналога ZooKeeper (кластер ClickHouse работает через ZooKeeper), поскольку никакое количество костылей, инкрементально разработанных в Яндексе ранее, так и не смогли заменить одного грамотно продуманного решения. Что мы по итогу видим сейчас? Вся инфраструктура Яндекса стоит на ZooKeeper, найди возможность положить ZooKeeper — весь Яндекс встанет колом. Тот же Facebook тоже полагается на ZooKeeper (хоть и меньше, они там саги любят). В Amazon вообще всё печально, и я не поверю, что с любым количеством денег Amazon способен создать аналог ZooKeeper, поскольку я читал статьи их отдела по исследованию распределенных систем, и уровень там совершенно никакущий. Достоверно мне известна ровно одна контора, способная разрабатывать распределенные СУБД с гарантиями согласованности — это Google. Она разработала самое первое подобное решение, Google Chubby, близкой копией которого позже стал ZooKeeper.

Но вот в чем проблема — ZooKeeper уже есть, а значит «ты нам не нужен». Что же еще требует глубокого вдумчивого погружения и нестандартной находчивости? Похожие требования есть у многопоточных приложений. Еще подобного рода мышление нужно при тяжелой глубокой отладке софтины, на отладку которой систематически забивали, предпочитая спринты и быстрые релизы. Правда, с распространением защищенных сред выполенния, вроде JVM, CLR, JS, и Python, неустранимая потребность в отладке сильно снизилось, потому что в крайнем случае можно просто перезапустить контейнер или иметь запасные контейнеры сразу. (Еще есть UI/UX, но про мертвых либо хорошо, либо ничего).

Второй отягчающий фактор — обычно такие вечные дети-экспериментаторы любят знать всё про всё. Следствие — редко можно встретить такого экспериментатора, который знает единственную тематику очень-очень глубоко, как того требует конвверное производство софта. Например, я проектировал и собирал аналоговые схемы, я проектировал и моделировал логические схемы, изучал устройство процессоров и проектировал микроконтроллеры, в конце-концов начал работать программистом, вплоть до самого высокого уровня динамических языков программирования. Я знаком с компьютерами сверху донизу, но эти общие знания не помогают получить теплое место у конвеерной ленты (о чем я был давно осведомлен и систематически игнорировал этот фактор).

Третий отягчающий фактор — вечно детскими глазами не получается избавиться от «о боже, это срань, этим невозможно пользоваться». Вы могли заметить, что я довольно много писал на Си, но не потому, что мне так нравится этот язык — он просто чуть менее страшный и подходит для моих задач, в остальном же нет особой разницы, из чего лепить свою софтину.

Парадокс в том, что смузи-мастеры чуть ли не поголовно мечтают быть творцами. Какой смысл этого стремления? «Хорошо там, где нас нет»? «Полчаса побунтовал - и фатит»? Прежде чем окончательно и бесповоротно решить встать на этот путь, посмотрите на настоящих успешных творцов (не путать с клоунами вроде меня или Илона Маска). Такие люди не заработают заоблачных денег, их не расхватывают на рынке труда, им не так просто устроиться на обычную должность, а даже если устроятся — умрут со скуки, попутно занимаясь ремонтом того, что не ломалось, таким образом выведя из строя какой-нибудь старый добрый сервис на Cobol или MUMPS, написанный в 70-х годах «настоящими программистами, настоящими, не то что новое поколение».

Показательно, что работодатели идут навстречу этому стремлению, мол «пишешь конфиги для CI/CD? Ну ты же архитектор теперь». Аналитический склад ума нельзя поменять за месяц, его нельзя быстро приобрести или положить на полку на период отпуска. Wannabe-творец-на-выходные в лучшем создаст популярный клон существующего софта — даже не потому, что не способен ни на что другое, а потому, что понимает, что сообщество не примет ни одной значимой инновации серьезнее плагина к Emacs или очередных скрипт-костылей для сборки C++. Да и то, плагины к Emacs не нужны, поскольку уже есть настоящее проверенное решение в виде Vim и его аналогов.

И я не могу упрекать работодателей (как правильно заметил Kogrom по ссылке выше): им нужна взаимозаменяемость и предсказуемость, им нужно снижение рисков и издержек; им нужен посредственный сайт, который будет создавать иллюзию наличия этого сайта у компании — а больше и не нужно; заказчикам нужна иллюзия масштабирования и отказоустойчивости, с бессмысленными невыполнимыми требованиями к системы — выдайте ему микросервисную архитектуру со стоимостью и временем разработки в 3 раза больше грамотного монолита, также бонусом дайте ценные инструкции по масштабированию бигдата-серверов монги сверх 500 ГБ (на случай, если его бигдата размещается в кластере из айфонов). Можно упрекать разве что себя (мне — себя, а вам — себя, не меня). Например, много лет назад я имел возможность выбрать семью и карьеру, но я выбрал то, что выбрал — не иметь власти, но знать всё и ничего одновременно. В этом есть свой кайф и неудобство одновременно.

 , , , опус,

byko3y
()

RSS подписка на новые темы