LINUX.ORG.RU

Переоценен ли K8S/Docker с некоммерческой точки зрения?

 , , , ,


3

3

Привет всем,

Работаю с Docker/K8S еще с 2018 года. Примерно с того времени, все проекты как правило вертятся в рамках Kubernetes. Неважно как:

  • в виде managed-сервисов в облоках (GKE, AWS EKS)
  • в виде unmanaged на приватных bare-metal (через kubeadm)

Да, удобно. И прошу не закидывать данный сабж общими словами на тему:

  • Докер, это новый стандарт и удобный инструмент для сборки образов
  • что К8С удобен для быстрого поднятия сред и оркестрации приложений
  • что можно лимиты ставить, и решать проблемы зависимостей системных либ

Все это понятно, известно и излишнию маркетинговую рекламу делать не надо в данном сабже. Да, спасибо всем этим новыми технологиям, они в принципе дают з/п и формируют спрос/предложение на рынке.

Речь немного у другом. Я прочел недавно пост: https://lwn.net/Articles/676831/

И некоторые слова зацепили, как:

According to Walsh’s presentation, the root cause of the conflict is that the Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux. These include initialization, service activation, security, and logging. «In a lot of ways Docker wants to be systemd,» he claimed. "It dreams of being systemd."

Сейчас, я выражу непопулярную точкую зрения :) и возможно, даже «мамонтовскую» :) но лезут такие мысли в голову:

  1. Докер действительно вызывает малость ощущения systemd-wanna be в опреденном аспекте, касаемо управления приложений (не берем аспект формирования образов)
  2. Формировать лимиты по RAM, CPU и др., вполне можно через тот же systemd
  3. Для проблемы эмуляции файловой ОС, совсем необяз. залезать в Docker, есть systemd nspawn и возможность дергать Linux namespaces напрямую
  4. честно говоря совсем банальная мысль :) а чем вам сама ОС не является крутым оркестратором для приложений?

Что мне лично еще не нравится при работе с Докером и К8С:

  1. Есть ощущения излишних слоев абстракций и user mode виртуализаций. С учетом того, что большинство приложений сидит на Java, Python, NodeJS … Спрашивается, а такая ли в этом необходимость? Куда ни шло, если речь про C++ проекты, где возня с headers/линковой либ и др., где действительно есть «головная боль» в ряде моментов… Но, на Жабке или Питоне-то? Сомнительно…

  2. Учет GAPов, если вы админите условный OpenStack с виртуалками и чудо-менеджер туда еще сует Докер, то создаются впечатления, что я занимаюсь больше обслуживанием абстракций, нежели реально проектом и реальной необходимости бизнесу

  3. Много какого-то ненормального хайпа вокруг этой облачно-контейтнерной тематики, и создается впечатление, что больше хайп ради хайпа. И менеджеры… Просто устраивают некий шоубизнес в IT на данной теме (сугубо личное мнение :) )

  4. Народ, как будто бы, разучился работать со stateful-сервисами и понимать проблематику больших баз и пр. Появилось много хомячков, кто трындит про A/B, удобное перекидывание контейнеров между нодами, но очень забавно было наблюдать :) как условные хомячки пытаются юзать Postgres в рамках контейнеров, а под капотом юзать Ceph (да еще в добавок на вирт. машинах), а потом удивляться, что кластер РСУБД не может быстро работать :) Уйму слоев виртуализаций построили, хранилища - дистрибутивные, проблему синхронизаций stateful-сервисов не решают, IOPS падает :) но зато «в облачке и поды по нодам». Понятно, что в облаках накинули 1000 баксов, и проблемы производительности могут улетучатся, ну или вообще увести базы в отдельные managed-сервисы. Но, очень забавляют картины, когда пытаются решать вопросы high load на приватных серверах через призму огромного слоя виртуализаций.

P.S. повторюсь, что сказал в начале. Спасибо Докеру и К8С за работу/деньги. Но, персонально есть ощущения какой-то лабуды. Как по мне, вполне себе можно было бы даже в условном systemd вращать многие приложения без огромной прослойки виртуализаций. Иногда кажется, что лучше быть не хайповым и вне моды.



Последнее исправление: twinpeaks (всего исправлений: 1)

Ответ на: комментарий от anonymous

свое котячее ржавое ведро с вейпами и смуззями

Пофиксил

anonymous
()
Ответ на: комментарий от Legioner

Докер - юзай, его стоит юзать вообще всегда. Мне сложно придумать ситуацию, когда докер не стоит использовать. Нужно раскатывать свежие фиксы плейбуками прямо в прод.

Пофиксил.

anonymous
()
Ответ на: комментарий от anonymous

Ржавые смузибои за вами уже пришли. Включение -Werror в ведре по умолчанию не поможет тому, кто считает, что «нет ничего лучше, чем Си».

Webtoolkit — это С++. Это совсем другой язык, с некоторой долей обратной совместимости. Не надо приплюсовывать его возможности к Си.

За ссылку спасибо, пригодится.

aist1 ★★★
()
Ответ на: комментарий от aist1

Ржавые смузибои за вами уже пришли

Лишь бы потом и до Вас не добрались.

Webtoolkit — это С++. Это совсем другой язык,

А кресты как появились?

За ссылку спасибо, пригодится. Велком

anonymous
()
Ответ на: комментарий от anonymous

Лишь бы потом и до Вас не добрались.

(голосом Воландеморта) О, пусть приходят, мы их встретим.

Суть. Делаются расширения компилятора С++ для поддержки метафункций — полного множества языка (включая потоки и ввод-вывод) во время компиляции. Метафункции интегрированы с компилятором и с парсером, могут быть осведомлены о контексте, в котором вызваны и могут создавать AST. Они тесно интегрированы с системой сборки, работающей как сервер приложений и построенной над специализированной мультимодельной БД, которая так же может и в аналитику. Система сборки работает как BaaS и доступна через различные интерфейсы для интеграции как с обычными приложениями, так и с API.

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

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

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от anonymous

А кресты как появились?

Кресты появились такими, потому что у Страуструпа хватило чуйки сделать язык обратно совместимым с Си. Но это всё же совсем другой язык парадигмально.

aist1 ★★★
()
Ответ на: комментарий от aist1

Но все таки он делал надстройку. А базис то си. Поэтому корректнее считать, что си - это братство. (Одна языковая семья). Тем более в условиях, когда «кругом враги». :) которые уже и на ведро покусились.

anonymous
()
Ответ на: комментарий от anonymous

Мы сишников в обиду не дадим. Но на месте Линуса я бы уже активно смотрел в сторону какого нибудь безопасного диалекта Си. На критику придется ответить конструктивно.

aist1 ★★★
()
Ответ на: комментарий от aist1

Линус смотрит сейчас на инвойсы, к сожалению. Боюсь, что единственный выход - это раскол в сообществе. Брать ядрышко 2.6 или 2.8 точно по ченджлогу не помню, чтобы не соврать, но не принципиально в контексте вопроса и форкать.

anonymous
()
Ответ на: комментарий от anonymous

Ну, раскол, как last resort против позиции конкретного человека, которая перестала отвечать реалиям — да, можно.

Rust на самом деле C в ядре не угрожает, так как не является безопасным в строгом смысле этого слова. Там можно до какой-то степени контролировать UB через unsafe, но только и всего. Существующую базу кода он автоматически не сделает безопасной, а претензии именно к ней.

Тут нужен именно безопасный диалект Си, так как существующие код на него портировать будет на много проще, чем переписать на Rust. И нужна расширенная кодовая автоматизация типа такой, как я привел выше для C++. Всё, что могут писать программы, должны писать программы.

То же самое и с интернет-сервисами. Си нужны механизмы «программирования в большом» и средства автоматизации современного уровня. И всё будет хорошо!

aist1 ★★★
()
Ответ на: комментарий от aist1

Rust на самом деле C в ядре не угрожает

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

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

anonymous
()
Ответ на: комментарий от anonymous

В программировании всегда будет место для героев, но закладываться на них нельзя. Герои устают, они всегда уходят, и иногда они уходят внезапно. В этом и проблема Си, что это язык для героев. А надо, чтобы он стал языком для людей. Вот этих вот, которые чуть что, бегут смотреть котиков. Кому надо? Это надо накопленной кодовой базе и тем, кто её накапливал. Эту базу надо сохранить, а для этого её надо модернизировать. Вот возможность беспроблемного использования кодовой базы в таких новых контекстах, как контейнеризованные интернет-сервисы и есть критерий модернизации. Остальное — средство.

aist1 ★★★
()
Ответ на: комментарий от aist1

Окай. Рассмотрим пример из жизни. Вот есть сервер протокола матрикс - синапс. Оно было написано на пьюр языке для широких масс ака людей. Оно в проде уже 7 лет. Бекгрунд - амдокс. При этом по понятным причинам оно а) тормозит б) очень кривое. За 7 лет изменить ничего не смогли. Сами массы внезапно осознали ошибку и ушли перепиливать на го. Перестанет ли оно тормозить - скорее всего да. Перестанет ли глючить - с таким подходом скорее всего нет. Вопрос знатокам: как такой фундаментальный подход скажется на работе/жизненном цикле/бекграунде ядра? Ядро - это все-таки не мыло по тазику гонять…

anonymous
()
Ответ на: комментарий от anonymous

Тут всё просто. В ядре нужно выделять mission critical core и всё остальное. В mission critical жесткая диктатура do the right thing и децимация методом имения шваброй провинившихся. В том числе и Самого Главного, если «хрень закоммитит». Шутка.

В смысле, нужны две инженерные культуры, разделенные перегородкой. do the right thing — штука объективно дорогая, и такого кода не может быть много. Как бы этого ни хотелось, но писать всё по этой методологии не получится. В идеале это может быть микроядро, которое и разделило бы две разные инженерные культуры. Я в этом смысле с интересом смотрю на Фуксию и планирую там со storage поиграться-поэкспериментировать.

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

Т.е. один только Rust в ядре никаких проблем не решит. Защита, в том числе и от программных ошибок, должна поддерживаться аппаратно. Например, от ошибок обращения памяти — через использование тегированной памяти и т.п.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

В смысле, нужны две инженерные культуры, разделенные перегородкой. do the right thing — штука объективно дорогая, и такого кода не может быть много. Как бы этого ни хотелось, но писать всё по этой методологии не получится.

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

В идеале это может быть микроядро, которое и разделило бы две разные инженерные культуры

Кроме кунх и бб10 на его базе не припомню омобо чего-то успешного. (Всякие вещи из оборонок в расчет не берем. Оно совсем другое). Какая участь постигла все эти ваши хурды? А ведь пытались же…

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

Так верстает только татьяныч:) что про медленные микроядра эти люди говорят в контексте бб10?

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

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

anonymous
()
Ответ на: комментарий от anonymous

Ничего в ближайшее время не будет. Ядро как писалось на С, так и будет продолжать писАться. Будут блеймить, фыркать, строить из себя обиженок, но пользоваться, потому что ничего больше нет. xBSD? Там всё принципиально лучше?

Т.е. есть какое-то ненулевое время, скажем, лет 10. За которое процесс дойдет до гниения и разложения. За это время можно успеть решить критические проблемы аппаратно. Это вполне реально на горизонте 3-5 лет сделать для всякой эмбедщины. А потом и сервера подтянутся, если не раньше))

Пойми просто идею. У проблемы есть аппаратное решение, а программного — нет. Проблемы с ядром — это не проблемы организации процесса разработки. Это проблемы самой вычислительной архитектуры, которая тупо не задумывалась для задач, для которых используется. Эти проблемы нельзя решить поддержанием инженерной дисциплины. Тут даже герои бессильны. Тем более, что они тоже хотят work/life balance.

aist1 ★★★
()
Ответ на: комментарий от anonymous

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

aist1 ★★★
()
Ответ на: комментарий от aist1

Ничего в ближайшее время не будет

Вместе с тем рейдерский захват пинуса происходит здесь и сейчас. И с этим надо что-то делать. Потому что потеряв попен сцурс, мы потеряем много больше, чем просто ос с бесплатными програмулинками. Цена вопроса будет слишком высока. Жизнь с зондом она ведь подходит чуть больше чем не всем….

xBSD? Там всё принципиально лучше?

Бсди развиваются эволюционно, а не революционно и вот как раз в контексте нонешних событий это и станет прибежищем и тихой гаванью. На какое-то время…

скажем, лет 10 Этого времени нет! Есть 3-4 года

За это время можно успеть решить критические проблемы аппаратно Это вполне реально на горизонте 3-5 лет сделать для всякой эмбедщины

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

anonymous
()
Ответ на: комментарий от aist1

В теории же да. Относительно ядреных подходов к решению задачи Вы совершенно правы. Но есть лабораторная стерильность и реалии жизни…

Делать все это в фоновом режиме, когда над головой не висит дамоклов меч архиважно и нужно. Но сейчас не та ситуация.

anonymous
()
Ответ на: комментарий от anonymous

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

Ну или ты просто хочешь некоторого safe space, где темой будут править остатки здравого смысла, а не инвойсы. Это можно, и это даже нужно.

Что касается меня, то я на своем пути «ближе к железу» дошел до того, что начал проектировать специализированные процессоры (на базе risc-v) для storage и обработки данных. И у меня есть софт, который это железо сможет заутилизировать в любых физических объемах.

Так вот, там как раз очень нужны вот эти все фичи, о которых я говорил выше. Потому что целостность структурированных данных — это mission critical. И вот на этом может и ядро «выехать».

aist1 ★★★
()
Ответ на: комментарий от anonymous

С зондом, кормящим «нужной» «правильной» глюкозой

Пофиксил

anonymous
()
Ответ на: комментарий от aist1

Т.е. я будут создавать и материализовывать потребность в высокопроизводительном защищенном железе для задач хранения и обработки данных. И качеству ядра это тоже поможет.

ЗЫ. Ко мне здесь всегда и всем можно обращаться «на ты».

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 2)
Ответ на: комментарий от aist1

Форк можно сделать всегда

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

почему с форком должно быть что-то фундаментально иначе.

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

Ну или ты просто хочешь некоторого safe space, где темой будут править остатки здравого смысла, а не инвойсы. Это можно, и это даже нужно.

И это в том числе

Что касается меня, то я на своем пути «ближе к железу» дошел до того, что начал проектировать специализированные процессоры (на базе risc-v) для storage и обработки данных. И у меня есть софт, который это железо сможет заутилизировать в любых физических объемах.

То что Вы делаете - это есть хорошо и правильно! Остается только придумать как это вывести на рынок. Почему не взлетели все эти либремы пуризмы…?

anonymous
()
Ответ на: комментарий от aist1

Форк или сгниет под давлением продуктовиков и продажников, или маргинализируется

Не поверите, но во времена когда мы пилили ведро, все эти элементы были. Ничего, вон сколько продержались… И если бы на старости лет один человек не превратился в шкуру, все было бы вполне себе.

anonymous
()
Ответ на: комментарий от anonymous

Перетащить дрова и перепилить из новых фич действительно нужное, а так же эти фичи переосмыслив. На это очевидно нужно время

Я в этом ключе думал про Фуксию. Попробовать перетащить туда важные драйвера. Слышал, что так некоторые микроядерные ОС и делают.

Почему не взлетели все эти либремы пуризмы…?

Потому что (а) они не обещали чуда и (б) железо не было приспособлено пот такой тип IPC.

Остается только придумать как это вывести на рынок

Как обычно. Через хайп. Просто потому, что оно так работает.

aist1 ★★★
()
Ответ на: комментарий от aist1

Я в этом ключе думал про Фуксию.

Можно попробовать. Но оно совсем сырое еще. Сам ее не щупал. Толком ничего сказать не могу.

Потому что (а) они не обещали чуда и (б) железо не было приспособлено пот такой тип IPC.

Только лишь по этим причинам или есть что-то еще?

Как обычно. Через хайп. Просто потому, что оно так работает.

:)

За сим на сегодня откланяюс. Пора опочевать.

anonymous
()
Ответ на: комментарий от aist1

Еще одно резюме. Я выше сказал, что тот же Rust в принципе не решает. Когда он сам по себе. А в сочетании с аппаратной защитой памяти делает систему очень надежной. Потому что аппаратная защита будет исключать ситуации тихого повреждения памяти (самые страшные ошибки), а программная зашита будет сводить к возможному минимуму ситуации, когда процесс будет сброшен из-за внутренней ошибки. Всё это и создает mission critical.

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

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

aist1 ★★★
()
Ответ на: комментарий от anonymous

Но оно совсем сырое еще.

Сегодня оно сырое, а завтра уже в моем смартфоне. Такое же сырое, гы. Я, собственно, НЕ ЗА Фуксию. У меня в ней самой нет интереса. Это просто площадка для «поиграть», которую тащит корпорация. И на этом можно проехаться, пока тащит.

Только лишь по этим причинам или есть что-то еще?

Основная причина в том, что потери индустрии от ошибок в софте существенно меньше прибыли от этого софта. Вот когда «работать станет невозможно», вот тогда и зачешутся. Do the right thing сильно повышает издержки без ощутимых бенефитов.

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

aist1 ★★★
()
Ответ на: комментарий от aist1

Доброго времени суток! Позволю себе так поздороваться покуда отдельные неолиберальные альтернативно образованные деятели не отняли у меня это право. Такие нравы, такие времена.

Я выше сказал, что тот же Rust в принципе не решает. Когда он сам по себе. А в сочетании с аппаратной защитой памяти делает систему очень надежной.

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

Про аппаратную защиту памяти отпишу позднее в ходе дискуссии. Вы просто вдумайтесь в то, что там в трэде… и с этой позиции просто еще раз представьте кто и как будет пилить ядро. И это я молчу о том, что деды пилили его бесплатно, джаст фор фан. А смуззибои без кеша на вейпы этого делать не будут 100%

Это я все говорю исходя из того, что я вижу здесь и сейчас, в рф, в мск. У меня тлеет лишь последняя надежда на то, что те талантливые ребята, которые уехали, живут достойно и достойно трудятся. Может быть их окружают другие люди. Я не знаю, я хочу на это надеяться. И может быть эти люди осуществлят рывок. Но то что я вижу здесь и сейчас ввергает меня в шок. Я в страшном сне такого себе представить не мог. И это далеко не конец еще. Причем это не только на лоре, стоит мне выйти в магазин, поликлиннику, куда угодно. Вот такое везде.

Я только хочу сказать тем ребятам, которых когда-то я здесь же и убеждал/уговаривал не уезжать, ведь я искренне верил в завтрашний день: парни, вы были правы, а я был не прав. Живите достойно, трудитесь достойно и никого не слушайте. Творите! Все эти политики - это другое. Ваш труд - это достояние мира. А если вдруг в какой-то промозглый зимний вечер нахлынет тоска, включите наши фед каналы. Проникнитесь патриотизмом и живите дальше.

Тут хоть безопасные языки, хоть небезопасные. Опасность уже в головах.

anonymous
()
Ответ на: комментарий от aist1

Погуглите компанию cellebrite, ее специалисты вполне релевантно ответили насчет аппаратной защиты памяти. Безусловно в том контексте имеют место быть разные векторы…но тем не менее.

anonymous
()
Ответ на: комментарий от aist1

Как обычно. Через хайп. Просто потому, что оно так работает.

Да. Но есть один момент. Как только доля Вашего продукта на рынке составит чуть более, чем 0.1% к Вам придут и скажут что-то вроде: …Вы большой молодец, но Вы же не хотите чтобы башни падали, да? Поэтому будьте любезны передать нам… и казалось бы причем тут опен сорс и вот это вот все. Заработать, заработаете. Но доколе все будут зарабатывать, но фундаментально мало что отдавая взамен?! Памятуя так же о том, кто как и на каком ресурсе пилил все эти сигрупс етс.

Вот таки дела. Поэтому ничего эти защиты принципиально не изменят. Как с точки зрения человеческого фактора, так и административного.

anonymous
()
Ответ на: комментарий от anonymous

Зарабатывать конечно нужно! Но не нужно забывать и о истоках.

anonymous
()
Ответ на: комментарий от anonymous

Здесь не идет речь о криптозащите. А только о защите от программных ошибок. Т.е. чтобы соответствующие функции той же JVM взяло на себя железо.

aist1 ★★★
()
Ответ на: комментарий от aist1

У той компании не только по криптозащите. Но давайте сложим вместе все факторы: сам ржавый (не безупречный)+кул прогроммизды + «защита».

anonymous
()
Ответ на: комментарий от anonymous

И да, кто писать будет? На грантах, на зарплатах или на энтузиазме? Это на самом деле вопрос далеко не последнего порядка.

anonymous
()
Ответ на: комментарий от anonymous

Ты драматизируешь. Ну придут, ну скажут, ну поговорим. К тебе гораздо быстрее придут с юристами конкуренты, чем силовики с предложениями, от которых нельзя отказаться. Вести компанию в Америке — это такая херова туча различных рисков, начиная от регуляторов с их экспортным контролем и заканчивая БЛМщиками из соседнего гетто с ихними белыми фанбоями. И те проблемы, которые ты описываешь, они вообще на этом фоне не видны никак.

aist1 ★★★
()
Ответ на: комментарий от aist1

Да не драматизирую я. Они ко мне приходили на проекты. И делали такое, что пол головы поседело. В итоге наши же мигранты выручали. Вот таки дела. Я это все не на пустом месте.

anonymous
()
Ответ на: комментарий от anonymous

А это — правильный вопрос :)

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

У меня на этот вопрос нет ответа. Я свою часть написал и продолжу писать.

aist1 ★★★
()
Ответ на: комментарий от anonymous

Они ко мне приходили на проекты. И делали такое, что пол головы поседело.

Тут я не понял. К тебе силовики приходили с предложениями или ламеры из ветки про книжки по питону?)

aist1 ★★★
()
Ответ на: комментарий от aist1

Правильно! Отвечать надо только за себя и свою часть. Согласен. Но общий результат… вот поэтому я с грустью смотрю в завтрашний день.

anonymous
()
Ответ на: комментарий от aist1

Да это я ошибся. Извиняюсь. День специальной олимпиады сказывается, до сих пор в тонусе:) Не. Ламеры с крутейшими корочками из мерилин линчей, микрософтов и прочих оракулов. А на деле даже wpf ниасилили.

anonymous
()
Ответ на: комментарий от aist1

Вы мне вот что скажите пожалуйста, вот такое вот как в том трэде у Вас там есть? Если есть превуалирует ли?

anonymous
()
Ответ на: комментарий от anonymous

Ну что я могу сказать. Учителем в школе ты бы работать не смог)))

Оно всё сильно сложнее, чем хотелось бы, и работать придется с теми, кто есть.

«Других писателей у меня для товарища Поликарпова нет, а другого Поликарпова мы писателям найдем»

Приписывают И.В. Сталину.

aist1 ★★★
()
Ответ на: комментарий от aist1

работать придется с теми, кто есть.

Проще по моему не работать.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.