Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE.
Я понимаю. Непонятен конкретный выбор ninja в качестве системы сборки. CMake — это прекрасный инструмент, практически не имеющий альтернатив, если проект кроссплатформенный. CMake умеет генерировать файлы под практически все системы сборки (включая msbuild). Посему остается непонятным, зачем нужно вводить дополнительный инструмент и какие преимущества он дает.
А вот можете это подробней раскрыть?
Если совсем подробно, то нужна будет целая статья. А то и не одна.
Если вкратце — то по моему личному опыту и мнению, разработка в IDE способна снизить самодисциплину. А она очень важна, когда речь идет о качестве кода.
Поясню, о чем речь. Когда программист пишет код, он пишет его в первую очередь для других программистов. Именно для того, чтобы код легче читался и понимался, придуманы тонны coding style guide'ов. Соблюдение всех этих правил и требует от программиста самодисциплины.
IDE слишком многое делает для и за программиста. Довольно часто это приводит к тому, что программист в упор не понимает, зачем нужно правильное оформление кода. Зачем лишние пробелы? Все же и так хорошо видно — IDE подсвечивает! Зачем разбивать длинные строки, ведь в IDE же все автоматически переносится? Да еще и экран у меня широкий — мне удобнее, когда весь код в одну строчку! Зачем разносить по файлам разные функции — IDE же предлагает их все в одном файле создавать! И так далее.
Неполный перечень примеров из реальной жизни:
— чувак в упор не понимал, почему функция с 20 аргументами — это плохо. «Все аргументы же в подсказках описываются, когда код вводишь!».
— другой товарищ в упор не понимал, зачем нужно разбивать на несколько файлов исходник в 200 Кб. При том, что там содержались функции, абсолютно друг с другом не связанные логически. «А чо, вот же слева есть навигатор — любая функция там легко находится, и не надо весь файл скроллить!».
— еще один гражданин упорно писал код строками длиной в 200-300 символов, да еще и с комментами на русском языке. «У меня же все видно!». Его не смущало даже то, что комментарии при коммите превращались в фарш, ибо сервер стоял в Германии и не умел работать с кириллицей. Попытки достучаться до здравого смысла наталкивались на железобетонную стену: «у меня все нормально, проблема на той стороне».
Это все, конечно, мелочи. Но с вышеупомянутыми гражданами проблемы были и посерьезнее: коммиты, которые ломают билд; нежелание осваивать новые инструменты, если они не интегрированы в их IDE; конфликтное поведение и «закукливание» в ответ на любую критику.
Я не утверждаю, что все беды от IDE. Но в некоторых случаях «прикипание» к IDE может привести к обострению проблем у асоциальных и аутичных личностей, а следовательно — к снижению качества их работы.
Помню, один знакомый товарищ намучился с такими вот «вижулятниками» и пошел своим путем: перешел на консольный vim, отключил подсветку синтаксиса и автоматический перенос строк. На его код было любо-дорого взглянуть. Потом, правда, все равно уволился. :)
Главное — зачем.
Допустим, с CMake все понятно — это кроссплатформенная замена autoconf. А вот зачем нужен ninja — не совсем ясно. MSys вроде как идет с утилитой make, под которую CMake вполне себе умеет генерировать файлы: cmake -G «UNIX Makefiles». Если отказаться от сурового опенсорца и собирать MSVC компилятором с тамошней утилитой nmake, то CMake и такое умеет: cmake -G «NMake Makefiles».
А в чем смысл юзать ninja? Непонятно.
Если вы так же, как и я, живёте в компьютере, а не только включаете его в рабочие часы, предлагается следующая схема: перед началом программирования добавлять MinGW в PATH, а после — убирать. Для облегчения процесса нужно сделать два батника, которые можно запускать двойным щелчком:
Все это уже придумано до вас. Если интересно — замарайте руки установкой visual studio community и посмотрите, как там реализован developer command prompt. По факту — это батники, которые запускаются по щелчку и выставляют огромную кучу всякого полезного. Более того, в зависимости от аргументов тамошние батники умеют выставлять окружение для разработки под разные платформы (x86, x64, arm). Самый цимес — все это выставляется только внутри запущенной консольки и не уродует систему.
Т.е. если вам действительно хочется собирать проекты из командной строки, можно разложить по десктопу батники: «g++ x64», «g++ x86», «msvc x64», «msvc x86» и т. п. Ткнул — открылось окно консольки, где все уже настроено для запуска нужной версии компилятора с нужными путями.
Тогда можно одновременно собирать, например, 32-битные и 64-битные бинари в разных окошках.
Не скажу за h0t_max, а лично я всегда считаю человека небезнадежным, пока он не докажет обратное. Автор интересуется шифрованием — это хорошо. Автор берется реализовать самописную шифрульку — это тоже неплохо.
Плохо, что автор так и не смог найти внятных введений в криптографию. Нахватался где-то терминов, понял их как смог, написал что попало.
В дополнение к книге Брюса Шнайера рекомендую homoastricus купить и почитать Книгу шифров Саймона Сингха. Написана очень легким языком, читается запоем. Просто и доходчиво объясняются базовые концепции криптографии. Пойдет в качестве введения и этакого исторического экскурса в криптографию. После нее книги Шнайера читаются и понимаются не в пример легче.
1. То, что homoastricus называет «приватным ключом», на самом деле и является единственным ключом шифрования в его системе. «Публичный» ключ в этой системе — это всего лишь соль.
2. Автор путает кодирование и шифрование (отсюда, например, радостные утверждения, будто кодирование одного исходного символа двумя символами шифротекста есть борьба с частотным анализом). Если бы автор отвлекся от печатных символов и начал свою систему шифрования «из байтов в байты», было бы проще понять эту ошибку. А закодировать в печатный текст можно уже после шифрования. Благо, кодировок для этого придумано выше крыши: хочешь — хексами байты изображай, хочешь — Base64, а ежели совсем на хардкор тянет — есть ascii85.
3. Странный набор результирующих символов. Проблема в том, что строки, состоящие из сплошной пунктуации, не очень подходят для передачи по каналам связи методом копи-пасты. Прикиньте, сколько смайликов найдет в такой строке какой-нибудь мессенджер. :)
4. При анализе системы шифрования исходят из того, что все исходники есть у атакующей стороны. Все шифрование у автора построено вокруг одной таблицы пермутаций, которая строится по фиксированному хэшу (плюс какие-то прыжки вокруг присланной снаружи соли — лень было разбираться). А это значит, что атакующему достаточно выяснить «приватный ключ» (сиречь — единственный ключ шифрования), и он сможет прочесть всю переписку. Что-то мне подсказывает, что подобрать содержимое таблицы, имея энное количество перехваченных сообщений, вполне себе решаемая задача.
Прошу прощения, при пуше, конечно. Хотя пуш от коммита, думаю, не особо отличается в плане изменений в файлах репозитория.
Был у меня скриптик, который синхрил git-репозиторию между флэшкой и диском. Пофайлово. Не спрашивайте зачем, так было надо. :)
Так вот, если в репозиторию запушить пару-тройку коммитов, скрипт выдавал примерно такие цифры: 15 файлов добавлено, 2 изменено. Менялся в основном, конечно, .git/refs/heads/master и еще что-то там, не помню уже что.
Совсем любое облачное хранилище использовать не получится.
Например, если вы попытаетесь для гит-репозитории использовать Google Drive (aka Google Sync), вас ждет множество удивительных сюрпризов. Эта падла иногда самовольно переименовывает файлы (добавляет и удаляет "(1)" после имени). Да и с синхронизацией у них проблемы бывают — то файлы недососет, то старую версию обновить отказывается…
Так было сделано про изготовлении 1801вм1, так было сделано при создании 486 (RISC ядро притворяющееся CISC процессором)
Ну, во времена 486-х технологии уже шагнули далеко вперед. Да и система команд в 486-м была всего одна, хоть и очень развесистая. А в древности, к которой относится 1801вм1, вряд ли можно было на кристалл ужать достаточно всего, чтобы микропрограммы стали действительно универсальными. Но задел был интересный, согласен.
Мне кажется, вы смешиваете в кучу сегодняшние реалии (стандартизованная блочная архитектура, документированные наборы инструкций) и «то самое» время.
Давайте разберем, зачем в принципе могла понадобиться поддержка нескольких ISA в рамках одного процессора.
— Выбор наиболее эффективной системы команд для решения задачи? Возможно. Но это имеет смысл, если задачи очень специфические. Иначе вполне подходит обычная, универсальная система команд.
— Имитация какого-то определенного процессора? Тоже вариант. Но не забываем, что придется имитировать и особенности тех машин, в которых этот процессор работает изначально, иначе программы придется долго и нудно адаптировать (превратить Радио 86 в Спектрум путем перепрошивки процессора из 8080 в z80 не получится). Да, кое-какие программы работают через сервисы операционной системы, так что теоретически можно было бы просто поставить адаптированный вариант CP/M и радоваться. Но в те времена, о которых мы говорим, таких программ было мало. А уж игр — вообще исчезающе мало, разве что написанные на бейсике могут пойти без адаптации (и то не все).
Кроме того, здесь уже писали о том, что реализация команд в микропрограммах вряд ли имитирует тайминги (время работы команд в тактах). Это сейчас нам пофиг, сколько там тактов занимает исполнение одной инструкции, а в те времена на тайминги процессора было завязано очень много что. Задержки в играх, тактирование при записи на магнитофон, таймауты при работе с оборудованием и т. п.
Что мы имеем в остатке? Удел таких процессоров — специализированное оборудование. Для имитации уже существующих систем они вряд ли подойдут: придется имитировать и другую аппаратуру тех систем, и не факт, что результат будет работать удовлетворительно.
Вот если поменять сценарий применения и изначально планировать такие процессоры к использованию в «своей», перспективной и расширяемой системе архитектур — тогда да, система имела бы потенциал. Скажем, пользователь мог бы добавить поддержку чисел с плавающей точкой простым накатыванием апдейта на систему. Да и архитектура команд была бы адаптирована под особенности реализации процессора — т.е. не приходилось бы «для галочки» реализовать команды, которые на железе будут исполняться долго и неэффективно.
Тогда да, была бы выгода от унификации и масштабирования производства.
К сожалению, все похерили.
Поскольку процессор микропрограммный то что он будет читать и исполнять, код Z80, 6502, 8086 решается программно, какую пьесу дадим ту и играть будет, сегодня Отелло, завтра Ромео. В чем профит? в эффекте масштаба производства и гибкости. В конце концов в компьютере главное — это программы.
В компьютере главное — совместимость на уровне программ. Иначе нет смысла городить огород с поддержкой различных наборов инструкций.
Для того времени, о котором мы говорим, программы обращались напрямую к железу (особенно игры). Допустим, команды процессора мы задаем идеально — все работает как надо, вплоть до недокументированных команд. А с периферией что будем делать? В разных системах программный доступ к периферии организован по-разному: где-то есть отображение на память, где-то через порты ввода-вывода.
В общем, вряд ли будет возможно перейти от Ромео к Отелло в рамках одной системы — придется и периферию соответственно менять. Так что особой выгоды от такого процессора я лично не вижу.
Недавно мне пришлось поменять дефолтное загрузочное ядро на компьютере Linux, который использовал GRUB2. Я обнаружил, что некоторые команды перестали работать корректно, или же я пользовался ими как-то некорректно. До сих пор не знаю, в чем была проблема, потребуется больше времени на ее исследование.
«Дорогая редакция! У меня который год в подполе происходит подземный стук».
Проблема у него, итить его в качель коромыслом… Вот когда grub2 после штатного обновления ядра перестает грузить вообще все — вот это проблема так проблема.
Сценарий:
— обновляем ядро штатным обновлятором Ubuntu. Заодно обновляется и grub.
— все прекрасно, ядро обновилось, grub переконфигурировался, дело за малым — перезагрузиться в новое ядро.
— перезагружаемся и видим страшное: вместо красивой рамочки вокруг меню grub — псевдографика из знаков вопроса, а при выборе любого пункта меню (включая memtest86+) grub пишет что-то невнятное про ненайденную команду '[' и попытку чтения-записи за пределами диска hd0.
После расследования выясняется следующее:
— grub не на всех материнках умеет адресовать сектора диска за пределами первых 8 Гб.
— Ubuntu по умолчанию ставится на один большой раздел, куда кладет как /boot, так и все остальные папки.
— после очередного обновления образ ядра и модули grub (который тоже обновился) попали за пределы первых 8 гигов. Grub их прочитать не может, и как следствие — не может ничего загрузить.
Вот это — проблема. А у автора — так, подземный стук.
Краткий пересказ: «Делайте как надо, а как не надо — не делайте».
Придет в винду пользователь мака и будет плеваться. Потому что у него ожидания другие. И что теперь делать проектировщику гуйни? Все как в маке проектировать? Так не получится.
В общем случае мы не знаем, что за привычки и ожидания у пользователя от интерфейса. Мы можем только догадываться. Посему все эти мудрствования и философствования — ни о чем.
Приведенные мной цитаты говорят о том, что по части разработки отставания у нас не было или было минимальным.
До примерно 1971 года — да. Потом, ЕМНИП, вышел указ об использовании «успешно зарекомендовавших себя» западных наработок в качестве основы для построения отечественных ЭВМ.
Как результат, отечественные исследования в области вычтехники захирели. Ну и — вполне закономерно — началось отставание: ведь для того, чтобы западный образец был признан «успешным», нужно было как минимум дождаться его выхода в серийное производство. И только после этого начиналась работа по его реверс-инжинирингу, оптимизации, адаптации к нашим условиям производства и т. п.
Даже ПК сделанные по мотивам стандарта MSX/MSX2 ПК8000/8002, Aleste 520EX отличались оригинальными схемотехническими решениями
Был у меня в детстве ПК8000 «Веста». Прекрасный был аппарат.
Что касается «оригинальных схемотехнических решений», то они в основном сводились к упрощению и удешевлению производства. Как шутили в те годы: «в наших машинах много чего можно включить напрямую» (хотя имелись в виду, конечно, автомобили).
IMHO я думаю что была допущена большая ошибка что ядро микропроцессора ВМ1801 не сделали конфигурируемым ядром процессоров разных систем команд (Z80, 8088, 68000).
А что, в ВМ1801 использовался какой-то микрокод? Мне всегда казалось, что наши инженеры смогли стянуть только то, что было «отлито» на кристалле. Как только пошел микрокод — начались проблемы с «цельнотянутым методом» (аналог 386-го процессора лепили чуть ли не десять лет).
Посмотрел спеки К1801ВМ1 — это же клон PDP-11, 16-разрядный процессор. Как его в 8-разрядные переделывать, у него же распиновка для этого не подходит? А главное — зачем?
При рождении генетически дается определенный фиксированный набор очков навыков.
Если вы в это действительно верите — у меня для вас плохие новости.
Я даже не говорю о том, что навык — это то, что вырабатывается повторением деятельности («навыкание делать»). Все еще проще. Никаких «очков навыков» генетика вам не дает. Если у человека две руки, две ноги, полный комплект органов и нет явных отклонений в развитии — он может заниматься абсолютно любой деятельностью при должном воспитании и обучении.
А по каким признакам вы предлагаете определять, мертвый сервис или еще жив? На рамблере почта и сейчас работает, и даже можно новый ящик завести. Какие-то сервисы они закрывают, какие-то открывают — ну так и гугель тем же самым занят.
Я понимаю. Непонятен конкретный выбор ninja в качестве системы сборки. CMake — это прекрасный инструмент, практически не имеющий альтернатив, если проект кроссплатформенный. CMake умеет генерировать файлы под практически все системы сборки (включая msbuild). Посему остается непонятным, зачем нужно вводить дополнительный инструмент и какие преимущества он дает.
Если совсем подробно, то нужна будет целая статья. А то и не одна.
Если вкратце — то по моему личному опыту и мнению, разработка в IDE способна снизить самодисциплину. А она очень важна, когда речь идет о качестве кода.
Поясню, о чем речь. Когда программист пишет код, он пишет его в первую очередь для других программистов. Именно для того, чтобы код легче читался и понимался, придуманы тонны coding style guide'ов. Соблюдение всех этих правил и требует от программиста самодисциплины.
IDE слишком многое делает для и за программиста. Довольно часто это приводит к тому, что программист в упор не понимает, зачем нужно правильное оформление кода. Зачем лишние пробелы? Все же и так хорошо видно — IDE подсвечивает! Зачем разбивать длинные строки, ведь в IDE же все автоматически переносится? Да еще и экран у меня широкий — мне удобнее, когда весь код в одну строчку! Зачем разносить по файлам разные функции — IDE же предлагает их все в одном файле создавать! И так далее.
Неполный перечень примеров из реальной жизни:
— чувак в упор не понимал, почему функция с 20 аргументами — это плохо. «Все аргументы же в подсказках описываются, когда код вводишь!».
— другой товарищ в упор не понимал, зачем нужно разбивать на несколько файлов исходник в 200 Кб. При том, что там содержались функции, абсолютно друг с другом не связанные логически. «А чо, вот же слева есть навигатор — любая функция там легко находится, и не надо весь файл скроллить!».
— еще один гражданин упорно писал код строками длиной в 200-300 символов, да еще и с комментами на русском языке. «У меня же все видно!». Его не смущало даже то, что комментарии при коммите превращались в фарш, ибо сервер стоял в Германии и не умел работать с кириллицей. Попытки достучаться до здравого смысла наталкивались на железобетонную стену: «у меня все нормально, проблема на той стороне».
Это все, конечно, мелочи. Но с вышеупомянутыми гражданами проблемы были и посерьезнее: коммиты, которые ломают билд; нежелание осваивать новые инструменты, если они не интегрированы в их IDE; конфликтное поведение и «закукливание» в ответ на любую критику.
Я не утверждаю, что все беды от IDE. Но в некоторых случаях «прикипание» к IDE может привести к обострению проблем у асоциальных и аутичных личностей, а следовательно — к снижению качества их работы.
Помню, один знакомый товарищ намучился с такими вот «вижулятниками» и пошел своим путем: перешел на консольный vim, отключил подсветку синтаксиса и автоматический перенос строк. На его код было любо-дорого взглянуть. Потом, правда, все равно уволился. :)
Главное — зачем.
Допустим, с CMake все понятно — это кроссплатформенная замена autoconf. А вот зачем нужен ninja — не совсем ясно. MSys вроде как идет с утилитой make, под которую CMake вполне себе умеет генерировать файлы: cmake -G «UNIX Makefiles». Если отказаться от сурового опенсорца и собирать MSVC компилятором с тамошней утилитой nmake, то CMake и такое умеет: cmake -G «NMake Makefiles».
А в чем смысл юзать ninja? Непонятно.
Все это уже придумано до вас. Если интересно — замарайте руки установкой visual studio community и посмотрите, как там реализован developer command prompt. По факту — это батники, которые запускаются по щелчку и выставляют огромную кучу всякого полезного. Более того, в зависимости от аргументов тамошние батники умеют выставлять окружение для разработки под разные платформы (x86, x64, arm). Самый цимес — все это выставляется только внутри запущенной консольки и не уродует систему.
Т.е. если вам действительно хочется собирать проекты из командной строки, можно разложить по десктопу батники: «g++ x64», «g++ x86», «msvc x64», «msvc x86» и т. п. Ткнул — открылось окно консольки, где все уже настроено для запуска нужной версии компилятора с нужными путями.
Тогда можно одновременно собирать, например, 32-битные и 64-битные бинари в разных окошках.
Заблуждение.
Плохо, что автор так и не смог найти внятных введений в криптографию. Нахватался где-то терминов, понял их как смог, написал что попало.
В дополнение к книге Брюса Шнайера рекомендую homoastricus купить и почитать
Книгу шифров Саймона Сингха. Написана очень легким языком, читается запоем. Просто и доходчиво объясняются базовые концепции криптографии. Пойдет в качестве введения и этакого исторического экскурса в криптографию. После нее книги Шнайера читаются и понимаются не в пример легче.
1. То, что homoastricus называет «приватным ключом», на самом деле и является единственным ключом шифрования в его системе. «Публичный» ключ в этой системе — это всего лишь соль.
2. Автор путает кодирование и шифрование (отсюда, например, радостные утверждения, будто кодирование одного исходного символа двумя символами шифротекста есть борьба с частотным анализом). Если бы автор отвлекся от печатных символов и начал свою систему шифрования «из байтов в байты», было бы проще понять эту ошибку. А закодировать в печатный текст можно уже после шифрования. Благо, кодировок для этого придумано выше крыши: хочешь — хексами байты изображай, хочешь — Base64, а ежели совсем на хардкор тянет — есть ascii85.
3. Странный набор результирующих символов. Проблема в том, что строки, состоящие из сплошной пунктуации, не очень подходят для передачи по каналам связи методом копи-пасты. Прикиньте, сколько смайликов найдет в такой строке какой-нибудь мессенджер. :)
4. При анализе системы шифрования исходят из того, что все исходники есть у атакующей стороны. Все шифрование у автора построено вокруг одной таблицы пермутаций, которая строится по фиксированному хэшу (плюс какие-то прыжки вокруг присланной снаружи соли — лень было разбираться). А это значит, что атакующему достаточно выяснить «приватный ключ» (сиречь — единственный ключ шифрования), и он сможет прочесть всю переписку. Что-то мне подсказывает, что подобрать содержимое таблицы, имея энное количество перехваченных сообщений, вполне себе решаемая задача.
Der kører allerede en anden programdæmon.
После дешифровки получаем рэзультат:
Der krer allerede en anden programdmon.
Чудесный шифер, ящетаю. :)
Был у меня скриптик, который синхрил git-репозиторию между флэшкой и диском. Пофайлово. Не спрашивайте зачем, так было надо. :)
Так вот, если в репозиторию запушить пару-тройку коммитов, скрипт выдавал примерно такие цифры: 15 файлов добавлено, 2 изменено. Менялся в основном, конечно, .git/refs/heads/master и еще что-то там, не помню уже что.
Например, если вы попытаетесь для гит-репозитории использовать Google Drive (aka Google Sync), вас ждет множество удивительных сюрпризов. Эта падла иногда самовольно переименовывает файлы (добавляет и удаляет "(1)" после имени). Да и с синхронизацией у них проблемы бывают — то файлы недососет, то старую версию обновить отказывается…
Ну, во времена 486-х технологии уже шагнули далеко вперед. Да и система команд в 486-м была всего одна, хоть и очень развесистая. А в древности, к которой относится 1801вм1, вряд ли можно было на кристалл ужать достаточно всего, чтобы микропрограммы стали действительно универсальными. Но задел был интересный, согласен.
Давайте разберем, зачем в принципе могла понадобиться поддержка нескольких ISA в рамках одного процессора.
— Выбор наиболее эффективной системы команд для решения задачи? Возможно. Но это имеет смысл, если задачи очень специфические. Иначе вполне подходит обычная, универсальная система команд.
— Имитация какого-то определенного процессора? Тоже вариант. Но не забываем, что придется имитировать и особенности тех машин, в которых этот процессор работает изначально, иначе программы придется долго и нудно адаптировать (превратить Радио 86 в Спектрум путем перепрошивки процессора из 8080 в z80 не получится). Да, кое-какие программы работают через сервисы операционной системы, так что теоретически можно было бы просто поставить адаптированный вариант CP/M и радоваться. Но в те времена, о которых мы говорим, таких программ было мало. А уж игр — вообще исчезающе мало, разве что написанные на бейсике могут пойти без адаптации (и то не все).
Кроме того, здесь уже писали о том, что реализация команд в микропрограммах вряд ли имитирует тайминги (время работы команд в тактах). Это сейчас нам пофиг, сколько там тактов занимает исполнение одной инструкции, а в те времена на тайминги процессора было завязано очень много что. Задержки в играх, тактирование при записи на магнитофон, таймауты при работе с оборудованием и т. п.
Что мы имеем в остатке? Удел таких процессоров — специализированное оборудование. Для имитации уже существующих систем они вряд ли подойдут: придется имитировать и другую аппаратуру тех систем, и не факт, что результат будет работать удовлетворительно.
Вот если поменять сценарий применения и изначально планировать такие процессоры к использованию в «своей», перспективной и расширяемой системе архитектур — тогда да, система имела бы потенциал. Скажем, пользователь мог бы добавить поддержку чисел с плавающей точкой простым накатыванием апдейта на систему. Да и архитектура команд была бы адаптирована под особенности реализации процессора — т.е. не приходилось бы «для галочки» реализовать команды, которые на железе будут исполняться долго и неэффективно.
Тогда да, была бы выгода от унификации и масштабирования производства.
К сожалению, все похерили.
В компьютере главное — совместимость на уровне программ. Иначе нет смысла городить огород с поддержкой различных наборов инструкций.
Для того времени, о котором мы говорим, программы обращались напрямую к железу (особенно игры). Допустим, команды процессора мы задаем идеально — все работает как надо, вплоть до недокументированных команд. А с периферией что будем делать? В разных системах программный доступ к периферии организован по-разному: где-то есть отображение на память, где-то через порты ввода-вывода.
В общем, вряд ли будет возможно перейти от Ромео к Отелло в рамках одной системы — придется и периферию соответственно менять. Так что особой выгоды от такого процессора я лично не вижу.
«Дорогая редакция! У меня который год в подполе происходит подземный стук».
Проблема у него, итить его в качель коромыслом… Вот когда grub2 после штатного обновления ядра перестает грузить вообще все — вот это проблема так проблема.
Сценарий:
— обновляем ядро штатным обновлятором Ubuntu. Заодно обновляется и grub.
— все прекрасно, ядро обновилось, grub переконфигурировался, дело за малым — перезагрузиться в новое ядро.
— перезагружаемся и видим страшное: вместо красивой рамочки вокруг меню grub — псевдографика из знаков вопроса, а при выборе любого пункта меню (включая memtest86+) grub пишет что-то невнятное про ненайденную команду '[' и попытку чтения-записи за пределами диска hd0.
После расследования выясняется следующее:
— grub не на всех материнках умеет адресовать сектора диска за пределами первых 8 Гб.
— Ubuntu по умолчанию ставится на один большой раздел, куда кладет как /boot, так и все остальные папки.
— после очередного обновления образ ядра и модули grub (который тоже обновился) попали за пределы первых 8 гигов. Grub их прочитать не может, и как следствие — не может ничего загрузить.
Вот это — проблема. А у автора — так, подземный стук.
Придет в винду пользователь мака и будет плеваться. Потому что у него ожидания другие. И что теперь делать проектировщику гуйни? Все как в маке проектировать? Так не получится.
В общем случае мы не знаем, что за привычки и ожидания у пользователя от интерфейса. Мы можем только догадываться. Посему все эти мудрствования и философствования — ни о чем.
До примерно 1971 года — да. Потом, ЕМНИП, вышел указ об использовании «успешно зарекомендовавших себя» западных наработок в качестве основы для построения отечественных ЭВМ.
Как результат, отечественные исследования в области вычтехники захирели. Ну и — вполне закономерно — началось отставание: ведь для того, чтобы западный образец был признан «успешным», нужно было как минимум дождаться его выхода в серийное производство. И только после этого начиналась работа по его реверс-инжинирингу, оптимизации, адаптации к нашим условиям производства и т. п.
Был у меня в детстве ПК8000 «Веста». Прекрасный был аппарат.
Что касается «оригинальных схемотехнических решений», то они в основном сводились к упрощению и удешевлению производства. Как шутили в те годы: «в наших машинах много чего можно включить напрямую» (хотя имелись в виду, конечно, автомобили).
А что, в ВМ1801 использовался какой-то микрокод? Мне всегда казалось, что наши инженеры смогли стянуть только то, что было «отлито» на кристалле. Как только пошел микрокод — начались проблемы с «цельнотянутым методом» (аналог 386-го процессора лепили чуть ли не десять лет).
Посмотрел спеки К1801ВМ1 — это же клон PDP-11, 16-разрядный процессор. Как его в 8-разрядные переделывать, у него же распиновка для этого не подходит? А главное — зачем?
В квипе не выковыривала. Вместо пароля показывалось что-то типа [[PASSWORD]]
Если вы в это действительно верите — у меня для вас плохие новости.
Я даже не говорю о том, что навык — это то, что вырабатывается повторением деятельности («навыкание делать»). Все еще проще. Никаких «очков навыков» генетика вам не дает. Если у человека две руки, две ноги, полный комплект органов и нет явных отклонений в развитии — он может заниматься абсолютно любой деятельностью при должном воспитании и обучении.