На Linux перешел уже с год как (на CentOS 9 Stream). Мотивировала, как ни странно, покупка двух 4к мониторов. Старенький ноутбук под Windows 10 категорически не тянул в 4к ни ютубик, ни обычные mkv файлы, лаги, всхлипы, артефакты, рев кулеров. Никакой гуглеж и переустановки драйверов не помогали.
После экспериментальной установки Linux (донастроить VLC оказалось не так тривиально, но достижимо) и 4к видео порешались, и обнаружился внезапный, прямо системный эффект.
Ноутбук от батареи стал работать четыре часа. А на винде его и на час не хватало. Сначала списал на какие-то кривые драйвера. Но потом тот-же эксперимент повторил на планшете Microsoft Surface Pro (уж под свое железо Microsoft драйвера должна была поставить как надо). Аналогичный эффект - время жизни от батареи и на Surface выросло в три раза. Потом еще потюнил всякие cpupower профили - догнал до четырехкратной продолжительности времени работы (серфинг, чтение почты и книг, фильмы, что там еще на ноуте в поездке делать можно).
Сравнивались системы "с нуля", не переутяжеленные всяким. Ну и то, что система занимает на диске стартово не 40 гигабайт с тенденцией дорасти "апдейтами" до 80, а лишь 5..6 гигабайт - тоже очень приятно удивило.
И вот этот момент с временем работы под батареей стал переломным, т.к. стало понятно, что в что-то Windows давно и безнадежно сломалось фоновыми процессами и службами, может они там подмайнивают биткоин через Defender, или что-то еще делают, но разница автономного времени в разы, а не в проценты - никак разумно не объяснялась. А просмотр процессов в свежеустановленной системе по TaskManager/Process Explorer вызывал только отчаяние и уныние, даже в сравнении с Windows XP/7.
В результате под CentOS удалось перетянуть практически все нужное для работы и отдыха. WinMerge заменяется на meld, WinAmp на Audacity, VLC конечно не MPC, но тоже можно пользоваться. Far3 заменяется на Far2L. Даже putty уже нативный есть и под линукс. VS Code, IDEA, Telegram, Chrome/Edge/Firefox, Inkscape - это все есть нативное и отлично работает с полпинка. А всякое бэкэндное и так уже давно под Linux крутилось.
Gnome конечно сразу на помойку, это не для людей писалось (вместе c Wayland). А вот какой XFCE4 на удивление хорошо работает и его можно легко донастроить до вида и поведения Windows 10.
С грехом пополам через flatpak можно поставить и даже вполне пользоваться OneNote и Todo (т.к. там Electron внутри). PaintBrush заменяется KolorPaint. Часть старого рабочего софта удалось запустить через Wine, но далеко не все.
Игрушки - вполне работают через Steam, но далеко не все, примерно половина ранее купленного, можно пережить. 1С с MS SQL Server отлично живут под линукс во всех современных вариантах, зачем там людям сейчас нужна Windows - вот прямо неведомая загадка.
А вот чего реально не хватает и это удручает (с необходимостью ставить VMWare Player):
Microsoft Visio - реальной альтернативы нет от слова совсем.
Microsoft Outlook - альтернативы реально нет. Для дома можно и вебками от gmail, mail.ru пользоваться, но для рабочей почты с митингами и расписаниями - увы.
Microsoft Excel - LibreOffice Calc откровенно недоделан, пользоваться можно, но для совсем примитивного. И тормозной, прожевать 200 метров .csv он не очень может.
CAD/CAM/CAE для инженерной или строительной деятельности - в линуксе c этим вообще все тотально грустно. Может быть выпустят Компас3Д нативный, но пока единственный способ выживать - это запускать это все через VMWare+Windows 7, в таком работает плохонько, но работает, а если нужно что-то прям масштабное и быстро, то велкам обратно в винду в DualBoot. FreeCAD - это удел для мазохистов, работать с этим до сих пор невозможно ни в каком виде.
Итого - для чисто домашнего использования Linux уже вполне годен и очень странно почему его не ставят всем массово. Для рабочих задач есть заметный дрейф вендоров (1С, Аскон, и т.д.) и скоро видимо совсем все хорошо станет и про Windows можно будет повсеместно начинать забывать. Но в текущем виде переход полностью невозможен и далеко не всегда тривиален. Но небезнадежен, т.к. уже сейчас практически все непереводимое можно попробовать убрать или под RDP, или под VMWare Player.
А вот что очень радует, так это то, что тебе можно забыть про putty, Cygwin, MSYS, X/Ming, WSL и прочие подобные костыли-ужасы. И главное - что уже можно навсегда забыть про cmd.exe и powershell, аллилуя.
Вот на этом ответе мы и выяснили причины переусложенения в софте, ура. Оказывается виноват банальный человеческий фактор стремления к "лучшим практикам" при отсутствии собственных опыта и решений, достаточных для цинично-рефлективных оценок "лучшести" этих самых чьих-то практик.
И этот поведенческий паттерн повторяется в абсолютно любой задаче.
Вот пример этой задачи деплоя: по сути нужно просто запаковать некий набор файлов и отправить на сервер(ы), там выполнить некий набор команд и перезапустить сервис. Заранее сложив артифакт после билда куда-то в хранилище с целью возможного отката в будущем. И... и все, там ничего больше и не надо.
Как работает циник с парой десятков лет опыта? Да, просто берет ssh+scp+git (svn|cvs|vcs), и deploy.sh с прошлого проекта (или просто загуглив), и вот тут решает эту задачу еще один раз на месте. Перебираем .sh скриптом имена хостов в цикле от строки в конфиге и просто делаем туда ssh коннекты и этим же скриптом выполняем там нужные команды (кстати удивительно мало кто знает что так вообще всегда возможно было делать). Это работало двадцать..тридцать прошлых лет и будет работать через двадцать лет, не требуя своего переписывания, покупки-переустановки всякого при каком обновлении операционки, перестройки сети, продаже бизнеса и прочих революциях. Ну конфиг с именами хостов разве поправить на новом месте. Ничего дополнительно ставить не надо, все идет в составе базового Linux дистрибутива, даже epel репозиторий не нужен.
А что делают горящие глаза и неутомимые руки+ноги "опытного специалиста"? Ну.... ставим RHEL или даже Ubuntu LTS, это понятно и скучно, и сразу по совету очень опытных товарищей туда крутим модные-актуальные K8S, Docker, Kinematic, рядом обязательно ставим Artifactory, Bitbucket, Ansible, Puppet. Не забываем про Logstash, Elastic, Graphana, Kibana, сверху обязательно какой мониторинг за этим всем, Zabbix уже не торт, берем Splunk, ну и все остальные нужные и полезные и обязательные штуки, уже лень их все перечислять (и это все тянет только на старте эдак на 100 гектар на диске и минимум 128 гектар оперативки, ибо там JVM везде), а иначе.... ой ой как страшно, иначе ведь этот самописный .sh скрипт для деплоя на целых 2кбайт размером и полтора экрана кода, написанный еще 15 лет назад, он же приведет к ужас чему:
И через Н итераций на паре десятков проектов вы приходите к аду и к необходимости тратить кучу времени на поддержание, к отсутствию идемпотентности и ещё к очень большому количеству проблем.
К идемпотенции! И потом к наверняка еще большим пока неведомым науке проблемам. Да. И потере какой критической потенции, стратегического фокуса и прочей всякой нужной разной очень важной компетенции. А что, разве поддерживать этот весь адок из установленного третьестороннего инфраструктурного софта совсем не надо, само всегда настраивается, работает и обновляется? И даже лицензий/денег не требует? Вопрос риторический.
И такой сценарий повторяется абсолютно во всем - вместо того, чтоб просто один раз сконцентрироваться на решении какой простой задачи вида "задеплоить пакет на хост и перезапустить там сервис" (и забыть уже на следующий день про нее) начинается эпопея обмазывания гигатонными слоями "лучших практик и отраслевых решений", создание целых отделов по поддержке этого всего, процессов. Митинги, созвоны. И ради чего? Просто ради принципиальной священной войны с непонятными и неприятными для глаз самописными bash скриптами и прочими "антипаттернами" (что не понимаем, то боимся и уничтожаем)? А что, ковыряться в Ansible или Docker скриптах стало уже более понятно и приятно, чем в bash? Или самописных скриптов и всяких странных конфигов прям совсем нигде не станет после установки всего этого великолепия? Да неужели?
все эти штуки, они не просто так получились и чем больше вы хотите зарабатывать бабок, тем больше вы задумаетесь об эффективности и надёжности.
Могу только поддержать всеми руками. Переключение раскладки по CapsLock в современных линуксах - это единственный разумный вариант. Сначала выглядит дико, потом привыкаешь и не понимаешь как жил раньше.
Попытки же привинтить Ctrl+Alt или Shift+Alt обречены на фиаско, в тех или иных программах перестают нормально работать шоткаты (ЕМНИП в far2l проблемы, где-то еще), плюс само переключение не гарантировано. Стандартная же комбинация Win-Space раздражает неимоверно - и растопыривать пальцы + грохот по ночам.
А под винду есть несколько мелких утлит, которые тоже позволяют настроить переключение по CapsLock - lswitch, recaps, какие-то еще.
И когда наступят последствия от его дурацких решений, в эпицентре будут другие люди. Разруливать будут другие и оплачивать будут другие.
Ой да ладно, разруливать. Там на "модном, правильном и сложном" уже в первый год после выкатки в прод обязательно случится эпическая замятня с банальным обновлением зависимостей и заморозка оных. А через три-четыре года это станет уже реальной проблемой, т.к. придет безопасник и будет уже прям совсем больно бить по рукам за непропатченные древние библиотеки, а пропатчить их не получится от слова совсем.
Т.к. найти людей с компетенцией и желанием ковыряться в каком уже напрочь устаревшем ануляро-джанго-ларавеле не получится за любые деньги, и придется брать вчерашних джунов с горящими глазами, которые все враз "быстро" с нуля перепишут на очередной модный нукст-солид-мобикс. На который на рынке через пять лет тоже не найдешь "специалистов".
Эти латте-смузи архитектурные приколы давно известны и видимо пока снисходительно прощаются бизнесами по лишь той причине, что бизнесу положено примерно раз в эти пять лет тотально с нуля переписывать-перерисовывать весь фронтэнд, чтоб чисто визуально не прослыть совсем замшелыми технолуддитами на фоне конкурентов. Ну и чтоб пользователи не скучали и чувствовали, что о них заботятся, и не разбегались к этим самым конкурентам от скрытой обиды и прочего ощущения обделенности вниманием. Вот так любители переусложненных новомодных архитектур и заказчики и нашли способ гармоничного сосуществования - вы нам позволяете играться от души за ваши немалые деньги, а мы создаем вам имидж технической продвинутости, трендовости и прогрессивности. До очередной пятилетней итерации "а не пора ли обновить нам наш сайт?".
но в докере в чём проблема? Он просто пакует окружение. Что тут сложного? ОПять же - а почему не ребит?
Проблема в том, что этих зверьков тоже нужно кому-то обслуживать, обновлять, патчить, мониторить. Если облако с "модной" инфрастуктурой есть уже купленное и работающее на смежных проектах, с приложенной тренированной DevOps командой, то ок, может быть и можно брать сразу на старте под новый проект, если всем так проще.
Но чаще всего проблема высосана из пальца, потому как весь этот докеркуберцирк легко заменяется простыми словами bash, ssh/scp, crontab, zip/unzip, chroot (если прям параноит секурность или зависимости по линковке сильно хитрые).
Да и build.sh, и даже deploy.sh - можно и из putty запускать, никакие teamcity для этого не обязательны. Ну разве что jenkins прикрутить, чтоб начальству веселые картинки показывать с кнопками, ему так менее тревожно, чем смотреть в черные экраны с непонятными буквами в стиле первой Матрицы.
Работают же эти простые слова везде и на старте из коробки, хитрой настройки, компетенций, экспертизы и прочей поддержки не требуют.
Тому, кто только что в первый раз прочитал паттерны (условно - Фаулера), обязательно нужно всё это опробовать в первом же самостоятельном проекте. :)
Там не только паттерны. Есть масса реальных примеров в вполне боевых проектах. Суть задачи - есть на входе ArrayList, нужно его отфильтровать и сделать другой ArrayList. Куда уже проще. Смотришь код - а там чего только не навалено - и Java Streams, и Spring Batch, лямбды, инъекции, Generics, какие-то бины с кодогенерацией из YAML. Потом берешь commit blame и идешь к "автору" с вопросом: "А на кой хрен ты тогда вот это все наложил тут?" Ответ огонь - "Да просто хотел попробовать Java Streams, но не было другой подходящей задачи". ОООК. Идешь ревьюверу и аппруверу (все же ходы записаны): "Как так, почему ты это все пропустил в мерж?" Ответ почти аналогичен: "Да я тоже всегда хотел попробовать Spring Batch, не мог найти под них задачу, а тут было очень интересно почитать разобраться, потестить, опыт для резюме". Парни, а что, сделать себе песочницу на гитхабе и там незаметно поиграть всяким друг с дружкой нет, так нельзя было? Этот вопрос впрочем остался без ответа.
Причины переусложения тривиальны - потому что нет естественных ограничителей.
Усложняют не потому что это реально нужно, а потому что никто и ничто не запрещает так делать. У настоящих инженеров и архитекторов (которые строят машины из металла и дома из железобетона) есть как минимум габаритные и весовые ограничения, и законы физики. Никто же не купит автомобиль размером с трехэтажный дом с энергопотреблением в пять мегатонн бензина на сотню км. Но в IT подобное вообще без проблем, ну купим новые серверы с терабайтом оперативки и 128 ядрами, делов то.
И у программистов это норма, они еще и посмеются над тобой, дескать если у тебя в автомобиле нет реактивного SPA салона с многоуровневыми микросервисами поддержки климата, задеплоенными в облако кубернетиса, да с отдельной командой DevOps на поддержке этого всего в гараже, то ты какой-то чепушила малоактуальный. А если ты не дай бог какие суммы по заказу посчитаешь просто в цикле, а не через распределенный MapReduce с асинхронной потоковой сериализацией через лямбда промисы с кастомными аннотациями с применением минимум сразу двух BoostSpringMobxNuxt$mol фреймворков - то все, сразу в джуны разжалуют и даже возле кофе машины перестанут здороваться.
Почему-то вспомнилась классика жанра: "вы напишите программу, которой сможет пользоваться любой идиот, но учтите, что только идиоты и будут ей пользоваться".
Все так, ИИ может "писать" код. Программисты будут не нужны. Но не только лишь не все.
1) Cамое злободневно актуальное - это современный шаблонизируемый "всратокод". Если на одну сторону положить подход от DSL штук вроде каких lsFusion, jHeadStart и т.д., когда разработчики просто описывают требования заказчка в терминах вида "вот табличка заказов в базе данных, а вот тут для нее экранная формочка - должна примерно так выглядеть и кнопочка сохранить чтоб была, и чтоб проверка остатка на складе", то весь остальной "особо ценный" промежуточный многократно наслоенный boilerplate код, да, изначально запросто генерируется по шаблонам (те самые React/Vue/Angular/Solid/Mobx/Django/Models/Controllers/View/ViewModel/Presenters/WebServices/Dockers/SQLs/CRUDs/JSONs/YAMLs/etc). С небольшими дополнениями "мяса" бизнес-логики и валидаций в строго нужных местах в этом всем сгенеренном.
Но это доступно было уже очень давно и без всякого xxxGPT, примерно со времен появления Unix утилиты M4, если не раньше.
Мерило же простое - допустим появляется задача добавить новое поле на экранную форму. Сколько раз и в скольких разных местах разработчику нужно теперь это новое имя поля вручную вписать? А сколько созвонов провести? PR-ов замержить? Если больше, чем в двух - то его действительно нужно заменять какой генерилкой кода от DSL модели (модель может быть и в виде произвольного текста, почему и нет). Но так это просто сейчас мейнстримовый технологический стек изначально кривой, от этого все проблемы. Вон в мире 1С это все и то давно уже решили (хоть и своеобразно), ничего нового и тут нет. Ну так напишите уже и популяризуйте в массах "нормальную", "современную", "правильную" и, ок, "вот желательно не 1С" платформу для сайтиков всяких разных бизнес задач с готовыми базовыми примерами-конфигурациями и типовыми шаблонами-решениями на все случаи жизни, будет всем в мире счастье и глобальное сокращение затрат на этих ваших frontend/backend developers с их "микросервисами".
2) А вот риторика и когнитивные приемы "популяризаторов" этих ваших xxxGPT, увы, довольно печально известны. Наброс через скандал, сценарии апокалипсиса, обещание революций, общественных потрясений через катаклизмы, голод, массовые увольнения и прочее сведение с ума методами политической пропаганды и манипуляции массовым созданием. Иначе никак внимание и новый раунд инвестиций совсем видимо не привлечь.
Но почему программисты первые идут на увольнение? Других успешных применений этого вашего генеративного ИИ совсем пока не нашлось? Водителей, бухгалтеров, копирайтеров, переводчиков, сисадминов, кладовщиков, продавцов и HR-ов заменили уже повсеместно грядущим Скайнетом? Еще нет? А почему? Обещались же. Что с ними пока не так?
Кстати, а вот уличные художники в парках с этим вашим "нарисуем портрет вашей жены по фотографии"? Ну уж их то эти ваши датацентры с мегаваттами GPU мощностей смогли забороть повсеместно, миллиардные инвестиции же не зря были затрачены? Или все еще держатся творцы кусочками угля и лаком по бумаге?
Современный айтишник это удаленщик. А удаленщику априори положено жить с семьей на природе-свежем воздухе в коттедже/ИЖС/на даче. Так что дачные темы вполне актуальны, ПМ-ам и каким синиорам в особенности.
Про "поддерживается все, что с 95 винды"- это мягко говоря уже не так. Можно попробовать поставить на Windows 10/11 популярные Win32 игрушки 2000-х или 90-х годов, и насладиться "совместимостью" по полной. Начать, к примеру, с Казаков
В моей группе в ВУЗе, 2000е годы, ИТ специальность, все сплошь золотомедалисты в прошлом - примерно 95% популяции студентов в принципе не смогли понять и использовать адресную арифметику С/С++. Даже на уровне лабораторных и курсовых работ. А ассемблер не смогли освоить 99% (вообще никто на потоке).
Популярность Javascript/Python и прочих подобных языков, где ссылочная модель памяти выломана на старте лишь подтверждает тезис, что в мире существуют области знаний, не доступные массам. Это как игра на гитаре или рисование. Или есть некие врожденные способности, или их нет, и никакой тренировкой их не достичь. ООП, как и многое другое - тут не исключение.
Я выше указал - что принципиального отличия между GOTO и расбрасыванием кода по десяткам методов в десятках файлов нет. Какая разница, как назван переход "куда-то там", вне зоны прямой видимости текущего файла с кодом? Да хоть функтором обзови, хоть лямда промисом, суть не меняется - вместо того, чтоб просто последовательно читать код как статью-книгу, в типовом ООП проекте ты вынужден постоянно прыгать по файлам-страницам в википедия стиле, пытаясь удержать в голове контекст и путь-иерархию вызовов.
Почему подобные прыжки туда-сюда-вверх-вниз в случае GOTO это очень плохо, а в случае ООП - это прям очень хорошо? Суть и там и там одна - логика разбросана хаотическим образом, при том что никакого code-reuse обычно не происходит - в подавляющем большинстве случаев тот или иной метод имеет как правило одного, ну очень редко два-три места вызова (если речь не идет про SDK или utility классы).
Ужасным - надо понимать "написан не так, как у всех остальных в настоящее время принято"?
У Егора вполне актуальная компиляция как вполне здравых идей (к слову, вовсе не авторских, в массе придуманных десятки лет до него). К примеру недопустимость NULL ссылок/указателей на составные объекты. Как и откровенных утопических ахиней: недопустимость мутаций объектов как всеобщее правило, которое приехало из мира этих ваших монад (где безусловно очень умные парни так и не смогли в итоге справиться с задачей эффективной реализации автоматического параллелизма произвольного кода, там всеобщий и тотальный запрет мутаций как источников состояний гонок хоть вполне был обоснован).
Но без целостной платформы (как минимум SDK), изначально построенной и верифицированной на всех этих отличных идеях - это все лишь идеализм, как и успешно почивший в бозе SICP (и иже). Выражаясь метафорически: если взять бочку меда и бочку навоза и смешать, то на выходе получатся лишь две бочки навоза, и стоило ли переплачивать?
Впрочем, у Егора и нет задачи создать новую платформу или парадигму - у него лишь цель срубить побольше хайпа на своих книгах и выступлениях, он сам честно признается, что работает менеджером, а код пишет только для личных pet-проектов по утрам. Классическое - не умеешь сам, учи других как надо?
Но в целом полистать его небесполезно и даже занимательно, особенно если потом задаться академической целью выяснить - откуда тот или иной особо ценный совет или техника были взяты и какие-где проблемы/задачи когда-то успешно или не очень пытались ими решить.
ООП не любят не за vtable, и не за множественно наследуемый полиморфизм b и прочее инкапсулирование. Реальная проблема лежит совсем в другой плоскости: GOTO
Изначально GOTO был объявлен вне закона по одной простой причине - программистам было сильно неудобно "прыгать" по страницам кода, пытаясь отследить и качественно протестировать логику потока управления. Т.е. в идеале все должно было быть последовательно-линейно, с небольшими вариациями ветвления в той самой типовой самой задаче преобразования данных из одного табличного вида в другой (которая составляет 99.9% всех современных проектов - от бухгалтерий до игродела и машинного обучения).
А что в ответ предложил ООП? Да ничего нового - лишь значительно более чудовищные формы GOTO, но лишь назвав их "по новому, по-заграничному":
Exceptions - особо извращенная форма GOTO (суть setjmp/longjmp), которая обычно, эдак в 99% случаев - даже не покрывается автотестами. Не прошло и 40 лет как это архитектурное фиаско тихо признали в Rust и Go, и на том спасибо
Наследование и полиморфизм, когда вместо типовых 50-60 строк кода в одной процедуре тебе при чтении чужого проекта нужно бегать по 30-ти методам размером в 2..5 строк кода каждый, разбросанных по 29 файлам (и это было названо образцом для подражания), уже на 7 хопе в IDE напрочь забывая окуда и зачем ты сюда вообще попал.
Список фиаско ООП идей можно продолжить (пройтись и по возведенным в абсолют макросам/копипасте кода по имени С++ templates, и по free/reuse memory-models vs obstack regions, и по CPU cache friendly Entity Component System, и даже по провалу UML в т.ч.), но "хитроумная" маскировка GOTO уже превращает весь этот фарс в комедию.
Истина скорее всего в том, что никто не хочет признаваться в неудаче. Эти все показатели эффективности 2.5кВт потребления и 10кВт теплоотдача - они номинальные в неких идеальных условиях (каких?).
Реалии же в том, что COP резко падает при росте дельты температур. Т.е. если +7С еще можно превратить в +35С с COP=4, при использовании продвинутых фреонов, то если задаться целью нагреть воду до +55С, то COP может упасть до 2, а то и ниже. Т.е. к поправке "работаем только с ночным тарифом" нужно добавить "и обязательно используем только теплый пол / шведскую плиту, про существующие настенные радиаторы можем сразу забыть". И на этом моменте уже можно заканчивать эту эпопею с тепловыми насосами.
А потом еще выяснится что компрессор не работает с пониженным напряжением (все в поселке врубили ТЭНы и просело до 195V в сети), т.е. нужно докупать инвертор на 5кВт, что охлаждать колодезную воду до +1С нельзя, только до +4С, ибо оледенение, и вместо 1.5 тонны воды нужно качать все 3 тонны в час. И что за неделю в овраге наморозило гору льда или закупорило все трубы сброса канализации.... Гладко было на бумаге.
Хотя как вариант pet-проекта "собери себе сам игрушку", из китайского компрессора с Arduino контроллером, с окупаемостью затрат в 135 лет - почему и нет?
В расчетах выше я ошибся, цена киловатта тепла при газовом отоплении будет около 0.8 рублей (не 0.5р), кубометр газа дает примерно 10кВт, и магистральный стоит примерно 8 рублей.
А вот тепловой насос вода-вода при COP=3..4 и ночном тарифе Т2 (2.27к за квтч) теоретически даст 0.57..0.76 рублей за тепловой киловатт, если суметь эти добытые ночью 280кВт каким-то образом саккамулировать: тонны нагретой воды в бочках, прогретые бетонные стены и перекрытия, т.е. теоретические расчеты вовсе небезнадежны. Продавцы систем вода-вода также говорят о примерно одинаковых сезонных затратах в сравнении с магистральным газом, но умалчивают что это возможно лишь при ночном тарифе на ЭЭ.
Жаль только что практически нет реальных отзывов счастливых владельцев, одна только реклама от подрядчиков и эмоции "экспертов-теоретиков" в ютубике, и вот тут странно почему так, при том что отзывы счастливых владельцев систем воздух-воздух или воздух-вода, с цифрами затрат, наоборот - есть в больших количествах.
На Linux перешел уже с год как (на CentOS 9 Stream). Мотивировала, как ни странно, покупка двух 4к мониторов. Старенький ноутбук под Windows 10 категорически не тянул в 4к ни ютубик, ни обычные mkv файлы, лаги, всхлипы, артефакты, рев кулеров. Никакой гуглеж и переустановки драйверов не помогали.
После экспериментальной установки Linux (донастроить VLC оказалось не так тривиально, но достижимо) и 4к видео порешались, и обнаружился внезапный, прямо системный эффект.
Ноутбук от батареи стал работать четыре часа. А на винде его и на час не хватало. Сначала списал на какие-то кривые драйвера. Но потом тот-же эксперимент повторил на планшете Microsoft Surface Pro (уж под свое железо Microsoft драйвера должна была поставить как надо). Аналогичный эффект - время жизни от батареи и на Surface выросло в три раза. Потом еще потюнил всякие cpupower профили - догнал до четырехкратной продолжительности времени работы (серфинг, чтение почты и книг, фильмы, что там еще на ноуте в поездке делать можно).
Сравнивались системы "с нуля", не переутяжеленные всяким. Ну и то, что система занимает на диске стартово не 40 гигабайт с тенденцией дорасти "апдейтами" до 80, а лишь 5..6 гигабайт - тоже очень приятно удивило.
И вот этот момент с временем работы под батареей стал переломным, т.к. стало понятно, что в что-то Windows давно и безнадежно сломалось фоновыми процессами и службами, может они там подмайнивают биткоин через Defender, или что-то еще делают, но разница автономного времени в разы, а не в проценты - никак разумно не объяснялась. А просмотр процессов в свежеустановленной системе по TaskManager/Process Explorer вызывал только отчаяние и уныние, даже в сравнении с Windows XP/7.
В результате под CentOS удалось перетянуть практически все нужное для работы и отдыха. WinMerge заменяется на meld, WinAmp на Audacity, VLC конечно не MPC, но тоже можно пользоваться. Far3 заменяется на Far2L. Даже putty уже нативный есть и под линукс. VS Code, IDEA, Telegram, Chrome/Edge/Firefox, Inkscape - это все есть нативное и отлично работает с полпинка. А всякое бэкэндное и так уже давно под Linux крутилось.
Gnome конечно сразу на помойку, это не для людей писалось (вместе c Wayland). А вот какой XFCE4 на удивление хорошо работает и его можно легко донастроить до вида и поведения Windows 10.
С грехом пополам через flatpak можно поставить и даже вполне пользоваться OneNote и Todo (т.к. там Electron внутри). PaintBrush заменяется KolorPaint. Часть старого рабочего софта удалось запустить через Wine, но далеко не все.
Игрушки - вполне работают через Steam, но далеко не все, примерно половина ранее купленного, можно пережить. 1С с MS SQL Server отлично живут под линукс во всех современных вариантах, зачем там людям сейчас нужна Windows - вот прямо неведомая загадка.
А вот чего реально не хватает и это удручает (с необходимостью ставить VMWare Player):
Microsoft Visio - реальной альтернативы нет от слова совсем.
Microsoft Outlook - альтернативы реально нет. Для дома можно и вебками от gmail, mail.ru пользоваться, но для рабочей почты с митингами и расписаниями - увы.
Microsoft Excel - LibreOffice Calc откровенно недоделан, пользоваться можно, но для совсем примитивного. И тормозной, прожевать 200 метров .csv он не очень может.
CAD/CAM/CAE для инженерной или строительной деятельности - в линуксе c этим вообще все тотально грустно. Может быть выпустят Компас3Д нативный, но пока единственный способ выживать - это запускать это все через VMWare+Windows 7, в таком работает плохонько, но работает, а если нужно что-то прям масштабное и быстро, то велкам обратно в винду в DualBoot. FreeCAD - это удел для мазохистов, работать с этим до сих пор невозможно ни в каком виде.
Итого - для чисто домашнего использования Linux уже вполне годен и очень странно почему его не ставят всем массово. Для рабочих задач есть заметный дрейф вендоров (1С, Аскон, и т.д.) и скоро видимо совсем все хорошо станет и про Windows можно будет повсеместно начинать забывать. Но в текущем виде переход полностью невозможен и далеко не всегда тривиален. Но небезнадежен, т.к. уже сейчас практически все непереводимое можно попробовать убрать или под RDP, или под VMWare Player.
А вот что очень радует, так это то, что тебе можно забыть про putty, Cygwin, MSYS, X/Ming, WSL и прочие подобные костыли-ужасы. И главное - что уже можно навсегда забыть про cmd.exe и powershell, аллилуя.
Вот на этом ответе мы и выяснили причины переусложенения в софте, ура. Оказывается виноват банальный человеческий фактор стремления к "лучшим практикам" при отсутствии собственных опыта и решений, достаточных для цинично-рефлективных оценок "лучшести" этих самых чьих-то практик.
И этот поведенческий паттерн повторяется в абсолютно любой задаче.
Вот пример этой задачи деплоя: по сути нужно просто запаковать некий набор файлов и отправить на сервер(ы), там выполнить некий набор команд и перезапустить сервис. Заранее сложив артифакт после билда куда-то в хранилище с целью возможного отката в будущем. И... и все, там ничего больше и не надо.
Как работает циник с парой десятков лет опыта? Да, просто берет ssh+scp+git (svn|cvs|vcs), и deploy.sh с прошлого проекта (или просто загуглив), и вот тут решает эту задачу еще один раз на месте. Перебираем .sh скриптом имена хостов в цикле от строки в конфиге и просто делаем туда ssh коннекты и этим же скриптом выполняем там нужные команды (кстати удивительно мало кто знает что так вообще всегда возможно было делать). Это работало двадцать..тридцать прошлых лет и будет работать через двадцать лет, не требуя своего переписывания, покупки-переустановки всякого при каком обновлении операционки, перестройки сети, продаже бизнеса и прочих революциях. Ну конфиг с именами хостов разве поправить на новом месте. Ничего дополнительно ставить не надо, все идет в составе базового Linux дистрибутива, даже epel репозиторий не нужен.
А что делают горящие глаза и неутомимые руки+ноги "опытного специалиста"? Ну.... ставим RHEL или даже Ubuntu LTS, это понятно и скучно, и сразу по совету очень опытных товарищей туда крутим модные-актуальные K8S, Docker, Kinematic, рядом обязательно ставим Artifactory, Bitbucket, Ansible, Puppet. Не забываем про Logstash, Elastic, Graphana, Kibana, сверху обязательно какой мониторинг за этим всем, Zabbix уже не торт, берем Splunk, ну и все остальные нужные и полезные и обязательные штуки, уже лень их все перечислять (и это все тянет только на старте эдак на 100 гектар на диске и минимум 128 гектар оперативки, ибо там JVM везде), а иначе.... ой ой как страшно, иначе ведь этот самописный .sh скрипт для деплоя на целых 2кбайт размером и полтора экрана кода, написанный еще 15 лет назад, он же приведет к ужас чему:
К идемпотенции! И потом к наверняка еще большим пока неведомым науке проблемам. Да. И потере какой критической потенции, стратегического фокуса и прочей всякой нужной разной очень важной компетенции. А что, разве поддерживать этот весь адок из установленного третьестороннего инфраструктурного софта совсем не надо, само всегда настраивается, работает и обновляется? И даже лицензий/денег не требует? Вопрос риторический.
И такой сценарий повторяется абсолютно во всем - вместо того, чтоб просто один раз сконцентрироваться на решении какой простой задачи вида "задеплоить пакет на хост и перезапустить там сервис" (и забыть уже на следующий день про нее) начинается эпопея обмазывания гигатонными слоями "лучших практик и отраслевых решений", создание целых отделов по поддержке этого всего, процессов. Митинги, созвоны. И ради чего? Просто ради принципиальной священной войны с непонятными и неприятными для глаз самописными bash скриптами и прочими "антипаттернами" (что не понимаем, то боимся и уничтожаем)? А что, ковыряться в Ansible или Docker скриптах стало уже более понятно и приятно, чем в bash? Или самописных скриптов и всяких странных конфигов прям совсем нигде не станет после установки всего этого великолепия? Да неужели?
"А вот это уже печально" (с) Тинькофф
Могу только поддержать всеми руками. Переключение раскладки по CapsLock в современных линуксах - это единственный разумный вариант. Сначала выглядит дико, потом привыкаешь и не понимаешь как жил раньше.
Попытки же привинтить Ctrl+Alt или Shift+Alt обречены на фиаско, в тех или иных программах перестают нормально работать шоткаты (ЕМНИП в far2l проблемы, где-то еще), плюс само переключение не гарантировано. Стандартная же комбинация Win-Space раздражает неимоверно - и растопыривать пальцы + грохот по ночам.
А под винду есть несколько мелких утлит, которые тоже позволяют настроить переключение по CapsLock - lswitch, recaps, какие-то еще.
Ой да ладно, разруливать. Там на "модном, правильном и сложном" уже в первый год после выкатки в прод обязательно случится эпическая замятня с банальным обновлением зависимостей и заморозка оных. А через три-четыре года это станет уже реальной проблемой, т.к. придет безопасник и будет уже прям совсем больно бить по рукам за непропатченные древние библиотеки, а пропатчить их не получится от слова совсем.
Т.к. найти людей с компетенцией и желанием ковыряться в каком уже напрочь устаревшем ануляро-джанго-ларавеле не получится за любые деньги, и придется брать вчерашних джунов с горящими глазами, которые все враз "быстро" с нуля перепишут на очередной модный нукст-солид-мобикс. На который на рынке через пять лет тоже не найдешь "специалистов".
Эти латте-смузи архитектурные приколы давно известны и видимо пока снисходительно прощаются бизнесами по лишь той причине, что бизнесу положено примерно раз в эти пять лет тотально с нуля переписывать-перерисовывать весь фронтэнд, чтоб чисто визуально не прослыть совсем замшелыми технолуддитами на фоне конкурентов. Ну и чтоб пользователи не скучали и чувствовали, что о них заботятся, и не разбегались к этим самым конкурентам от скрытой обиды и прочего ощущения обделенности вниманием. Вот так любители переусложненных новомодных архитектур и заказчики и нашли способ гармоничного сосуществования - вы нам позволяете играться от души за ваши немалые деньги, а мы создаем вам имидж технической продвинутости, трендовости и прогрессивности. До очередной пятилетней итерации "а не пора ли обновить нам наш сайт?".
Проблема в том, что этих зверьков тоже нужно кому-то обслуживать, обновлять, патчить, мониторить. Если облако с "модной" инфрастуктурой есть уже купленное и работающее на смежных проектах, с приложенной тренированной DevOps командой, то ок, может быть и можно брать сразу на старте под новый проект, если всем так проще.
Но чаще всего проблема высосана из пальца, потому как весь этот докеркуберцирк легко заменяется простыми словами bash, ssh/scp, crontab, zip/unzip, chroot (если прям параноит секурность или зависимости по линковке сильно хитрые).
Да и build.sh, и даже deploy.sh - можно и из putty запускать, никакие teamcity для этого не обязательны. Ну разве что jenkins прикрутить, чтоб начальству веселые картинки показывать с кнопками, ему так менее тревожно, чем смотреть в черные экраны с непонятными буквами в стиле первой Матрицы.
Работают же эти простые слова везде и на старте из коробки, хитрой настройки, компетенций, экспертизы и прочей поддержки не требуют.
Там не только паттерны. Есть масса реальных примеров в вполне боевых проектах. Суть задачи - есть на входе ArrayList, нужно его отфильтровать и сделать другой ArrayList. Куда уже проще. Смотришь код - а там чего только не навалено - и Java Streams, и Spring Batch, лямбды, инъекции, Generics, какие-то бины с кодогенерацией из YAML. Потом берешь commit blame и идешь к "автору" с вопросом: "А на кой хрен ты тогда вот это все наложил тут?" Ответ огонь - "Да просто хотел попробовать Java Streams, но не было другой подходящей задачи". ОООК. Идешь ревьюверу и аппруверу (все же ходы записаны): "Как так, почему ты это все пропустил в мерж?" Ответ почти аналогичен: "Да я тоже всегда хотел попробовать Spring Batch, не мог найти под них задачу, а тут было очень интересно почитать разобраться, потестить, опыт для резюме".
Парни, а что, сделать себе песочницу на гитхабе и там незаметно поиграть всяким друг с дружкой нет, так нельзя было? Этот вопрос впрочем остался без ответа.
Причины переусложения тривиальны - потому что нет естественных ограничителей.
Усложняют не потому что это реально нужно, а потому что никто и ничто не запрещает так делать. У настоящих инженеров и архитекторов (которые строят машины из металла и дома из железобетона) есть как минимум габаритные и весовые ограничения, и законы физики. Никто же не купит автомобиль размером с трехэтажный дом с энергопотреблением в пять мегатонн бензина на сотню км. Но в IT подобное вообще без проблем, ну купим новые серверы с терабайтом оперативки и 128 ядрами, делов то.
И у программистов это норма, они еще и посмеются над тобой, дескать если у тебя в автомобиле нет реактивного SPA салона с многоуровневыми микросервисами поддержки климата, задеплоенными в облако кубернетиса, да с отдельной командой DevOps на поддержке этого всего в гараже, то ты какой-то чепушила малоактуальный. А если ты не дай бог какие суммы по заказу посчитаешь просто в цикле, а не через распределенный MapReduce с асинхронной потоковой сериализацией через лямбда промисы с кастомными аннотациями с применением минимум сразу двух BoostSpringMobxNuxt$mol фреймворков - то все, сразу в джуны разжалуют и даже возле кофе машины перестанут здороваться.
Почему-то вспомнилась классика жанра: "вы напишите программу, которой сможет пользоваться любой идиот, но учтите, что только идиоты и будут ей пользоваться".
Все так, ИИ может "писать" код. Программисты будут не нужны. Но не только лишь не все.
1) Cамое злободневно актуальное - это современный шаблонизируемый "всратокод". Если на одну сторону положить подход от DSL штук вроде каких lsFusion, jHeadStart и т.д., когда разработчики просто описывают требования заказчка в терминах вида "вот табличка заказов в базе данных, а вот тут для нее экранная формочка - должна примерно так выглядеть и кнопочка сохранить чтоб была, и чтоб проверка остатка на складе", то весь остальной "особо ценный" промежуточный многократно наслоенный boilerplate код, да, изначально запросто генерируется по шаблонам (те самые React/Vue/Angular/Solid/Mobx/Django/Models/Controllers/View/ViewModel/Presenters/WebServices/Dockers/SQLs/CRUDs/JSONs/YAMLs/etc). С небольшими дополнениями "мяса" бизнес-логики и валидаций в строго нужных местах в этом всем сгенеренном.
Но это доступно было уже очень давно и без всякого xxxGPT, примерно со времен появления Unix утилиты M4, если не раньше.
Мерило же простое - допустим появляется задача добавить новое поле на экранную форму. Сколько раз и в скольких разных местах разработчику нужно теперь это новое имя поля вручную вписать? А сколько созвонов провести? PR-ов замержить? Если больше, чем в двух - то его действительно нужно заменять какой генерилкой кода от DSL модели (модель может быть и в виде произвольного текста, почему и нет). Но так это просто сейчас мейнстримовый технологический стек изначально кривой, от этого все проблемы. Вон в мире 1С это все и то давно уже решили (хоть и своеобразно), ничего нового и тут нет. Ну так напишите уже и популяризуйте в массах "нормальную", "современную", "правильную" и, ок, "вот желательно не 1С" платформу для сайтиков всяких разных бизнес задач с готовыми базовыми примерами-конфигурациями и типовыми шаблонами-решениями на все случаи жизни, будет всем в мире счастье и глобальное сокращение затрат на этих ваших frontend/backend developers с их "микросервисами".
2) А вот риторика и когнитивные приемы "популяризаторов" этих ваших xxxGPT, увы, довольно печально известны. Наброс через скандал, сценарии апокалипсиса, обещание революций, общественных потрясений через катаклизмы, голод, массовые увольнения и прочее сведение с ума методами политической пропаганды и манипуляции массовым созданием. Иначе никак внимание и новый раунд инвестиций совсем видимо не привлечь.
Но почему программисты первые идут на увольнение? Других успешных применений этого вашего генеративного ИИ совсем пока не нашлось? Водителей, бухгалтеров, копирайтеров, переводчиков, сисадминов, кладовщиков, продавцов и HR-ов заменили уже повсеместно грядущим Скайнетом? Еще нет? А почему? Обещались же. Что с ними пока не так?
Кстати, а вот уличные художники в парках с этим вашим "нарисуем портрет вашей жены по фотографии"? Ну уж их то эти ваши датацентры с мегаваттами GPU мощностей смогли забороть повсеместно, миллиардные инвестиции же не зря были затрачены? Или все еще держатся творцы кусочками угля и лаком по бумаге?
Русскоязычную школу для детей вместе с собой на Бали брать? Сразу с учителями и одноклассниками?
Современный айтишник это удаленщик. А удаленщику априори положено жить с семьей на природе-свежем воздухе в коттедже/ИЖС/на даче. Так что дачные темы вполне актуальны, ПМ-ам и каким синиорам в особенности.
Про "поддерживается все, что с 95 винды"- это мягко говоря уже не так. Можно попробовать поставить на Windows 10/11 популярные Win32 игрушки 2000-х или 90-х годов, и насладиться "совместимостью" по полной. Начать, к примеру, с Казаков
В моей группе в ВУЗе, 2000е годы, ИТ специальность, все сплошь золотомедалисты в прошлом - примерно 95% популяции студентов в принципе не смогли понять и использовать адресную арифметику С/С++. Даже на уровне лабораторных и курсовых работ. А ассемблер не смогли освоить 99% (вообще никто на потоке).
Популярность Javascript/Python и прочих подобных языков, где ссылочная модель памяти выломана на старте лишь подтверждает тезис, что в мире существуют области знаний, не доступные массам. Это как игра на гитаре или рисование. Или есть некие врожденные способности, или их нет, и никакой тренировкой их не достичь. ООП, как и многое другое - тут не исключение.
Более 9 лет назад: https://habr.com/ru/articles/282986/
Я выше указал - что принципиального отличия между GOTO и расбрасыванием кода по десяткам методов в десятках файлов нет. Какая разница, как назван переход "куда-то там", вне зоны прямой видимости текущего файла с кодом? Да хоть функтором обзови, хоть лямда промисом, суть не меняется - вместо того, чтоб просто последовательно читать код как статью-книгу, в типовом ООП проекте ты вынужден постоянно прыгать по файлам-страницам в википедия стиле, пытаясь удержать в голове контекст и путь-иерархию вызовов.
Почему подобные прыжки туда-сюда-вверх-вниз в случае GOTO это очень плохо, а в случае ООП - это прям очень хорошо? Суть и там и там одна - логика разбросана хаотическим образом, при том что никакого code-reuse обычно не происходит - в подавляющем большинстве случаев тот или иной метод имеет как правило одного, ну очень редко два-три места вызова (если речь не идет про SDK или utility классы).
Ужасным - надо понимать "написан не так, как у всех остальных в настоящее время принято"?
У Егора вполне актуальная компиляция как вполне здравых идей (к слову, вовсе не авторских, в массе придуманных десятки лет до него). К примеру недопустимость NULL ссылок/указателей на составные объекты. Как и откровенных утопических ахиней: недопустимость мутаций объектов как всеобщее правило, которое приехало из мира этих ваших монад (где безусловно очень умные парни так и не смогли в итоге справиться с задачей эффективной реализации автоматического параллелизма произвольного кода, там всеобщий и тотальный запрет мутаций как источников состояний гонок хоть вполне был обоснован).
Но без целостной платформы (как минимум SDK), изначально построенной и верифицированной на всех этих отличных идеях - это все лишь идеализм, как и успешно почивший в бозе SICP (и иже). Выражаясь метафорически: если взять бочку меда и бочку навоза и смешать, то на выходе получатся лишь две бочки навоза, и стоило ли переплачивать?
Впрочем, у Егора и нет задачи создать новую платформу или парадигму - у него лишь цель срубить побольше хайпа на своих книгах и выступлениях, он сам честно признается, что работает менеджером, а код пишет только для личных pet-проектов по утрам. Классическое - не умеешь сам, учи других как надо?
Но в целом полистать его небесполезно и даже занимательно, особенно если потом задаться академической целью выяснить - откуда тот или иной особо ценный совет или техника были взяты и какие-где проблемы/задачи когда-то успешно или не очень пытались ими решить.
Можно еще и SICP вспомнить, там тоже было много хороших и правильных идей, примерно такой-же практической ценности.
ООП не любят не за vtable, и не за множественно наследуемый полиморфизм b и прочее инкапсулирование. Реальная проблема лежит совсем в другой плоскости: GOTO
Изначально GOTO был объявлен вне закона по одной простой причине - программистам было сильно неудобно "прыгать" по страницам кода, пытаясь отследить и качественно протестировать логику потока управления. Т.е. в идеале все должно было быть последовательно-линейно, с небольшими вариациями ветвления в той самой типовой самой задаче преобразования данных из одного табличного вида в другой (которая составляет 99.9% всех современных проектов - от бухгалтерий до игродела и машинного обучения).
А что в ответ предложил ООП? Да ничего нового - лишь значительно более чудовищные формы GOTO, но лишь назвав их "по новому, по-заграничному":
Exceptions - особо извращенная форма GOTO (суть setjmp/longjmp), которая обычно, эдак в 99% случаев - даже не покрывается автотестами. Не прошло и 40 лет как это архитектурное фиаско тихо признали в Rust и Go, и на том спасибо
Наследование и полиморфизм, когда вместо типовых 50-60 строк кода в одной процедуре тебе при чтении чужого проекта нужно бегать по 30-ти методам размером в 2..5 строк кода каждый, разбросанных по 29 файлам (и это было названо образцом для подражания), уже на 7 хопе в IDE напрочь забывая окуда и зачем ты сюда вообще попал.
Список фиаско ООП идей можно продолжить (пройтись и по возведенным в абсолют макросам/копипасте кода по имени С++ templates, и по free/reuse memory-models vs obstack regions, и по CPU cache friendly Entity Component System, и даже по провалу UML в т.ч.), но "хитроумная" маскировка GOTO уже превращает весь этот фарс в комедию.
Истина скорее всего в том, что никто не хочет признаваться в неудаче. Эти все показатели эффективности 2.5кВт потребления и 10кВт теплоотдача - они номинальные в неких идеальных условиях (каких?).
Реалии же в том, что COP резко падает при росте дельты температур. Т.е. если +7С еще можно превратить в +35С с COP=4, при использовании продвинутых фреонов, то если задаться целью нагреть воду до +55С, то COP может упасть до 2, а то и ниже. Т.е. к поправке "работаем только с ночным тарифом" нужно добавить "и обязательно используем только теплый пол / шведскую плиту, про существующие настенные радиаторы можем сразу забыть". И на этом моменте уже можно заканчивать эту эпопею с тепловыми насосами.
А потом еще выяснится что компрессор не работает с пониженным напряжением (все в поселке врубили ТЭНы и просело до 195V в сети), т.е. нужно докупать инвертор на 5кВт, что охлаждать колодезную воду до +1С нельзя, только до +4С, ибо оледенение, и вместо 1.5 тонны воды нужно качать все 3 тонны в час. И что за неделю в овраге наморозило гору льда или закупорило все трубы сброса канализации.... Гладко было на бумаге.
Хотя как вариант pet-проекта "собери себе сам игрушку", из китайского компрессора с Arduino контроллером, с окупаемостью затрат в 135 лет - почему и нет?
В расчетах выше я ошибся, цена киловатта тепла при газовом отоплении будет около 0.8 рублей (не 0.5р), кубометр газа дает примерно 10кВт, и магистральный стоит примерно 8 рублей.
А вот тепловой насос вода-вода при COP=3..4 и ночном тарифе Т2 (2.27к за квтч) теоретически даст 0.57..0.76 рублей за тепловой киловатт, если суметь эти добытые ночью 280кВт каким-то образом саккамулировать: тонны нагретой воды в бочках, прогретые бетонные стены и перекрытия, т.е. теоретические расчеты вовсе небезнадежны. Продавцы систем вода-вода также говорят о примерно одинаковых сезонных затратах в сравнении с магистральным газом, но умалчивают что это возможно лишь при ночном тарифе на ЭЭ.
Жаль только что практически нет реальных отзывов счастливых владельцев, одна только реклама от подрядчиков и эмоции "экспертов-теоретиков" в ютубике, и вот тут странно почему так, при том что отзывы счастливых владельцев систем воздух-воздух или воздух-вода, с цифрами затрат, наоборот - есть в больших количествах.