Это не "идея" и не "фича". Это прямое и неизбежное следствие из дизайна. И что характерно, этот дизайн был скопирован всей (как мне кажется) остальной криптой, потому что других работоспособных вариантов у них нет.
"Идея" - это то, что крипту нельзя отследить. Идея, возникшая у людей, не знающих о существовании такой профессии как forensic accounting.
"ничего, что крипта создавалась, чтобы этой лажи не было, потому что ее типа нельзя отследить"
Финансовый продукт, который по определению хранит всю историю транзакций вечно, создавался типа чтобы средства нельзя было отследить. На конкурсе феноменальных залётов этот залёт займёт второе место.
Можно и Doom в терминале запустить, но не лучше ли для просмотра картинок использовать более подходящие инструменты? Раз уж у нас всё равно графический интерфейс, можно открывать новые окошки и т.д. Eierlegende Wollmilchsau это всё-таки сатира, а не руководство к действию.
Юникод уже был: в какой-то момент вместо шрифтов koi8r я стал подключать юникодные, и это было как раз в 2000х. Цвета, очевидно, тоже были, всё тот же десяток, что используется и сейчас.
Ну и по-стариковски покряхчу про "свистелки и перделки": и практически бесконечный scrollback, и многооконность тоже были, но их реализовывал не терминал, а screen/tmux. Вот рендеринга на 140 Hz не было, это факт. Зачем терминалу рендеринг на вдвое более высокой частоте, чем у при игре в шутеры, и даже чем в принципе поддерживает мой монитор - это вообще загадка.
А тупящий терминал я вспомнил, да. Это было окошко command.com под виндой. Там я видел как вывод простыни текста тормозил. Больше нигде.
Что вы вообще делаете с терминалом такое, что он тормозит. Это же относительно простая штука, в 90х и 2000х ни о каких задержках в ней и не слышали: если что-то тормозит, то или Ctrl-S нажали, или сами процессы в сессии тупят.
protobuf это отличная штука, но в данном случае возможно слишком мощная. К тому же придётся искать библиотеку, которая умеет работать без аллокатора и с no_std.
Вы никогда не видели подтекста решений того же комитета по стандартизации C, например? Когда кто-то предлагает "давайте выкинем вот эту грёбаную адову херню", а им другие дружно отвечают "на эту хрень у пользователей нашего копмилятора из автостроения/авиации/финансов/военных/хзчего завязан тулчейн, которым они собирают сертифицированый код из 1997 года, и если вы его сломаете в новом стандарте, то им починить и пересертифицировать будет стоить сто тыщ миллионов и пять лет времени".
Срач между разработчиками ядра FreeBSD и чуваком из комитета по поводу mutex API был когда-то совершенно в духе подростковых форумов.
Если вы не знакомы с корутинами, то перед прочтением "как оно там устроено под капотом" всё-таки стоит познакомиться с ними. Какой смысл изучать хтонические потроха компилятора, если не представляете, какой результат от них ожидается?
А для человека, который понимает что делают корутины, и хорошо бы как они реализованы в других языках, это вполне полезное описание. В C++ довольно запутаный API, у меня чуть голова не лопнула в своё время даже простенькую реализацию корутин написать.
Нельзя в сетевых сервисах падать от ненадёжного мира. Триста кривых клиентов пришло, процесс от них упал - и отвалились соединения ещё с миллионом. А восстанавливать их долго и дорого.
Это не "идея" и не "фича". Это прямое и неизбежное следствие из дизайна. И что характерно, этот дизайн был скопирован всей (как мне кажется) остальной криптой, потому что других работоспособных вариантов у них нет.
"Идея" - это то, что крипту нельзя отследить. Идея, возникшая у людей, не знающих о существовании такой профессии как forensic accounting.
"ничего, что крипта создавалась, чтобы этой лажи не было, потому что ее типа нельзя отследить"
Финансовый продукт, который по определению хранит всю историю транзакций вечно, создавался типа чтобы средства нельзя было отследить. На конкурсе феноменальных залётов этот залёт займёт второе место.
Можно и Doom в терминале запустить, но не лучше ли для просмотра картинок использовать более подходящие инструменты? Раз уж у нас всё равно графический интерфейс, можно открывать новые окошки и т.д. Eierlegende Wollmilchsau это всё-таки сатира, а не руководство к действию.
Юникод уже был: в какой-то момент вместо шрифтов koi8r я стал подключать юникодные, и это было как раз в 2000х. Цвета, очевидно, тоже были, всё тот же десяток, что используется и сейчас.
Ну и по-стариковски покряхчу про "свистелки и перделки": и практически бесконечный scrollback, и многооконность тоже были, но их реализовывал не терминал, а screen/tmux. Вот рендеринга на 140 Hz не было, это факт. Зачем терминалу рендеринг на вдвое более высокой частоте, чем у при игре в шутеры, и даже чем в принципе поддерживает мой монитор - это вообще загадка.
А тупящий терминал я вспомнил, да. Это было окошко command.com под виндой. Там я видел как вывод простыни текста тормозил. Больше нигде.
Как печально, что ОС неспособна догадаться задрать приоритет терминалу. Пропали все полимеры (c)
Что вы вообще делаете с терминалом такое, что он тормозит. Это же относительно простая штука, в 90х и 2000х ни о каких задержках в ней и не слышали: если что-то тормозит, то или Ctrl-S нажали, или сами процессы в сессии тупят.
Никто уже не помнит классику.
Но для этого надо уметь писать код руками. А как известно, для C++ обучение этому навыку занимает как минимум 21 день.
protobuf это отличная штука, но в данном случае возможно слишком мощная. К тому же придётся искать библиотеку, которая умеет работать без аллокатора и с no_std.
Вы никогда не видели подтекста решений того же комитета по стандартизации C, например? Когда кто-то предлагает "давайте выкинем вот эту грёбаную адову херню", а им другие дружно отвечают "на эту хрень у пользователей нашего копмилятора из автостроения/авиации/финансов/военных/хзчего завязан тулчейн, которым они собирают сертифицированый код из 1997 года, и если вы его сломаете в новом стандарте, то им починить и пересертифицировать будет стоить сто тыщ миллионов и пять лет времени".
Срач между разработчиками ядра FreeBSD и чуваком из комитета по поводу mutex API был когда-то совершенно в духе подростковых форумов.
Не допускать старых ошибок для новых технологий можно. Не допускать новых ошибок для новых технологий вряд ли получится.
Мне было бы более интересно узнать, много ли счётчиков именно измеряют напряжение, а не просто считают его константой.
Как вы память на стеке освобождаете вручную в программе на C? В куче всё-таки, наверное.
https://en.wikipedia.org/wiki/Pentium_FDIV_bug ещё никто не приносил, потому что не застали? К вопросу о золотом стандарте точности :)
AI компании смотрят на вас с недоумением и закупают ещё один грузовик GPU.
Если вы не знакомы с корутинами, то перед прочтением "как оно там устроено под капотом" всё-таки стоит познакомиться с ними. Какой смысл изучать хтонические потроха компилятора, если не представляете, какой результат от них ожидается?
А для человека, который понимает что делают корутины, и хорошо бы как они реализованы в других языках, это вполне полезное описание. В C++ довольно запутаный API, у меня чуть голова не лопнула в своё время даже простенькую реализацию корутин написать.
Если бы вместо `int state_;` там было `enum State { state1, state2, state3 } state_;` -- вам понятнее было бы? Это функционально идентичный код.
Ну какой же это Rust, это Haskell :)
Нельзя в сетевых сервисах падать от ненадёжного мира. Триста кривых клиентов пришло, процесс от них упал - и отвалились соединения ещё с миллионом. А восстанавливать их долго и дорого.
"Ты не должен этого хотеть" (c) Яндекс