У QNX их несколько десятков (в ранних версиях < 20), у seL4 < 14 (цель - возможность проверки соответствия спекам), но микроядро - это не всегда хорошо, их область - медицина, промышленность, транспорт (и, внезапно, Blackberry). И на то есть причины: чем меньше сисколлов - тем чаще их надо вызывать - тем больше переключений контекста, а это очень накладная операция: доступ к ФС, сети, устройствам и пр. - всё в userspace. Плюс нагрузка на программиста: минимизировать IPC с этими переключениями.
Что важнее, такие узкоспециализированные ядра не имеют драйверов для простого пользовательского оборудования, в то время как Linux и Windows поддерживают сотни тысяч самых разнообразных устройств.
Свою правоту я не доказываю, даже не утверждаю что я прав — дискуссия на то и дискуссия, что можно услышать самые разные точки зрения. Мнение специалистов, которые меня исправят, будет явно более интересным и ценным, чем моё. Что до юзера… Так я сам простой юзер, даже сишный код навряд ли сумею прочитать. Недавно в даташите одной микрухи копался, час просидел — так ни черта и не понял, залез в код её эмуляции — и там снова ничего не понял. Интерес к потрохам Windows и Linux у меня давно, с детства мечтал свою ОС запилить, только пока знаний не хватает.
P. S. увидел, что стартовый комментарий ветки унесло НЛО, и как-то смысл в ней пропал. Если кому-нибудь интересно, тред начался с провокационного заявления о том, будто Л. Торвальдс заявил, что "сделал бы как в Windows, [если бы была возможность]".
он уже давно не совсем монолитный, а модульный; другое дело что в случае с Linux можно отредактировать сами исходники ядра, чего Windows не позволяет сделать без реверс-инжиниринга.
Что касается поддержки 8086, то её в Linux не было, ядро изначально разрабатывалось под 80386, причём поддержку этих процессоров выкинули ещё в 2012 году, а недавно избавились и от 486. Есть ELKS, но это старый форк и совсем про другое. Если Linux - это монолитный изврат, тогда как объясните большое количество поддерживаемых архитектур?
серьезному потребителю нужны службы архивации, синхронизация и бекапы
Службы архивации, синхронизации и бэкапы - это не ядерная история, вы о чём? Это прикладное ПО.
не нужна безопасность на уровне ядра и сервисов
Безопасность на уровне ядра и сервисов обеспечивается и в Linux, причём есть разные реализации, в зависимости от дистрибутива, в том числе средства контейнеризации и виртуализации, которые используют механизмы ядра и позволяют ещё более гибко управлять доступом к ресурсам и изоляцией.
ну а для чего надо в оси 16 гигабайт? чтоб они были ПУСТЫЕ и ИХ НИКТО НЕ ИСПОЛЬЗОВАЛ, ведь это же кайф - открыть диспетчер задач, и увидеть ОН СКОКА НЕИСПОЛЬЗУЕМОЙ памяти!
Если Вася купил себе много ОЗУ и мощный многоядрёный проц, то очевидно, у Васи есть свои потребности и он уже решил что будет на этом железе запускать; ОС не должна самовольно, без спроса, занимать мощности, процессорное время, диск и ОЗУ ради каких-то своих действий.
500 системных вызовов - сумасшествие?...
500 сисколлов гораздо легче изучить и понять, чем то что наворотили в MS, причём они обеспечивают ядру Linux б0льшую выживаемость, чем 2к с лишним Windows. BSOD словить всё ещё легче, чем kernel panic.
и сколько там на вашем инвалиде нагружается ваш sysMain(что это вообще?)
Вы не уловили контекст: SysMain не мой, можно было загуглить кто его написал, с какой версии Windows эта системная служба входит в стандартную поставку и почему это косяк разработчиков MS. Я просто привёл её как пример "финтифлюшки", на которую навесили отчасти ядерные функции (сжатие содержимого ОЗУ, комбинирование страниц), и из-за которой у кучи пользователей внезапно подскочила нагрузка на дисковый I/O и CPU.
Есть конторы, которым важно не потерять конфиденциальность и есть своя программно-аппаратная архитектура. Есть запрос на лонг-тайм поддержу этого всего и бизнес-процессов.
Думаете я этого не понимаю? Однако если в Linux постепенно избавляются от легасей, то в NT его постепенно накапливают. Логичнее всего было бы абсолютное переписывание с выбросом всех лишних частей, примерно как при переходе от DOS'ок к NTшкам. Да, где-то 5-10 лет пришлось бы поддерживать обе ветки системы, ждать пока бизнес (не) перейдёт на новую ветку, но на NT же мигрировали как-то, справились бы и тут.
"Windows и Linux - это разные подходы к одним и тем же вещам" - это было в прошлом веке
Вам говорят про Фому и Ерёму (буквально перечислив их отличия), а вы - про то, чем Фома и Ерёма занимаются и на кого работают (с чем я не спорю и не поднимал эту тему ни разу). И Windows, и Linux применяются активно в самых разных сферах, это не отменяет их различий.
"Windows ужасен", "Linux на этом фоне выглядит скелетом, зато этот скелет хорошо бегает и его можно обвесить любым "мясом"
Опять не уловили тон поста. "Windows ужасен" - это гипербола, а не факт. Большее юзабилити и более лучший UI/UX Windows не отменяют того, что под капотом. Linux поддерживается на большем числе архитектур и оборудования благодаря открытому коду, Windows не угнаться за ним никак; правда есть и оборудование, поддерживаемое только Windows, с которым "пингвин" работает криво или не работает совсем. С ПО - тоже самое, есть десятки пакетов MS Windows-only.
А вы сами то это скелет ручками пытались обвесить?
5 лет использовал его как домашнюю систему, в том числе запускал через Wine игры и всякое непотребство, когда Steam Deck c Proton не существовали в природе, в том числе сталкивался с кривым UX вроде выброса в терминал после того как иксы не сдружились с новыми дровами. "Скелет" и "мясо" - это больше про гибкость Linux и про сам подход. Я не пишу что всем нравится в этом конструкторе ковыряться, кому-то легче купить готовый, собранный организм и доучить его (да, это я про Windows).
Не умел до 3 класса, и до сих пор когда мне говорят "пять минут пятого" или "полпервого" всегда уточняю что имел ввиду собеседник, а когда смотрю на аналоговые часы - в уме пересчитываю время в привычные цифры.
Насчёт графония я приврал ради красного словца (это распространённый миф). Прибит он не намертво, и при желании из системы можно выбросить очень многое - вот, например, интересный комментарий ; или есть ещё такие эксперименты.
Уважаемый @Fima_Sobak ! Обычному юзеру на многое пофиг, но на Хабре не только юзеры сидят, не так ли? То что графоний в ядре напрямую влияет на возможность заразить ОС или BSOD'нуть её через этот самый графоний - ну, юзеры не должны разбираться, они должны страдать, верно? Или, например, служба SysMain начинает грузить систему под 100% - и что делать юзеру с таким косяком разработчиков? Отключить и потерять быстродействие?
Windows и Linux - это разные подходы к одним и тем же вещам, что в моём комменте подсвечено; в первой уже начал захламляться юзерспейс "финтифлюшками", а во второй с ними приходится иметь дело добровольно-принудительно - обе недружественны к пользователю.
ОС сами по себе создавались, чтобы "финтифлюшки" скрыть и от оборудования, и от программиста, и от пользователя (это их главное предназначение: драйверам - HAL, программам - API, юзеру - GUI). И у Windows, и у Linux это получается неидеально, согласитесь?
P. S.: свидетели Linux, запустившие его на 555, с символом /s, намекают на стёб, но вы, видимо, неуловили. Теперь стало яснее?
Windows ужасен. Они прокинули графоний в ядро (win32k.sys), десятилетиями тащат код и UI из древних версий винды (ещё и несколько слоёв абстракции), перегружают службы и ОС ненужным обвесом (XBox, Cortana, etc.), хранят все настройки в одной корзине (при повреждении файлов реестра навернется всё; формально есть бэкап, неформально юзер ещё должен знать как его подсунуть системе)... Но самая боль - это системные вызовы. 500+-100 в Linux против 2000 в NTOSKrnl (или ntdll.dll, hal.dll, win32k.Sys). Зачем им столько?! Это без учета других важных файлов, многие из которых - подсистемы либо ядра, либо тесно спаянные с ядром (wmilib.sys, pci.sys, acpi.sys, DCOMLaunch, RPCSs, PnP, etc.)
Linux на этом фоне выглядит скелетом, зато этот скелет хорошо бегает и его можно обвесить любым "мясом". Графический сервер отдельно, демоны отдельно (за исключением systemd и dbus, но и они заменимы), конфиги отдельно для каждой проги, откровенное легаси по 30 лет не тащат (кроме иксов, но и те победил Wayland), а программировать низкоуровневые штуки - одно удовольствие, можно ядро обрезать и сделать лютый кастом - и оно будет работать. Код открыт, делай что хочешь - такая гибкость позволяет запускать "пингвина" хоть на мк, свидетели подтверждают запуск даже на 555 /s.
Опять отстал от прогресса, @qvvah Таки научное направление уже зародилось, "Машинная психология". Методы психологии к ИИ применяют только потому что напрямую как-то оценить происходящее внутри LLM затруднительно.
"Если рожа в зеркале тебя не устраивает, виновато не зеркало" (Н. В. Гоголь в японской обработке)
Многие явления статьи применимы и к людям. Это немного пугает, только не пойму чем: схожестью ИИ и людей, тем что разум человека неидеален, попыткой автора найти в ИИ этот самый "чистый разум в вакууме"... Равно как и трудно понять, о чём же автор пишет. Исследование LLM методами когнитивных наук и психологии - это двойная рефлексия: изучая человеческий разум с помощью разума же, люди изучают себя; изучая ИИ-модель, отражающую некоторые свойства нашего разума, с помощью своего разума, человек изучает... что?
Много вопросов, мало ответов, ещё меньше способов подтвердить или опровергнуть ваши выводы. Интересно, выродится ли всё это в научное направление, какую-нибудь "ИИ-когнитивистику", или останется словоблудием?
P. S. термин "когнитивный субстрат" напомнил работы трансгуманистов. Трансгуманисты - это выдумщики-фантасты, к продуктам их деятельности следует относиться максимально скептически - как к любой фантастике. То что там описывается, в нашу жизнь приходит в совершенно ином виде (если приходит вообще). Этот поскриптум для тех, кто воспринимает т. слишком серьёзно.
Автор статьи, на мой взгляд, упорно пытается протащить через текст идею о том, что "всё слишком однозначно" или хотя бы "не так просто". В пределе эти аргументы переходят в теории заговора, а сторонникитеорийзаговора, уверенные в своей правоте, движутся дальше.
Нужно объективно и научно смотреть на вещи, а не делать из пары совпадений далеко идущие выводы с необратимыми, кошмарнымипоследствиями для всего мира (однако, автор так далеко не заходит, предпочитая намекать, чтобы читатель сам додумал лишнее).
@deltadegger: ...А теперь смотрим, как индийцы вознамерилась получить щедрот от Запада, аналогичных тем, что пролились на Китай...
Индийцам не зачем получать щедроты на Западе. Они начали с "индусского кода" - и мы смеялись, а они дошли уже до топовых позиций, возглавив мировые корпорации: Наделла в MS, Пичаи в Google, Кришна в IBM, Мохан в YT, Нарайен в Adobe, Шринивас в Perplexity AI, Рагхурам в VMWare, Мехротра в Micron Technology, Сангхи в Microchip, Девган в Cadence. Более низкие позиции также часто заняты индийцами. Пока нам "англичанка и дядя Сэм" мешали, индийцы накапливали опыт и экспертизу в "кровавом энтерпрайзе" - в реальных условиях, извнутри ИТ-гигантов. Индия, в случае чего, получит прокачанных практикой инженеров и слитые ими технологии. Схожим образом поступил Китай, встроившись в систему, хотя мог пойти против и "назло всем отморозить уши", обидевшись на "жёлтую опасность".
Политота и теории заговора уводят дискуссию от постановки и решения инженерных задач (что надо было делать ещё дцать лет назад, а сейчас это надо делать срочно!!11) к "злому Западу"(на который можно свалить всю ответственность, а с себя - её снять). По вашему получается, что успехи Индии и Китая - это виназлого Запада,который "не тем технологии передал!" Вы написали, что являетесь инженером-механиком. Посмотрите на проблему с инженерной точки зрения, а не с политической, пожалуйста.
Поставить минус не могу, но напомню: Правила Хабра, пункт 7.
Уважаемый @BugM, вы перевели разговор с ПК на тему мобильных телефонов и применяете к технике того времени требования и подходы к разработке текущего времени. Мне это кажется абсурдным.
Начну с того, какими были телефоны в 2005
А были они сильно разными: бюджетники, среднячки, медиа- и камерофоны, топовые. Я ходил с бюджетным Nokia, но даже на нём бы запустилась лёгкая версия "Qiwi Кошелёк", позволявшая проводить финансовые операции - это j2me-мидлет ~100 Кб весом, использующий стандартное UI телефона. Кроме того, есть USSD, SMS и WML/XHTML-браузеры, так что с банкингом проблем бы не было точно.
Qiwi Wallet какой-то там версии
Насчёт видео - некоторые умудрялись смотреть фильмы, пережатые в 240p на мелком экране 240х320, но я не понимал тогда (и не понимаю сейчас), зачем так делать - на ПК гораздо удобнее. Однако, помню что ставил какое-то приложение, позволявшее подключаться к веб-камерам, и оно даже работало [sic!]. У **Tube вроде были j2me-клиенты (возможно, самопальные), точно знаю что можно было скачать оттуда видео и посмотреть, но народ чаще wap-сайтами пользовался и bluetooth.
Насчёт смартфонов точно ничего сказать не могу, думаю там всё было ещё лучше.
А теперь о текущих требованиях и раке ПО
Рак прикладного ПО. Что я подразумеваю? Использование кучи библиотек, Electron, Node.js и много ещё чего. То что раньше занимало 100-200 кБ, сейчас разрастается до 200 мБ и, будучи запущенным, жрёт много ресурсов. Это те самые приложения для банкинга с мессенджером и открытками, страховкой, планировкой бюджета, заказом автозапчастей и лекарств, антивирусом и антиспамом, картами и геометками, хранилищем для документов, бонусной программой и подписками, ИИ (куда без него!) - экосистема всё-в-одном. На Хабре всё это обсуждалось: 123456 - вместе с критикой: 1. Тренд неоспорим. Зачем так делать? С таким подходом любое железо будет тормозить: разработчики постоянно надеются, что рост памяти, частот, ядер перекроет любые огрехи их "жручего" софта.
Пользуясь интернет-банкингом через браузер, каждый раз сталкиваюсь с тормозами: захожу на сайт банка, нажимаю "Интернет-банк", и... Сайт не прогружается с первой попытки. Два раза обновляю страницу. Появляется анимация загрузки, ещё 5-10 секунд ожидания и... Всё это чтобы отрисовать хедер, поле для ввода номера, кнопку подтверждения и всплывающее окно о cookies. Вы серьёзно?! 5 элементов на странице. С этим навороченный смартфон, который намного мощнее бюджетного мобильника 2005ых, должен справляться за миллисекунды!
Мидлет Opera Mini 3 справлялся с отрисовкой всей страницы полностью - всеми разделами, текстом, таблицами, картинками, работая через GPRS, через прокси со сжатием, в J2ME-машине на "слабом железе". Да, это было неудобно, но работало. В 2005ом писать компактные и быстрые программы ещё умели, сам подход к разработке был другим.
UPD.: Насчёт ****бчика: если запускать видео в UHD, то конечно его мобильники не потянут. Но на телефоне оно и не нужно: 360р, на край 480р - хватит. Проблемы с производительностью видео в те годы решались переконвертацией. Был и другой вариант, например, у нетбуков: установка специфичных кодеков, CoreAVC. Думаю, с помощью аппаратно-программных ухищрений воспроизводить стриминг (тот же **Tube) вполне возможно и на старых ПК. Плюс можно загружать видео через сторонние утилиты.
Думаю, выжить можно и с производительностью, меньшей чем у iPhone.
Будущее может быть разным: совместная кооперация, технологическое рабство с угнетением или добровольно-принудительная пятилетка за три года своими силами... Этого предсказать нельзя, даже повлиять нельзя - только прикинуть сценарии. Имхо, лучше заранее приготовиться, чем внезапно оказаться в худшем положении.
Это не троллинг. Другое дело, что sloc измеряется в десятках тысяч, ну и человеко-часы соответственно. Плюс, их всё ещё можно здорово сократить засчёт грамотной архитектуры с отсутствием дублирования функционала.
Что до городов... От них отказываться не надо, а вот деревни поддерживать - очень даже необходимо. Деревня город кормит.
У QNX их несколько десятков (в ранних версиях < 20), у seL4 < 14 (цель - возможность проверки соответствия спекам), но микроядро - это не всегда хорошо, их область - медицина, промышленность, транспорт (и, внезапно, Blackberry). И на то есть причины: чем меньше сисколлов - тем чаще их надо вызывать - тем больше переключений контекста, а это очень накладная операция: доступ к ФС, сети, устройствам и пр. - всё в userspace. Плюс нагрузка на программиста: минимизировать IPC с этими переключениями.
Что важнее, такие узкоспециализированные ядра не имеют драйверов для простого пользовательского оборудования, в то время как Linux и Windows поддерживают сотни тысяч самых разнообразных устройств.
Свою правоту я не доказываю, даже не утверждаю что я прав — дискуссия на то и дискуссия, что можно услышать самые разные точки зрения. Мнение специалистов, которые меня исправят, будет явно более интересным и ценным, чем моё. Что до юзера… Так я сам простой юзер, даже сишный код навряд ли сумею прочитать. Недавно в даташите одной микрухи копался, час просидел — так ни черта и не понял, залез в код её эмуляции — и там снова ничего не понял. Интерес к потрохам Windows и Linux у меня давно, с детства мечтал свою ОС запилить, только пока знаний не хватает.
P. S. увидел, что стартовый комментарий ветки унесло НЛО, и как-то смысл в ней пропал. Если кому-нибудь интересно, тред начался с провокационного заявления о том, будто Л. Торвальдс заявил, что "сделал бы как в Windows, [если бы была возможность]".
он уже давно не совсем монолитный, а модульный; другое дело что в случае с Linux можно отредактировать сами исходники ядра, чего Windows не позволяет сделать без реверс-инжиниринга.
Что касается поддержки 8086, то её в Linux не было, ядро изначально разрабатывалось под 80386, причём поддержку этих процессоров выкинули ещё в 2012 году, а недавно избавились и от 486. Есть ELKS, но это старый форк и совсем про другое. Если Linux - это монолитный изврат, тогда как объясните большое количество поддерживаемых архитектур?
Службы архивации, синхронизации и бэкапы - это не ядерная история, вы о чём? Это прикладное ПО.
Безопасность на уровне ядра и сервисов обеспечивается и в Linux, причём есть разные реализации, в зависимости от дистрибутива, в том числе средства контейнеризации и виртуализации, которые используют механизмы ядра и позволяют ещё более гибко управлять доступом к ресурсам и изоляцией.
Если Вася купил себе много ОЗУ и мощный многоядрёный проц, то очевидно, у Васи есть свои потребности и он уже решил что будет на этом железе запускать; ОС не должна самовольно, без спроса, занимать мощности, процессорное время, диск и ОЗУ ради каких-то своих действий.
500 сисколлов гораздо легче изучить и понять, чем то что наворотили в MS, причём они обеспечивают ядру Linux б0льшую выживаемость, чем 2к с лишним Windows. BSOD словить всё ещё легче, чем kernel panic.
Вы не уловили контекст: SysMain не мой, можно было загуглить кто его написал, с какой версии Windows эта системная служба входит в стандартную поставку и почему это косяк разработчиков MS. Я просто привёл её как пример "финтифлюшки", на которую навесили отчасти ядерные функции (сжатие содержимого ОЗУ, комбинирование страниц), и из-за которой у кучи пользователей внезапно подскочила нагрузка на дисковый I/O и CPU.
Думаете я этого не понимаю? Однако если в Linux постепенно избавляются от легасей, то в NT его постепенно накапливают. Логичнее всего было бы абсолютное переписывание с выбросом всех лишних частей, примерно как при переходе от DOS'ок к NTшкам. Да, где-то 5-10 лет пришлось бы поддерживать обе ветки системы, ждать пока бизнес (не) перейдёт на новую ветку, но на NT же мигрировали как-то, справились бы и тут.
Вам говорят про Фому и Ерёму (буквально перечислив их отличия), а вы - про то, чем Фома и Ерёма занимаются и на кого работают (с чем я не спорю и не поднимал эту тему ни разу). И Windows, и Linux применяются активно в самых разных сферах, это не отменяет их различий.
Опять не уловили тон поста. "Windows ужасен" - это гипербола, а не факт. Большее юзабилити и более лучший UI/UX Windows не отменяют того, что под капотом. Linux поддерживается на большем числе архитектур и оборудования благодаря открытому коду, Windows не угнаться за ним никак; правда есть и оборудование, поддерживаемое только Windows, с которым "пингвин" работает криво или не работает совсем. С ПО - тоже самое, есть десятки пакетов MS Windows-only.
5 лет использовал его как домашнюю систему, в том числе запускал через Wine игры и всякое непотребство, когда Steam Deck c Proton не существовали в природе, в том числе сталкивался с кривым UX вроде выброса в терминал после того как иксы не сдружились с новыми дровами. "Скелет" и "мясо" - это больше про гибкость Linux и про сам подход. Я не пишу что всем нравится в этом конструкторе ковыряться, кому-то легче купить готовый, собранный организм и доучить его (да, это я про Windows).
Не умел до 3 класса, и до сих пор когда мне говорят "пять минут пятого" или "полпервого" всегда уточняю что имел ввиду собеседник, а когда смотрю на аналоговые часы - в уме пересчитываю время в привычные цифры.
Насчёт графония я приврал ради красного словца (это распространённый миф). Прибит он не намертво, и при желании из системы можно выбросить очень многое - вот, например, интересный комментарий ; или есть ещё такие эксперименты.
Уважаемый @Fima_Sobak ! Обычному юзеру на многое пофиг, но на Хабре не только юзеры сидят, не так ли? То что графоний в ядре напрямую влияет на возможность заразить ОС или BSOD'нуть её через этот самый графоний - ну, юзеры не должны разбираться, они должны страдать, верно? Или, например, служба SysMain начинает грузить систему под 100% - и что делать юзеру с таким косяком разработчиков? Отключить и потерять быстродействие?
Windows и Linux - это разные подходы к одним и тем же вещам, что в моём комменте подсвечено; в первой уже начал захламляться юзерспейс "финтифлюшками", а во второй с ними приходится иметь дело добровольно-принудительно - обе недружественны к пользователю.
ОС сами по себе создавались, чтобы "финтифлюшки" скрыть и от оборудования, и от программиста, и от пользователя (это их главное предназначение: драйверам - HAL, программам - API, юзеру - GUI). И у Windows, и у Linux это получается неидеально, согласитесь?
P. S.: свидетели Linux, запустившие его на 555, с символом /s, намекают на стёб, но вы, видимо, неуловили. Теперь стало яснее?
И получилось бы отвратительно,
Windows ужасен. Они прокинули графоний в ядро (win32k.sys), десятилетиями тащат код и UI из древних версий винды (ещё и несколько слоёв абстракции), перегружают службы и ОС ненужным обвесом (XBox, Cortana, etc.), хранят все настройки в одной корзине (при повреждении файлов реестра навернется всё; формально есть бэкап, неформально юзер ещё должен знать как его подсунуть системе)... Но самая боль - это системные вызовы. 500+-100 в Linux против 2000 в NTOSKrnl (или ntdll.dll, hal.dll, win32k.Sys). Зачем им столько?! Это без учета других важных файлов, многие из которых - подсистемы либо ядра, либо тесно спаянные с ядром (wmilib.sys, pci.sys, acpi.sys, DCOMLaunch, RPCSs, PnP, etc.)
Linux на этом фоне выглядит скелетом, зато этот скелет хорошо бегает и его можно обвесить любым "мясом". Графический сервер отдельно, демоны отдельно (за исключением systemd и dbus, но и они заменимы), конфиги отдельно для каждой проги, откровенное легаси по 30 лет не тащат (кроме иксов, но и те победил Wayland), а программировать низкоуровневые штуки - одно удовольствие, можно ядро обрезать и сделать лютый кастом - и оно будет работать. Код открыт, делай что хочешь - такая гибкость позволяет запускать "пингвина" хоть на мк, свидетели подтверждают запуск даже на 555 /s.
А оно в общем-то есть, от самого Торвальдса: "Just for Fun". О Линухе там мало, а вот о Линусе - много и юморно.
Опять отстал от прогресса, @qvvah Таки научное направление уже зародилось, "Машинная психология". Методы психологии к ИИ применяют только потому что напрямую как-то оценить происходящее внутри LLM затруднительно.
Многие явления статьи применимы и к людям. Это немного пугает, только не пойму чем: схожестью ИИ и людей, тем что разум человека неидеален, попыткой автора найти в ИИ этот самый "чистый разум в вакууме"... Равно как и трудно понять, о чём же автор пишет. Исследование LLM методами когнитивных наук и психологии - это двойная рефлексия: изучая человеческий разум с помощью разума же, люди изучают себя; изучая ИИ-модель, отражающую некоторые свойства нашего разума, с помощью своего разума, человек изучает... что?
Много вопросов, мало ответов, ещё меньше способов подтвердить или опровергнуть ваши выводы. Интересно, выродится ли всё это в научное направление, какую-нибудь "ИИ-когнитивистику", или останется словоблудием?
P. S. термин "когнитивный субстрат" напомнил работы трансгуманистов. Трансгуманисты - это выдумщики-фантасты, к продуктам их деятельности следует относиться максимально скептически - как к любой фантастике. То что там описывается, в нашу жизнь приходит в совершенно ином виде (если приходит вообще). Этот поскриптум для тех, кто воспринимает т. слишком серьёзно.
Поздравляю всех гостей сайта, читателей, авторов и команду Хабра с Новым годом!
Желаю здоровья, счастья, успехов во всех делах! Минимум багов и ошибок, максимум надёжных и элегантных решений вам и вашим проектам!
Автор статьи, на мой взгляд, упорно пытается протащить через текст идею о том, что "всё слишком однозначно" или хотя бы "не так просто". В пределе эти аргументы переходят в теории заговора, а сторонники теорий заговора, уверенные в своей правоте, движутся дальше.
Нужно объективно и научно смотреть на вещи, а не делать из пары совпадений далеко идущие выводы с необратимыми, кошмарными последствиями для всего мира (однако, автор так далеко не заходит, предпочитая намекать, чтобы читатель сам додумал лишнее).
Индийцам не зачем получать щедроты на Западе. Они начали с "индусского кода" - и мы смеялись, а они дошли уже до топовых позиций, возглавив мировые корпорации: Наделла в MS, Пичаи в Google, Кришна в IBM, Мохан в YT, Нарайен в Adobe, Шринивас в Perplexity AI, Рагхурам в VMWare, Мехротра в Micron Technology, Сангхи в Microchip, Девган в Cadence. Более низкие позиции также часто заняты индийцами. Пока нам "англичанка и дядя Сэм" мешали, индийцы накапливали опыт и экспертизу в "кровавом энтерпрайзе" - в реальных условиях, извнутри ИТ-гигантов. Индия, в случае чего, получит прокачанных практикой инженеров и слитые ими технологии. Схожим образом поступил Китай, встроившись в систему, хотя мог пойти против и "назло всем отморозить уши", обидевшись на "жёлтую опасность".
Политота и теории заговора уводят дискуссию от постановки и решения инженерных задач (что надо было делать ещё дцать лет назад, а сейчас это надо делать срочно!!11) к "злому Западу" (на который можно свалить всю ответственность, а с себя - её снять). По вашему получается, что успехи Индии и Китая - это вина злого Запада, который "не тем технологии передал!" Вы написали, что являетесь инженером-механиком. Посмотрите на проблему с инженерной точки зрения, а не с политической, пожалуйста.
Поставить минус не могу, но напомню: Правила Хабра, пункт 7.
На любом устройстве необходимо запустить Linux, Hello World, Bad Apple и DOOM. Осталось прикрутить остальное...
ОЗУ
Уважаемый @BugM, вы перевели разговор с ПК на тему мобильных телефонов и применяете к технике того времени требования и подходы к разработке текущего времени. Мне это кажется абсурдным.
Начну с того, какими были телефоны в 2005
А были они сильно разными: бюджетники, среднячки, медиа- и камерофоны, топовые. Я ходил с бюджетным Nokia, но даже на нём бы запустилась лёгкая версия "Qiwi Кошелёк", позволявшая проводить финансовые операции - это j2me-мидлет ~100 Кб весом, использующий стандартное UI телефона. Кроме того, есть USSD, SMS и WML/XHTML-браузеры, так что с банкингом проблем бы не было точно.
Насчёт видео - некоторые умудрялись смотреть фильмы, пережатые в 240p на мелком экране 240х320, но я не понимал тогда (и не понимаю сейчас), зачем так делать - на ПК гораздо удобнее. Однако, помню что ставил какое-то приложение, позволявшее подключаться к веб-камерам, и оно даже работало [sic!]. У **Tube вроде были j2me-клиенты (возможно, самопальные), точно знаю что можно было скачать оттуда видео и посмотреть, но народ чаще wap-сайтами пользовался и bluetooth.
Насчёт смартфонов точно ничего сказать не могу, думаю там всё было ещё лучше.
А теперь о текущих требованиях и раке ПО
Рак прикладного ПО. Что я подразумеваю? Использование кучи библиотек, Electron, Node.js и много ещё чего. То что раньше занимало 100-200 кБ, сейчас разрастается до 200 мБ и, будучи запущенным, жрёт много ресурсов. Это те самые приложения для банкинга с мессенджером и открытками, страховкой, планировкой бюджета, заказом автозапчастей и лекарств, антивирусом и антиспамом, картами и геометками, хранилищем для документов, бонусной программой и подписками, ИИ (куда без него!) - экосистема всё-в-одном. На Хабре всё это обсуждалось: 1 2 3 4 5 6 - вместе с критикой: 1. Тренд неоспорим. Зачем так делать? С таким подходом любое железо будет тормозить: разработчики постоянно надеются, что рост памяти, частот, ядер перекроет любые огрехи их "жручего" софта.
Пользуясь интернет-банкингом через браузер, каждый раз сталкиваюсь с тормозами: захожу на сайт банка, нажимаю "Интернет-банк", и... Сайт не прогружается с первой попытки. Два раза обновляю страницу. Появляется анимация загрузки, ещё 5-10 секунд ожидания и... Всё это чтобы отрисовать хедер, поле для ввода номера, кнопку подтверждения и всплывающее окно о cookies. Вы серьёзно?! 5 элементов на странице. С этим навороченный смартфон, который намного мощнее бюджетного мобильника 2005ых, должен справляться за миллисекунды!
Мидлет Opera Mini 3 справлялся с отрисовкой всей страницы полностью - всеми разделами, текстом, таблицами, картинками, работая через GPRS, через прокси со сжатием, в J2ME-машине на "слабом железе". Да, это было неудобно, но работало. В 2005ом писать компактные и быстрые программы ещё умели, сам подход к разработке был другим.
UPD.: Насчёт ****бчика: если запускать видео в UHD, то конечно его мобильники не потянут. Но на телефоне оно и не нужно: 360р, на край 480р - хватит. Проблемы с производительностью видео в те годы решались переконвертацией. Был и другой вариант, например, у нетбуков: установка специфичных кодеков, CoreAVC. Думаю, с помощью аппаратно-программных ухищрений воспроизводить стриминг (тот же **Tube) вполне возможно и на старых ПК. Плюс можно загружать видео через сторонние утилиты.
Думаю, выжить можно и с производительностью, меньшей чем у iPhone.
Будущее может быть разным: совместная кооперация, технологическое рабство с угнетением или добровольно-принудительная пятилетка за три года своими силами... Этого предсказать нельзя, даже повлиять нельзя - только прикинуть сценарии. Имхо, лучше заранее приготовиться, чем внезапно оказаться в худшем положении.
Это не троллинг. Другое дело, что sloc измеряется в десятках тысяч, ну и человеко-часы соответственно. Плюс, их всё ещё можно здорово сократить засчёт грамотной архитектуры с отсутствием дублирования функционала.
Что до городов... От них отказываться не надо, а вот деревни поддерживать - очень даже необходимо. Деревня город кормит.