никуда он не уйдет, и дома его (виндовс) будут исполхьовать по инерции. Если что у меня убунту дома, но я реально сомтрю на вещи в мире.
Тут не в инерции дело. Если вспомнить историю, то Windows CE/Mobile просто доминировал на смартфонах и казалось что ничто его оттуда не сдвинет. iPhone не в счет, т.к. MacOS/MacOSX всегда существала параллельно Windows с ее 10% в США и близко к 0% в остальном мире.
А потом пришел Google, перелицевал Linux под видом Android и захватил весь рынок смартфонов.
Сейчас Windows доминирует в домашнем секторе просто потому что ее до сих пор принудительно предустанавливают на ноутбуки и десктопы. Т.е. просто никому пока не понадобилось взять и начать доминировать по типу Android (ChromeOS, SteamOS - примеры, но сильно нишевые).
Возможно пример российского рынка с тотальным переводом всяких 1С и Компас на Linux подтолкнут мир в понимании, что Windows уже давно не монополист на десктопе, а Linux годится не только для запуска Firefox и ssh.
Другое вопрос что и Windows, и Linux с их монолитными ядрами это концептуально устаревшие еще на момент выпуска дырявые решета для взлома, с другой стороны вон darwin весь такой правильный и микроядерный, но ломают и его, только в путь.
Да, внутри Linux есть фрагментация. Менеджеры пакетов это на самом деле мелочи, а вот отличия Qt от GTK и Wx более существенны. Ну а где фрагментации нет? Даже в Windows помимо исторических WinAPI, MFC, VCL наворотили сверху еще WinForms, WPF, FMX и прочей ерунды. При том что Qt, GTK, Wx там тоже есть, бодро хромают. Инсталляторов тоже, помио MSI хватает.
Тем не менее, с эволюционной точки зрения Windows должен уйти, как только все его API окончательно портируют/реализуют в OSS, и может быть вайбкодинг тут как раз придаст ускорение, хоть какая-то будет польза от клодов этих.
Уйти просто по причине невозможности мирового сообщества хоть как-то влиять на ее развитие.
Плюс базовая платформа в закрытых исходных кодах, с возможностью удаленного и бесконтрольного управления твоим компьютером посредством любой третьей компании или персоны - не должна существовать просто из соображений инфобезопасности (вирусы Петя и прочее).
Кроссплатформа не нужна. Мир стремится к унификации, и уже в обозримой перспективе вообще все схлопнется к миру Linux, не только серверы. В виде разнообразия некоторое время останутся iOS, macOS, но неизбежно вытеснят и их.
А можно ли реализовать вместе с ИИ? Вполне возможно что да. Но поможет ли тут агентный кодинг или нужно нечто другое, более интерактивное?
Поможет реализовать первый полурабочий прототип, и не более того, потом это все рухнет без социокультурного феномена и обратной связи. Мир устал от всего этого, rust, zig, nemerle, kotlin, swift, все такие правильные и грамотные, 100500 способов банального консольного println() на фоне нигде толком так и нерешенной проблемы 0.2 + 0.1 != 0.3.
Взлететь может лишь что-то запредельно правильное и запредельно простое, не требующее 1500 листов фолианта для написания простейшего hello world сервиса.
И то только тогда, когда его в chrome встроят. И это не typescript
сам бы я писал его очень долго, в том числе по причине нехватки на это времени.
Именно так. AI позволяет очень безболезненно пройти стадию от "моя чумовая идея" к "идея была не такая уж и чумовая, и вообще вот и вот и вот уже готовое лежит, а я и не знал". Не надо тратить месяцы и годы на написание вручную всякого ненужного, и не так обидно это потом выбрасывать.
Это реклама сервиса lenza? Для РФ в качестве корпоративного мессенджера (в котором пароли и прочие бизнес секреты же будут передавать без шифрации) внедрять что-то проприетарное с закрытым исходным кодом - идея как минимум рисковая.
Аналогично Ubuntu, мало того, что это британская компания, отказавшая в поддержке компаниям в РФ, так ее и в слежке за пользователями уличали и не только.
Хотя учитывая еще и Windows... отдел инфобезопасности видимо у вас совсем не дремлет :)
ИИ это всего лишь инструмент. Раньше конструкторы чертили карандашами, циркулем и линейкой, и вычисляли на логарифмической линейке. Потом появились CAD/CAM/CAE и прочие графопостроители. Уменьшило ли это число инженеров? Да, исчезла специфическая профессия копировальщицы, но не более того. Инженерам прибавилось новых задач, которые они раньше не решали или не могли решать в силу лимита времени.
Аналогично с программированием. С ИИ просто прибавится новых задач и решений, и неизбежно увеличится в разы количество кода, которое нужно будет поддерживать.
Принципиально же ничего не изменилось. Выросла энтропия и количество информационного шума, но это другое.
Ну вот и первая полезная фича AI революции: возможность менее чем за год навайбкодить все свои гениальные идеи, и прийти в итоге к выводу, что они не нужны никому, даже тебе самому :)
Аналог? Ок, озвучим задачу. Нужно быстро сделать полный клон текущего процесса, и сохранить все открытые дескрипторы и отображения памяти. Но только часть отображений (mmap-ings) должны быть разделяемыми между копиями процесса, а часть - изолированными, т.е. изменение памяти в порожденном процессе должно делать копию изменяемой страницы памяти. А вот чтение - нет, оба процесса должны читать одну и ту-же страницу (до тех пор, пока она не изменится одним из процессов).
Как только это станет возможным под Windows - велкам в первый класс начальной школы.
Описанное выше не какие-то фрик бредни, это основа порождения процессов в Linux, именно по этой причине он настолько фантастически быстр в таких вещах как bash/find/grep и т.п. и не только.
Можно еще про Oracle вспомнить и насколько костыльно он был портирован на WinNT по причине недоделанности системных API и в целом кривизны архитектуры (а воз и ныне там, уже 30+ лет прошло, ничего не меняется).
Неужели кто-то в здравом уме думает, что Майкрософт не осилила бы запилить свой форк-аналог, будь в нем хоть какая-то польза?...
Microsoft в своем Windows настолько фантастически отстала от современного OS строения, что рассматривать ее не как безнадежно legacy платформу - это признак или отстуствия здравомыслия, или элементарного незнания основ. Причем ситуация вообще не меняется уже лет 20+ как.
Уже и корпоративный сектор даже в США и ЕС вовсю выносит ее из датацентров (оставляя только ActiveDirectory/Exchange по причине завязки на десктопы и VDI), уже даже .NET и MSSQL перенесли на Linux, вместе с 1С, даже в WSL все два раза поиграли (недачно в обоих попытках реализации), но нет, находятся же правдорубцы, которые в 2026-м году утвержают, что Windows имеет практический смысл и перспективу для чего-то еще, кроме игродела, ms office/VDI, запуска putty и retail-home сектора с его принудительной предустановкой на ноутбуки.
Не надо читать бредятину. Нужно просто хоть раз попробовать попрограммировать под Windows, но не на Python, Java или PHP, а прям с низов, попробовать найти там mmap(), fork(), clone(), вкусить, так сказать, все тонкости.
Потом сравнить поведение даже таких примитивов как send(), recv()
Глядишь и до сравнения накладных расходов в msysgit и его bash/grep/find дойдет.
А так конечно Windows отличная система.... для запуска putty, vs code remote и outlook, не ирония.
Там в самом начале цитата "Что не так с Linux. В целом всё в порядке, сказал бы я, пока не начал плотно заниматься проектами в трейдинге"
Ну ок, пусть будет не про трейдинг :)
Для стандартного серверного софта общего назначения в разы важнее возможность интеграции с существующими прикладными решениями, и тут еще одна OS как еще одна своя экосистема просто не нужна. Да и не так много задач, где latency настолько критично. Тем более и эта тема закрыта - есть целый букет ОСРВ (RTOS), разной степени адекватности, некоторые даже в ADAS применяются.
В общем не в OC все дело. Тем более на современном многоядерном железе, где можно через CPU affinity, mmap() и прочие IO_URING свести участие ядра в процессе к минимуму - т.е. процесс и ядро будут просто весело перебрасываться сообщениями между cpu cores в стиле LMAX Disruptor (а там через CAS достижимы несколько миллионов операций в секунду), без какого либо переключения контекста.
Т.е. более интересны скорее новые архитектурные паттерны, к примеру фрики вроде последователей идей Erlang/Elixir/OTP, да и actix тот-же (которого всегда бъет libreactor-ng - кстати отличный пример реализации сказанного абзацем выше).
Ну и конечно-же незабвенные KDB+/Q, с идеей и демо на стендах, что если все затолкать в L1 кеш, то интерпретация получится даже быстрее, чем на C/C++, что порой даже отчасти верно. Пока до реального прода не дойдет :)
Причем все это актуально даже не сколько про performance, сколько про избавление от типового корпоративного java-style bloatware, где стек обработчика события (хоть с Kafka, хоть HTTPS запроса) разворачивается в глубину на 30+ вызовов.
в целом, не верю что взлетит, gpt лажается даже с намного более простыми задачами
Тут главное - верить. В целом AI плотно занял нишу генерации MVP/POC прототипов, для A/B тестирования чумовых идей. Еще более менее может в статический анализ, где Coverity и PC-Lint не справляются, как дополнение к оным. Ну и Google Search 3.0 само собой.
И скорее всего в этой нише это все и останется. Допиливать руками потом MVP/POC до прода все же проще, чем с нуля писать его вручную (тем более несколько раз подряд).
А вот на тему rust интереснее - выйдет ли он из ниши второстепенных задач, вроде драйверов ядра, IDE и прочих встраиваемых веб-серверов (где и С/C++ на самом деле неплохо и так работает). В bloody enterprise так и не вошел - Java его не пропустила.
Основатель CentOS и Rocky Linux представил Linux-совместимое ядро Ginux, написанное на Rust
А coreutils-то уже дописали на Rust, все хорошо? Что там следующее? m4 или еще один цикл запустят в цепочке ipfwadm->ipchains->iptables->nftables->rustables ?
Можно и systemd переписать, вот на LOR порадуются :)
Довольно странная статья. В контексте озвученной задачи (трейдинг) не упомянуты термины HFT, FPGA, ULLDMA, темы не изучены?
Хотя теме HFT уже 12+ лет, успела и взлететь, и упасть, и даже Mantara пару раз обанкротилась.
Но если не рассматривать исполнительное ядро для исполнения торговой стратегии / ордера, где собственно OS как раз и не нужна, даже на rust навайбкоженная, а нужны запредельно низкие задержки, работа на уровне offloading процессора сетевой карты (см Xilinx и подобные), то задача в целом теряет смысл, т.к. дальше уже и нет никакой особо разницы, с какой скоростью posttrading обработка растечется по подсистемам, тут пара лишних микросекунд затрат на ядро Linux уже никакой роли на финансовый результат не имеют.
А Linux сам по себе достаточно быстр и постоянно совершенствуется в этом плане, да и способы выжать максимум тоже известны, от user-space UDP до disable CPU throtting, замены malloc()/free() и т.п.
Самый яркий пример - tickerplant architecture pattern, ну вот кто бы мог подумать, что замена типовой утопической multithreading модели на однопроцессную может дать настолько значимый прирост :) Хотя event based loop открыли еще во времена nginx, да и io_uring уже давно не открытие.
Но сейчас, вспоминая архитектуру TV, наверное не выбрал бы. Взял бы что попроще. Она создавалась по подобию системы сообщений и окон Windows.
Не совсем так. Вернее совсем не так. Там прародителем была библиотека-среда MacApp, от Apple. С нее потом списали TV, OWL и даже частично MFC. Ну и VCL само собой. И что самое интересное - Object Pascal это изначально тоже от Apple популяризация, а не от Borland, правда у них потом случился сдвиг в C++ и потом в Objective C, но это уже другая история. Гуглится это великолепие по "Programmer's Guide to MacApp".
А Windows это WinAPI, все эти HANDLE, HWND - там нет ничего от TV.
Вопросом был конкретный пример непостижимой задачи, которая требует прокачки специализированных скиллов 3+ лет. Есть что сказать по теме?
К примеру вопрос вида "У кластера базы данных появился нестабильный интерконнект, потому что на уровне OS установили последними релизами нестабильный драйвер NIC, который теряет иногда пакеты при TCP-offloading, вот Note ID, вот патч, вот hot-fix workaround" - это семечки, подобное диагностируется и чинится влет при наличии общих навыков в IT.
Наверное имелось в виду не с нуля, а имея 10+ лет опыта в отрасли. Для DBA - достаточно проштудировать Student guides + практикум.
Что там непостижимого? Добавлять пользователей по шаблону, отслеживать бекапы, накатывать патчи и разгребать инциденты из Snow? В наше время даже устанавливать и настраивать сервер самому не требуется, все разворачивается из шаблона в облаке.
Фантомные неведомые глюки - велкам на вендорский саппорт, форумы и ИИ-чку, любой вопрос можно разрешить за час, максимум сутки.
По остальным направлениям аналогично. Месяца вполне достаточно для загрузки основных инструментов и обязанностей в краткосрочную память и просмотреть закрытые тикеты в ретроспективе для изучения местной специфики, а дальше все как обычно.
При этом не в айтишных специальностях аналогично. Прям 6+ опыта строго плотником, кровельщиком, плиточником или электриком не требуется. Переквалифицироваться из очень хорошего плотника в неплохого электрика можно за неделю, максимум за месяц. Две недели в кровельщика. Ряд специальностей правда подразумевает неслабые физические данные (каменщик) или специфическую многомесячную отработку моторики и реакции (дальнобойщик), но в целом важен вдумчивый подход, умение быстро соображать, держать в голове контекст (где что лежит и куда что должно быть прикручено), помнить и эффективно применять десятки ньюансов вроде инструкций и ограничений: не прегревать, не перекручивать и т.д.
Типовая вакансия по мотивам hh.ru: нужен кровельщик с опытом работы с поликарбонатом, стеклоизолом, мембраной ПВХ, сланцем, черепицей, профнастилом, ондулином и кварцевым полотном с температурами до +6000С на объектах от уровня сельская баня до Москва сити и КА Буран, опыт до 3 лет (т.е. нужны бойцы до 25 лет возратом), наличие сертификатов и профильного высшего образования приветствуется. Опты работы в Арктике и Антарктиде обязателен, опыт работы на объектах в Сомали, Зимбабве или Афганистан будет плюсом.
Также требуется развернутое портфолио не менее 200 ранее завершенных проектов и отзыв 4.99 на профи.ру с не менее 500 откликов.
При этом суть проекта - раскатать еще один слой рубероида на гаражах автоцеха :)
И из 300 откликов возьмут банально того, кто меньше денег попросит.
Краткое резюме - на hh.ru что-то сильно поломалось, и процедура поиска работы и соискателей там стала неадекватной задаче поиска собственно работы и соискателей. Нужны другие инструменты и площадки.
Фильтрация по навыкам и тегам - оок, может быть. Но на самом деле приобрести hard-skills уровня junior можно за неделю, middle - за два месяца в любой области, уровня senior - за год, а уровня эксперт мирового уровня - лет за пять. Переквалифицироваться из фронэнда в бекэнд - три недели. Из DBA в DevOps и обратно - максимум месяц.
Какой вообще смысл в этих фильтрах? В реальности важны совсем другие навыки - к примеру умение не уронить прод пятничным релизом. Умение делать review на PR в сотню файлов и 10 тысяч строк кода (а не skip-approve оного).
Замапить файл размером (там size_t параметр) более 2/4 гигабайт - да, этим пожалуй можно найти оправдание 64-х битному size_t. Можно ли иметь файл размером более 2/4 гигабайт - аналогично, конечно можно. Но тут тонкий момент - эти сущности относятся к другому классу памяти - это уже не RAM, а persistent memory.
И даже там, на самом деле, не нужен 64-х битный size_t.
Если речь про базы данных, то у них есть внутренняя структура, сегменты, extent-ы, партиции, секции, еще поди много разных названий деления условной таблицы на части. А если говорить про HCC, т.е. колоночную компрессию, то там гранулярность условно в 16мегабайт, больше делать нет смысла, т.к. будут большие затраты на рекомпрессию, а степень сжатия вырастет незначительно.
И в целом сверхбольшие размеры секций просто не практичны - их так просто труднее параллельно обрабатывать, к примеру параллельно бекапить.
Применительно к базам данных эти отдельные секции-сегменты можно было mmap()-ить каждую отдельно, из позиции 64 битный segment offset + 32 битный segment size. А хранить эти секции-сегменты хоть одним большим файлом, хоть десятком более мелких, это уже не принципиально.
Т.е. задача опять сводится в вопросу - то, что size_t выбрали из соображений вместить самый большой потенциальный объект в системе (т.е. файл целиком) - это понятно, но на самом деле с инженерной и оптимизационной точки зрения вопрос должен был звучать так - вместить самый большой атомарный (т.е. неделимый) объект приложений.
К примеру строка "Москва" - условно неделима, ее можно рассматривать и обрабатывать только целиком. А вот есть ли в природе такие, условно неделимые названия или чанки чего-либо, размер которых не вмещается в целочисленное поле размеров в 32 бита и которые нужно обрабатывать только через 64-х битный size_t и иначе никак?
Ну а я вообще обалдел, когда это прочитал (в 48 бит адреса). Это ж откровенно идиотское и высосанное из пальца ограничение. Зачем ограничивать виртуальный адрес?
Там и экономия на транзисторах и линиях шин, и особенности внутренней реализации уровней блоков MMU, они оперируют по схеме (12 + 9 + 9 + 9 = 48). В общем костыль на костыле. При этом расширение 52 бит реализовано еще одним костылем, что-то вроде PAE или EMM386, но там уже и на уровне поддержки ОС веселье, просто так в те 52 бита не забраться, нужно подключать отдельное API.
И скорее всего это уже не изменится никогда, т.к. физические пределы уплотнения транзисторов достигнуты, и просто так нарастить объем RAM не получится - ибо на мобильных телефончиках сразу вырастет энергопотребление. А кому сильно надо - те помучаются и с отдельными API
Тут не в инерции дело. Если вспомнить историю, то Windows CE/Mobile просто доминировал на смартфонах и казалось что ничто его оттуда не сдвинет.
iPhone не в счет, т.к. MacOS/MacOSX всегда существала параллельно Windows с ее 10% в США и близко к 0% в остальном мире.
А потом пришел Google, перелицевал Linux под видом Android и захватил весь рынок смартфонов.
Сейчас Windows доминирует в домашнем секторе просто потому что ее до сих пор принудительно предустанавливают на ноутбуки и десктопы. Т.е. просто никому пока не понадобилось взять и начать доминировать по типу Android (ChromeOS, SteamOS - примеры, но сильно нишевые).
Возможно пример российского рынка с тотальным переводом всяких 1С и Компас на Linux подтолкнут мир в понимании, что Windows уже давно не монополист на десктопе, а Linux годится не только для запуска Firefox и ssh.
Другое вопрос что и Windows, и Linux с их монолитными ядрами это концептуально устаревшие еще на момент выпуска дырявые решета для взлома, с другой стороны вон darwin весь такой правильный и микроядерный, но ломают и его, только в путь.
Опять минусаторы прибежали, не проснувшись?
Да, внутри Linux есть фрагментация. Менеджеры пакетов это на самом деле мелочи, а вот отличия Qt от GTK и Wx более существенны. Ну а где фрагментации нет? Даже в Windows помимо исторических WinAPI, MFC, VCL наворотили сверху еще WinForms, WPF, FMX и прочей ерунды. При том что Qt, GTK, Wx там тоже есть, бодро хромают. Инсталляторов тоже, помио MSI хватает.
Тем не менее, с эволюционной точки зрения Windows должен уйти, как только все его API окончательно портируют/реализуют в OSS, и может быть вайбкодинг тут как раз придаст ускорение, хоть какая-то будет польза от клодов этих.
Уйти просто по причине невозможности мирового сообщества хоть как-то влиять на ее развитие.
Плюс базовая платформа в закрытых исходных кодах, с возможностью удаленного и бесконтрольного управления твоим компьютером посредством любой третьей компании или персоны - не должна существовать просто из соображений инфобезопасности (вирусы Петя и прочее).
Кроссплатформа не нужна. Мир стремится к унификации, и уже в обозримой перспективе вообще все схлопнется к миру Linux, не только серверы. В виде разнообразия некоторое время останутся iOS, macOS, но неизбежно вытеснят и их.
Поможет реализовать первый полурабочий прототип, и не более того, потом это все рухнет без социокультурного феномена и обратной связи. Мир устал от всего этого, rust, zig, nemerle, kotlin, swift, все такие правильные и грамотные, 100500 способов банального консольного println() на фоне нигде толком так и нерешенной проблемы 0.2 + 0.1 != 0.3.
Взлететь может лишь что-то запредельно правильное и запредельно простое, не требующее 1500 листов фолианта для написания простейшего hello world сервиса.
И то только тогда, когда его в chrome встроят. И это не typescript
Именно так. AI позволяет очень безболезненно пройти стадию от "моя чумовая идея" к "идея была не такая уж и чумовая, и вообще вот и вот и вот уже готовое лежит, а я и не знал". Не надо тратить месяцы и годы на написание вручную всякого ненужного, и не так обидно это потом выбрасывать.
Это реклама сервиса lenza? Для РФ в качестве корпоративного мессенджера (в котором пароли и прочие бизнес секреты же будут передавать без шифрации) внедрять что-то проприетарное с закрытым исходным кодом - идея как минимум рисковая.
Аналогично Ubuntu, мало того, что это британская компания, отказавшая в поддержке компаниям в РФ, так ее и в слежке за пользователями уличали и не только.
Хотя учитывая еще и Windows... отдел инфобезопасности видимо у вас совсем не дремлет :)
ИИ это всего лишь инструмент. Раньше конструкторы чертили карандашами, циркулем и линейкой, и вычисляли на логарифмической линейке. Потом появились CAD/CAM/CAE и прочие графопостроители.
Уменьшило ли это число инженеров? Да, исчезла специфическая профессия копировальщицы, но не более того. Инженерам прибавилось новых задач, которые они раньше не решали или не могли решать в силу лимита времени.
Аналогично с программированием. С ИИ просто прибавится новых задач и решений, и неизбежно увеличится в разы количество кода, которое нужно будет поддерживать.
Принципиально же ничего не изменилось. Выросла энтропия и количество информационного шума, но это другое.
Ну вот и первая полезная фича AI революции: возможность менее чем за год навайбкодить все свои гениальные идеи, и прийти в итоге к выводу, что они не нужны никому, даже тебе самому :)
Аналог? Ок, озвучим задачу. Нужно быстро сделать полный клон текущего процесса, и сохранить все открытые дескрипторы и отображения памяти. Но только часть отображений (mmap-ings) должны быть разделяемыми между копиями процесса, а часть - изолированными, т.е. изменение памяти в порожденном процессе должно делать копию изменяемой страницы памяти. А вот чтение - нет, оба процесса должны читать одну и ту-же страницу (до тех пор, пока она не изменится одним из процессов).
Как только это станет возможным под Windows - велкам в первый класс начальной школы.
Описанное выше не какие-то фрик бредни, это основа порождения процессов в Linux, именно по этой причине он настолько фантастически быстр в таких вещах как bash/find/grep и т.п. и не только.
Можно еще про Oracle вспомнить и насколько костыльно он был портирован на WinNT по причине недоделанности системных API и в целом кривизны архитектуры (а воз и ныне там, уже 30+ лет прошло, ничего не меняется).
Microsoft в своем Windows настолько фантастически отстала от современного OS строения, что рассматривать ее не как безнадежно legacy платформу - это признак или отстуствия здравомыслия, или элементарного незнания основ. Причем ситуация вообще не меняется уже лет 20+ как.
Уже и корпоративный сектор даже в США и ЕС вовсю выносит ее из датацентров (оставляя только ActiveDirectory/Exchange по причине завязки на десктопы и VDI), уже даже .NET и MSSQL перенесли на Linux, вместе с 1С, даже в WSL все два раза поиграли (недачно в обоих попытках реализации), но нет, находятся же правдорубцы, которые в 2026-м году утвержают, что Windows имеет практический смысл и перспективу для чего-то еще, кроме игродела, ms office/VDI, запуска putty и retail-home сектора с его принудительной предустановкой на ноутбуки.
Не надо читать бредятину. Нужно просто хоть раз попробовать попрограммировать под Windows, но не на Python, Java или PHP, а прям с низов, попробовать найти там mmap(), fork(), clone(), вкусить, так сказать, все тонкости.
Потом сравнить поведение даже таких примитивов как send(), recv()
Глядишь и до сравнения накладных расходов в msysgit и его bash/grep/find дойдет.
А так конечно Windows отличная система.... для запуска putty, vs code remote и outlook, не ирония.
Там в самом начале цитата "Что не так с Linux. В целом всё в порядке, сказал бы я, пока не начал плотно заниматься проектами в трейдинге"
Ну ок, пусть будет не про трейдинг :)
Для стандартного серверного софта общего назначения в разы важнее возможность интеграции с существующими прикладными решениями, и тут еще одна OS как еще одна своя экосистема просто не нужна. Да и не так много задач, где latency настолько критично. Тем более и эта тема закрыта - есть целый букет ОСРВ (RTOS), разной степени адекватности, некоторые даже в ADAS применяются.
В общем не в OC все дело. Тем более на современном многоядерном железе, где можно через CPU affinity, mmap() и прочие IO_URING свести участие ядра в процессе к минимуму - т.е. процесс и ядро будут просто весело перебрасываться сообщениями между cpu cores в стиле LMAX Disruptor (а там через CAS достижимы несколько миллионов операций в секунду), без какого либо переключения контекста.
Т.е. более интересны скорее новые архитектурные паттерны, к примеру фрики вроде последователей идей Erlang/Elixir/OTP, да и actix тот-же (которого всегда бъет libreactor-ng - кстати отличный пример реализации сказанного абзацем выше).
Ну и конечно-же незабвенные KDB+/Q, с идеей и демо на стендах, что если все затолкать в L1 кеш, то интерпретация получится даже быстрее, чем на C/C++, что порой даже отчасти верно. Пока до реального прода не дойдет :)
Причем все это актуально даже не сколько про performance, сколько про избавление от типового корпоративного java-style bloatware, где стек обработчика события (хоть с Kafka, хоть HTTPS запроса) разворачивается в глубину на 30+ вызовов.
Тут главное - верить. В целом AI плотно занял нишу генерации MVP/POC прототипов, для A/B тестирования чумовых идей. Еще более менее может в статический анализ, где Coverity и PC-Lint не справляются, как дополнение к оным. Ну и Google Search 3.0 само собой.
И скорее всего в этой нише это все и останется. Допиливать руками потом MVP/POC до прода все же проще, чем с нуля писать его вручную (тем более несколько раз подряд).
А вот на тему rust интереснее - выйдет ли он из ниши второстепенных задач, вроде драйверов ядра, IDE и прочих встраиваемых веб-серверов (где и С/C++ на самом деле неплохо и так работает). В bloody enterprise так и не вошел - Java его не пропустила.
А coreutils-то уже дописали на Rust, все хорошо? Что там следующее? m4 или еще один цикл запустят в цепочке ipfwadm->ipchains->iptables->nftables->rustables ?
Можно и systemd переписать, вот на LOR порадуются :)
Довольно странная статья. В контексте озвученной задачи (трейдинг) не упомянуты термины HFT, FPGA, ULLDMA, темы не изучены?
Хотя теме HFT уже 12+ лет, успела и взлететь, и упасть, и даже Mantara пару раз обанкротилась.
Но если не рассматривать исполнительное ядро для исполнения торговой стратегии / ордера, где собственно OS как раз и не нужна, даже на rust навайбкоженная, а нужны запредельно низкие задержки, работа на уровне offloading процессора сетевой карты (см Xilinx и подобные), то задача в целом теряет смысл, т.к. дальше уже и нет никакой особо разницы, с какой скоростью posttrading обработка растечется по подсистемам, тут пара лишних микросекунд затрат на ядро Linux уже никакой роли на финансовый результат не имеют.
А Linux сам по себе достаточно быстр и постоянно совершенствуется в этом плане, да и способы выжать максимум тоже известны, от user-space UDP до disable CPU throtting, замены malloc()/free() и т.п.
Самый яркий пример - tickerplant architecture pattern, ну вот кто бы мог подумать, что замена типовой утопической multithreading модели на однопроцессную может дать настолько значимый прирост :) Хотя event based loop открыли еще во времена nginx, да и io_uring уже давно не открытие.
Не совсем так. Вернее совсем не так. Там прародителем была библиотека-среда MacApp, от Apple. С нее потом списали TV, OWL и даже частично MFC. Ну и VCL само собой. И что самое интересное - Object Pascal это изначально тоже от Apple популяризация, а не от Borland, правда у них потом случился сдвиг в C++ и потом в Objective C, но это уже другая история.
Гуглится это великолепие по "Programmer's Guide to MacApp".
А Windows это WinAPI, все эти HANDLE, HWND - там нет ничего от TV.
Вопросом был конкретный пример непостижимой задачи, которая требует прокачки специализированных скиллов 3+ лет. Есть что сказать по теме?
К примеру вопрос вида "У кластера базы данных появился нестабильный интерконнект, потому что на уровне OS установили последними релизами нестабильный драйвер NIC, который теряет иногда пакеты при TCP-offloading, вот Note ID, вот патч, вот hot-fix workaround" - это семечки, подобное диагностируется и чинится влет при наличии общих навыков в IT.
Наверное имелось в виду не с нуля, а имея 10+ лет опыта в отрасли.
Для DBA - достаточно проштудировать Student guides + практикум.
Что там непостижимого? Добавлять пользователей по шаблону, отслеживать бекапы, накатывать патчи и разгребать инциденты из Snow? В наше время даже устанавливать и настраивать сервер самому не требуется, все разворачивается из шаблона в облаке.
Фантомные неведомые глюки - велкам на вендорский саппорт, форумы и ИИ-чку, любой вопрос можно разрешить за час, максимум сутки.
По остальным направлениям аналогично. Месяца вполне достаточно для загрузки основных инструментов и обязанностей в краткосрочную память и просмотреть закрытые тикеты в ретроспективе для изучения местной специфики, а дальше все как обычно.
При этом не в айтишных специальностях аналогично. Прям 6+ опыта строго плотником, кровельщиком, плиточником или электриком не требуется. Переквалифицироваться из очень хорошего плотника в неплохого электрика можно за неделю, максимум за месяц. Две недели в кровельщика. Ряд специальностей правда подразумевает неслабые физические данные (каменщик) или специфическую многомесячную отработку моторики и реакции (дальнобойщик), но в целом важен вдумчивый подход, умение быстро соображать, держать в голове контекст (где что лежит и куда что должно быть прикручено), помнить и эффективно применять десятки ньюансов вроде инструкций и ограничений: не прегревать, не перекручивать и т.д.
Типовая вакансия по мотивам hh.ru: нужен кровельщик с опытом работы с поликарбонатом, стеклоизолом, мембраной ПВХ, сланцем, черепицей, профнастилом, ондулином и кварцевым полотном с температурами до +6000С на объектах от уровня сельская баня до Москва сити и КА Буран, опыт до 3 лет (т.е. нужны бойцы до 25 лет возратом), наличие сертификатов и профильного высшего образования приветствуется. Опты работы в Арктике и Антарктиде обязателен, опыт работы на объектах в Сомали, Зимбабве или Афганистан будет плюсом.
Также требуется развернутое портфолио не менее 200 ранее завершенных проектов и отзыв 4.99 на профи.ру с не менее 500 откликов.
При этом суть проекта - раскатать еще один слой рубероида на гаражах автоцеха :)
И из 300 откликов возьмут банально того, кто меньше денег попросит.
Краткое резюме - на hh.ru что-то сильно поломалось, и процедура поиска работы и соискателей там стала неадекватной задаче поиска собственно работы и соискателей. Нужны другие инструменты и площадки.
Фильтрация по навыкам и тегам - оок, может быть. Но на самом деле приобрести hard-skills уровня junior можно за неделю, middle - за два месяца в любой области, уровня senior - за год, а уровня эксперт мирового уровня - лет за пять. Переквалифицироваться из фронэнда в бекэнд - три недели. Из DBA в DevOps и обратно - максимум месяц.
Какой вообще смысл в этих фильтрах? В реальности важны совсем другие навыки - к примеру умение не уронить прод пятничным релизом. Умение делать review на PR в сотню файлов и 10 тысяч строк кода (а не skip-approve оного).
И даже там, на самом деле, не нужен 64-х битный size_t.
Если речь про базы данных, то у них есть внутренняя структура, сегменты, extent-ы, партиции, секции, еще поди много разных названий деления условной таблицы на части. А если говорить про HCC, т.е. колоночную компрессию, то там гранулярность условно в 16мегабайт, больше делать нет смысла, т.к. будут большие затраты на рекомпрессию, а степень сжатия вырастет незначительно.
И в целом сверхбольшие размеры секций просто не практичны - их так просто труднее параллельно обрабатывать, к примеру параллельно бекапить.
Применительно к базам данных эти отдельные секции-сегменты можно было mmap()-ить каждую отдельно, из позиции 64 битный segment offset + 32 битный segment size. А хранить эти секции-сегменты хоть одним большим файлом, хоть десятком более мелких, это уже не принципиально.
Т.е. задача опять сводится в вопросу - то, что size_t выбрали из соображений вместить самый большой потенциальный объект в системе (т.е. файл целиком) - это понятно, но на самом деле с инженерной и оптимизационной точки зрения вопрос должен был звучать так - вместить самый большой атомарный (т.е. неделимый) объект приложений.
К примеру строка "Москва" - условно неделима, ее можно рассматривать и обрабатывать только целиком. А вот есть ли в природе такие, условно неделимые названия или чанки чего-либо, размер которых не вмещается в целочисленное поле размеров в 32 бита и которые нужно обрабатывать только через 64-х битный size_t и иначе никак?
Там и экономия на транзисторах и линиях шин, и особенности внутренней реализации уровней блоков MMU, они оперируют по схеме (12 + 9 + 9 + 9 = 48). В общем костыль на костыле. При этом расширение 52 бит реализовано еще одним костылем, что-то вроде PAE или EMM386, но там уже и на уровне поддержки ОС веселье, просто так в те 52 бита не забраться, нужно подключать отдельное API.
И скорее всего это уже не изменится никогда, т.к. физические пределы уплотнения транзисторов достигнуты, и просто так нарастить объем RAM не получится - ибо на мобильных телефончиках сразу вырастет энергопотребление. А кому сильно надо - те помучаются и с отдельными API