@sbflowers, пока сезон и погода позволяет, что там насчёт той моей старой идеи попробовать вырастить растение из смеси каллуса груши и черноплодки? Если повезёт и оно стабилизируется в мозаичную химеру типа биззарии (биццарии), размножаемую вегетативно — получится весьма полезный и вкусный миниатюрный удобный кустик :)

Ну, и бюджет эксперимента с точностью хотя бы до порядка (а лучше — до двоичного порядка). Чтобы я знал, потяну ли :)

Сегодня на арене пятничного цирка — очередной проект, за который я уже никогда не возьмусь.

Это осциллограф на ЭЛТ от монитора. Суть несложная — поворачиваем старичка вертикально, на кадровую развёртку (у которой обмотки с большой индуктивностью и на высокую частоту их не раскачаешь) подаём от 30 до сколько уж там выдержит герц «пилы». Получается ось X.

На бывшую строчную — исследуемый сигнал, в последнем каскаде лепим дико высоковольтный транзистор (которые и производились в своё время именно затем, чтобы остановить злобную самоиндукцию строчной развёртки), токоизмерительный шунт, с шунта заводим потенциал на ООС — получаем преобразователь входных вольт в выходные амперы (которые в отклоняющей катушке). Транзистор, наверное, придётся охлаждать Ниагарским водопадом :-D Но строчная уже спокойно может разглядеть и отработать не один десяток килогерц, что делает прибор уже более чем просто сувениром :) По крайней мере, на оси Y звук мы уже разглядим.

Через мелкую ёмкость измеряем первую производную от входного сигнала и её модуль закидываем на, правильно, Z. Чтобы не прожечь люминофор при рисовании прямой, но чтобы было что-то видно при бешено мечущемся уровне. Можно ещё пушки переключать, чтобы было три входа, работающих по очереди.

Разумеется, если у вас какие-то свои идеи развлечений с этими дудками — welcome :) А я и так задолжал тут пару обещанных статей, если не больше :( На такие вещи, как это чудо-юдо — меня уже никогда, видимо, не хватит… короче, #отдамдаром.

Предлагаю на выходных гипотетически подумать, как можно быстро и легко доработать сервер Minecraft так, чтобы можно было запустить несколько штук в одном мире (допустим, 16 серверов на 8 человек). Не, никто реально ничего делать не собирается, просто задачка для ума :)

Для определённости положим, что синхронизировать происходящее между серверными процессами мы не будем. Каждый работает сам по себе.

Проблему с миром вчерне решить несложно: кто первый загрузил чанк, того и тапки. Остальные получают read-only и их игроки не могут там строить и копать (вокруг всё «запривачено»). Оптимизировать тоже не очень трудно — небольшой алгоритм группировки игроков на серверах и выбора, кому именно отдать чанк при наличии рядом нескольких серверов-кандидатов (чтобы пореже сталкивались с «чужими» чанками).

А вот как быть с сущностями? Примерно понятно, что происходить с ними могут одновременно разные вещи в одной локации, если её взяли несколько серверов. Но как быть потом с изменениями в сущностях, чтобы можно было, допустим, за лутом вернуться, выгрузив-загрузив чанк? Как мерджить это от нескольких серверов?

Есть очевидные варианты, а есть хорошие. Меня увлекла задача поискать вторые :) и я приглашаю поломать голову со мной :)

Первый — стирлинг Белецкого с фазовым переходом, который он обещал показать почти 10 лет назад, но что-то как-то не задалось… может быть, в виде холодильника идея жизнеспособна? Будет ли хладагент сжижаться и вскипать там, где надо, или будет плескаться только на дне? Будет ли он при этом проникать в нужных количествах где нужно, или уменьшение объёма при сжижении поставит крест на прокачке его из цилиндра в цилиндр?

Второй — классический «Морозко», упрощённый (в ущерб и без того кислому КПД) до уровня школьной демонстрационной модели. Вода нагревается, растворимость аммиака падает, а сжижаться сам по себе он при такой температуре не хочет даже под давлением — в результате они прощаются и идут охлаждаться в раздельные радиаторы, после чего, может быть, и жалеют о содеянном — а назад пути уже нет :) Остывший аммиак сжижается пассивным давлением, царящим во всей системе, после чего в левой ветке остывшая вода «через водород» снова его «впитывает», образуя исходный раствор.

Основная функция водорода тут — не мешать аммиаку испаряться при условии равенства давлений слева и справа. Нам совершенно не нужно, чтобы он испарялся справа, мешая конвекции, потому что справа его «некому забрать», но справа царит более-менее равновесное состояние насыщающих паров, поэтому там он и не спешит испаряться. Слева же паров аммиака мало (сплошной водород), поэтому испаряется он охотно, но не создавая падения давления, которое могло бы «пробить колено раковины» (выражаясь сантехническим языком).

А что, если объекты с очень высоким градиентом гравитационного поля (ЧД, нейтронные звёзды…) имеют бо́льшую массу, чем видится снаружи?

Что, если на порождение излучения Хокинга жрётся не только масса, но и сами гравиволны?

Что, если притяжение может быть асимметричным из-за того, что тело имеет большую массу и сильно притягивается к другому, но не может ответить взаимностью более чем на 99,9999%, а 0,0001% теряется? И за счёт чего будет работать закон сохранения массы и закон сохранения импульса при таком раскладе?

Простите, у меня пятница и высокая температура.

В копилку к ZX-Poly и неведомому широким массам адаптеру на «Денди» (кстати, что это, кто-то может рассказать?) держите кусочек пятничного ретро.

Навеяно статьёй о портах Doom и поскрёбышем Спектрум-128, у которого доступ ко вторым 64К был постраничный (не знаю, правда, что там с обратной совместимостью…)

Идея использовать «Денди» в качестве внешнего графического ускорителя, несомненно, как раз из категории тех вещей, которые упустили свой шанс завоевать мир — хотя явно могли. Какой-никакой, а графоний с аппаратными спрайтами-с. Но если речь идёт о Doom или хотя бы о Wolf3D, нужны скалеры столбцов. Или хотя бы строк: небольшой телевизор и набок можно положить.

Это приводит нас к такой ретро-игрушке: полметра-метр оперативки, к которой доступ производится поочерёдно от «Спекки» (через окошко, как в 128-м) и от счётчика. Счётчик формирует видеосигнал «на лету», собирая строку из указанных в стартовой (служебной) области памяти данных.

А фишка в том, что счётчик (видеосигнал-то аналоговый!) берёт из служебной области не только адрес и размер, но и скорость, с которой он «ползёт» по данным. Забиваем память тайлами и спрайтами, а в служебной области обновляем указания для счётчика — откуда сколько и чего брать. Они маленькие.

Получается вполне себе «2dFX» — можно и спрайты отскейлить, задавая разные скорости и разное число повторений одной строки, и даже Wolf3D сделать — только на боку.

Если заморочиться с рефрешем DRAM, можно даже на «рассыпухе» спаять. Даже на «рассыпухе» из тех лет.

Я опять зашёл набросить на вентилятор — и в кусты, а кто решится это на практике проверить — тот опять не я:‑D

Итак, очень пятничная концепция 3D‑принтера. Берём длинную шпильку М12×0.5, да, такое существует, в этом‑то вся и прелесть (ну, или можно нарезать без станка — плашки выпускаются, метчики тоже). Пропускаем через две гайки, на торце делаем столик размером с хорошее велосипедное колесо (12 мм стали, если более‑менее соблюдать развесовку относительно центра, за просто так не согнёшь). Получается такая «табуретка пианиста».

Над ней по такой же (или другой похожей) шпильке бегает, разумеется, сам экструдер. С соплом в те же полмиллиметра, потому что всё равно имеем явно девайс для грубой печати крупняка (столик за один оборот отступает от экструдера на 0.5 мм, соответственно, толщина слоя всегда и неизбежно 0.5 мм).

А поскольку крупняк печатать хочется бросовым пластиком, то экструдер делаем пеллетным: «горячая» часть (показана жёлтым) состоит из точно дозирующего насоса типа «восемь‑бесконечность» и системы грубого оплавления (коническое дно, к которому некая злая сила прижимает бедные пеллеты), а «холодная» часть (показана синим) делается по вкусу, допустим, бункер с прижимным поршнем, или канализационная гофра со шнеком внизу, или ещё как‑то, лишь бы придавливала пеллеты к, так сказать, предварительной оплавлялке.

В камментах это по отдельности было, сейчас просто свёл в общую концепцию.

Ещё одна вещь, которую я ни в жисть делать не стану — «но идея хороша» (© стишок про ужа, чижа, ежа, ерша…) Ретро-VHS-приставка из восьмибитного контра и старого видака. Как те, доисторические, но с точной перемоткой к нужному кадру, чтобы можно было полноценный платформер замутить, и Микки Маус Освобождённый прыгал вместе с Кроликом Освальдом в точности на том фоновом кадре, на котором надо.

Износ кассеты, точное совмещение спрайта пиксел-в-пиксел с чёрт-те-каким аналоговым сигналом фона, короче, будет весело. Но не мне :) Я пас :) Хорошо хотя бы прошивка какой-нибудь «тиньки» позволяет заметную часть железа решить софтово, а за саму игру пусть отвечает интерпретатор, грузящий её код с той же кассеты. В сумме, с поправкой на тормознутость интерпретатора, будет вполне аутентично — как если бы недопроцессор той эпохи при помощи кучи плат рассыпухи делал всё это аппаратно, включая загрузку кода игры и совмещение спрайтов с фоном.

Поскольку эта суббота является суперпятницей, держите суперпятничное: представьте себе мышку с двумя хвостами, встроенным свитчем, кнопкой переключения и разъёмом под SODIMM.

Для того, чтобы сделать Ctrl+C на одном компе, а Ctrl+V — на другом. А аппаратный буфер обмена — в мышке. Сунуть старую бучную планку «сколько не жалко» и развлекаться :)

Может, можно даже как-то сделать там секьюрный Air Gap, чтобы можно было обменяться только той информацией, которой пользователь открытым текстом приказывает обменяться. Ну, чтобы это не было шизой ради шизы. Но как именно — ХЗ.

Хотя это не обязательно — суперпятница же! Сделайте хаб «Клиника дяди Финика» для ненормального, но не только программирования :)

Студентом я мечтал скрестить Doom II, Fallout II и, не смейтесь, Minecraft — но, поскольку его ещё даже в проектах не было, за него отдувался не менее квадратный Rise of the Triad, к которому я додумал более гибкую геометрию блоков (получился по сути Minecraft).

Открытый мир (сгенерированный) с квестовыми городами (созданными умелыми руками всяких Петерсенов), и шастать вслепую не хватит никакой жизни — чтобы найти новую локацию, надо искать зацепки. Зачистить старую от «футболов» с «козлами» и посмотреть документы. Найти не до конца разбитую железную или автомобильную дорогу, которая куда-то да ведёт. Логически допереть, что тут с точки зрения логистики и инфраструктуры что-то обязано быть. И бои, бои, бои — в локациях открытого мира, в путешествиях, в (разумеется) квестовых городах! В основе всего всё-таки Doom :)

И, конечно, в конце главный демон обрушивается в клубах пыли, а все его деяния откатываются.

И только ручной какодемон Сильвестр всё ещё пытается сожрать последнюю канарейку на Земле — до чего же упрямая скотина…

Ну, крафт оружия на тот момент уже напрашивался, тут я не был оригинален. Ещё не был мейнстримом, но уже напрашивался. А вот движок тогдашнее железо едва ли бы потянуло. Даже упрощённый. Хотя вот когда оно дотянуло — блажь попробовать хотя бы движок мне в голову всё-таки ударила, уже без связи со несбывшимися мечтами, конечно.

А сейчас все такое пишут, лол :) Но в сеттинге Doom II, увы, в это вряд ли получится поиграть. Порты такое не потянут.

Представьте себе такой девайс. USB-бокс для харда, на боку — переключатель аппаратной защиты от записи, сверху — несколько кнопочек, снизу — коннектор типа оптоволоконного, только плоский.

Если защита от записи выключена, хард видится обычным макаром. Если же включена — вдобавок к нему определяется последовательный порт, по которому девайс отдаёт в терминал старый добрый Нортон Коммандер (вернее, клон под тот контроллер, на котором это чудо-юдо будет крутиться).

Оперируя кнопочками на девайсе, можно в обход защиты от записи работать с отдельными файлами (если, конечно, файловая система этому контроллеру понятна). Главная там операция — это копирование чего-то на второй такой же диск, тихо-мирно сложенный в стопочку с первым так, чтобы их оптоконнекторы совпали (ну или с него). Да, файловая система при этом будет меняться втихую от компа, к которому они подключены, но в read-only это не самая большая проблема, да и можно просто «отвалиться» с первым изменением, чтобы не смущать ОС уже на самом компе.

«Вторая главная» операция — конечно же, сравнение двух деревьев директорий вместе с содержимым файлов.

Назначение девайса, как вы все уже догадались — бэкапы и синхронизация в условиях «никому нельзя верить». От утечек, конечно, не спасёт (хотя можно на переключателе сделать и третье положение «Только терминал»), но хотя бы обеспечит то, что в момент копирования данных на диске назначения не произойдут какие-то загадочные несанкционированные изменения типа шифрования…

Замутим? ;)

Интересно, а как бы выглядел «модульный телефон наоборот» — не он состоит из модулей, а он сам является модулем? Допустим, в нём 8 ядер на низкой частоте, пассивное охлаждение, 4 гига оперативки и системная флэшка. С нормальным линуксом пользоваться вполне уже можно.

Одну боковую стенку делаем сдвижной и там лепим коннектор «во всю стену». При втыкании его в ноутбуко-образную докстанцию он подключается не только к дополнительному харду и «экспрессу», но и к паре слотов оперативки (естественно, всё придётся выключить-включить, как старую приставку при смене картриджа), задняя стенка прижимается к обдуваемому радиатору (здрасте, нормальные частоты) и так далее. Экран вполне может занять место тачпада.

Или, допустим, снимаем с этой докстанции экран и втыкаем телефон прямо в него. В экране ничего особенно интересного нет, он просто расширяет телефон до планшета.

Или, допустим, в экране-то и спрятано внешнее видеоядро, доступное как в режиме планшета, так и в режиме ноутбука. И дополнительный аккумулятор на сдачу. А телефон при этом вообще сзади, с выключенным экраном.

Не, ну я в курсе про попытки такое сделать, но если подключить по USB телефон к докстанции, ноутбуком это не станет, а станет фигнёй с телефоньими мозгами, но в форме ноутбука. Я же себе это представляю, как видите, «ваще по хардкору» — включая даже расширение оперативки (ох и коннектор же понадобится…), ну и, конечно, сам весь остальной ноут должен быть модульным как минимум на уровне «Мышиного заговора» или выше :)

Если кому-то нужна минималистичная 32-битная библиотека в стиле 90-х, обеспечивающая запуск unrar.dll в отдельном треде и прозрачный доступ к файлам «как если бы они были просто на диске» — вот эта давно заброшенная мной штучка на последний момент так и не показала ни одной рассинхронизации тредов, как я её ни сношал рандомными обращениями при рандомных задержках.

Умеет копать, умеет не копать. Памяти жрёт немного, синхронизация максимально быстрая (перед каждым wait проверяет атомарки — может, надо сразу следующую часть распаковывать, не дёргая апи), но, увы, не умеет плодить несколько тредов распаковки с автоматическим выбором того, где окно распаковки ближе всего к запрошенному файлу («солидные» архивы бы сильно выиграли по скорости от такого подхода).

Есть задатки FindNext — если всё равно, в каком порядке читать, то «солидолки» быстрее всего читать через эту функцию.

АЭС я бы этой штуке пока не доверил, но для инди-игрушек вполне покатит. Хинт: Рар вроде как-то позволяет задавать порядок, в котором «солидолить» файлы (сиречь добавлять их в непрерывный архив), что можно разумно использовать для ускорения распаковки.

Научите уже кто-нибудь нейросети диагностировать те же ноутбуки, например. Камера, четыре щупа, база данных по элементной базе и ИИ, способный быстро пройтись щупами по тем же мосфетам, например. Хотя бы просто отличать пробитые от живых.

А то у́чите-у́чите всякой фигне, тот же г*внокод совершенно спокойно и без ИИ можно писать тоннами. И наукоподобную чушь генерировать, полную фактических ошибок и вымышленных «фактов» (вспоминается тот модуль из «Портала», рассуждавший про «этилбензоловые рыбки»). Научите уже своих горе-роботов делать что-то полезное из условно-рутинной деятельности, пусть человек думает, а робот — щупами тыкает.

Интересно, можно ли «здесь и сейчас» имеющимися УФ-лазерами что-то писать на кварцевые диски (с распределённой по объёму взвесью мелкодисперсного технического серебра, если я не ошибаюсь), добившись для начала хотя бы одного-двух гигов за коммерчески доступные деньги — а потом уже покушаться на фемтосекундники и безумные терабайты, как обещает нам не первый год «а-воз-и-ныне-там-5D-запись»?

Кварц дёшев, практически вечен, техническое серебро стоит копейки и количество его там смешное, если не потребуется какая-то ультра-полировка поверхностей и не намудрят каких-то абсурдных параметров (хотя бы тех же габаритов — форм-фактор чуть толще дискеты идеален и от косого взгляда оно уже не переломится) — взлетит как миленькое. Ещё можно контакты на «дискете» сделать и добавить флэшку там же, чтобы не кидаться по всем ящикам «а где у меня темпы и конфиги от этого дистра, блин?», а «прожигать» уже, так сказать, «устаканившиеся» бэкапы. А ещё лучше — гнездо в уголке под оную, чтобы менять её по мере износа.

Короче, не революция, а эволюция. Начинать понемногу, а там ведь, как те же дискеты, от килобайт до мегабайт пройти, то есть от гигабайт до терабайт в нашем случае… и не забыть аппаратную защиту от записи, которая просто выключателем выключает «писательную» мощность. Экологическая ниша долгосрочного хранения данных простых юзеров (той их части, которая об облака уже обожглась больно) — специфическая и требует многих таких вещей не забывать.

Гибрид кодека и аркадного игрового движка — таким я себе вижу главное наследие технологии Macromedia Flash, царствие ей дискетное.

Нет, серьёзно.

В зоопарке кодеков категорически не хватает особенного кодека (точнее, декодера — обратно провернуть этот фарш не представляется возможным, по крайней мере, на современном уровне технологий всё ещё очень примитивно, см. ниже ↓), базирующегося на принципах «define sprite», «transform sprite» и «show sprite» (а также «…sample» для звука). Ну, и «purge sprite», когда он уже не нужен.

Весь необходимый инструментарий можно подсмотреть в существующих анимационных пакетах (от того же Флэша и Инкскейпа до профессиональных), при этом косясь на то, что творится в супер-мощных супер-жмущих кодеках, выделяющих в растре объекты и движущиеся области и трансформирующих их от кадра к кадру, за счёт чего у них, собственно, и супер-сжатие («я знал, что рано или поздно мы докатимся и до этой дряни», см. выше ↑).

Проще говоря, при рисовании мультика можно будет экспортировать его сразу в этом формате потока, а потом любой стандартный плеер при помощи этого кодека его покажет. И не только: простенькую аркаду можно спокойно свести к формированию игрой видеопотока в этом формате, а выводом (по факту — рендером) будет заниматься первый попавшийся плеер.

Но эта часть уже по сути являет собой возрождение флэш-игр на новый лад! Фактически я описываю парадигму флэша без лишней сущности в виде самого флэша, сведённую к стандартной части мультимедиа — к кодекам.

Что-то чем дальше, тем больше у меня зудит идея минималистичного векторного формата с минималистичным редактором. Форматов полно — но почему-то они все по принципу «а давайте сделаем на основе XML, тогда можно будет сделать Всё, Что Угодно», ну или по ему подобным принципам. В результате вектор весит больше пожатого растра, а редакторы и вьюеры должны тоже предусмотреть безграничный полёт фантазии тех, кто использует этот формат… короче, уже даже хочется убить пару (дюжин, хех) выходных на то, чтобы появился пятнадцатый формат.

Я его вижу как иерархическое дерево чанков неограниченной вложенности, где чанк являет собой поле координат с фиксированной точкой и ограниченным числом бит, и включать он может примитивы а-ля Пэйнт и ссылки на все чанки, которые были определены ранее (1:1, с попиксельным масштабированием отрендеренного чанка или с векторным масштабированием чанка «как есть»).

Получается, что применение зависит только от того, чем забили чанки — радиосхема будет или текстовый документ со вшитыми шрифтами, суть всегда одинаковая. Главное — продумать, где в какую сторону должно разруливаться масштабирование пиксельной сетки, изначально привязанной к фиксированной точке, чтобы не соединить недостатки обоих подходов :)

Короче, отговорите меня, пожалуйста, опять на фигню выходные потрачу.

Интересно, как бы выглядела *buntu-подобная сборка вообще без десктопа? В основе всего — двухпанелька типа Midnight Commander, образующая «незакрываемое» окно, заменяющее рабочий стол. С файлами работать вполне себе. Даже директорию «Desktop» можно сохранить, чтобы не ломать привычки *buntu-дистрибутивов, вот только специальная папка ей не будет соответствовать — это будет просто директория.

Вместо «Пуска» — командная строка внизу, как в «Нортоне», благо Tab позволяет что угодно запустить по двум-трём первым буквам.

Вместо кучи разрозненных гуйных редакторов настроек — набор скриптов, позволяющих быстро находить нужные .conf-файлы и генерировать для них нужное содержимое, а крутить эти скрипты, разумеется, на некоем едином и могучем редакторе-конфигураторе, встроенном в эту «двухпанельку». «Правый клик» (клавиша «меню», что-то ещё, уместное по обстоятельствам) по строчке параметров видеорежима — скрипт сам обращается к xrandr, получает список разрешений и выдаёт перечень допустимых строчек, на которые можно заменить искомую, это для примера. Гуйный конфигуратор без гуйного конфигуратора, ага.

Плюс, заметьте, если настраивается что-то особо нестандартное по железу — всё то же самое доступно хоть через удалённый терминал, удобства автоконфигуратора не зависят от живых Иксов/Вяленого.

Да, такой «швейцарский нож» — это вообще не UNIX-way. Но почему мы не можем попробовать заповедник DOS-way посреди UNIX-way, у нас свободное ПО или ритуально-догматическое?

Будет ли полнофункциональный текстовый браузер жрать больше ресурсов, чем обычный, или же меньше?

Вот посмотрите: с одной стороны, не нужен даже мало-мальски точный рендер шрифтов. Вёрстку можно считать с точностью плюс-минус лапоть, лишь бы понять, что видимое, а что — нет. Нужно просто вычленить видимый текст, видимые изображения и в нужном порядке показать текст, перемежающийся ссылками на файлы изображений. До кучи можно забыть всю кастомизацию и даже куки хранить в оперативке, плюс размер виртуального экрана всегда один.

С другой стороны — все тормознутые матрёшки скриптов всё равно придётся выполнить. Нужно будет не только более-менее слепить страницу, но и достаточно интеллектуально переверстать её в линейную простынку текста, не перемесив содержимое (задача крайне нетривиальная). Современные сайты реагируют на каждый чих и управляются бровью, движениями сфинктеров, стуками по телефону — всем, кроме нормального нажатия на активные элементы. Как-то заэмулировать ввод, чтобы можно было перейти на следующую страницу, когда есть только кнопки консоли — тоже та ещё задача, а если мы делаем совсем «настоящую» консоль (без редактирования ранее выведенного текста) и при добавлении в хвост страницы нового контента (те самые богомерзкие бесконечные бесстраничные ленты) перепечатываем страницу заново — надо определиться, на что реагировать, чтобы какая-то фоновая активность скриптов не приводила к постоянным обновлениям.

Короче, задача тянет уже на неплохой AI, не находите? О_о

А что сейчас с низкоуровневым форматированием хардов? Можно ли, скажем, отключить или как-то пометить убитую сторону, например? Или вообще скомандовать девайсу перенанести служебную разметку, если посыпались ошибки позиционирования?

Как я понимаю, потребуется TTL UART и ломаный протокол команд? Чего там сейчас люди творят на этом поприще?

Эх, верните мне мою FAT с её bad clusters, тотальным host-managed RELO (хотя тогда и слова-то такого не было) и интерливингом секторов… славные времена, когда всё задавалось в файловой системе, а не где-то в чёрном ящике харда :(

Хотя полный host-managed всего на свете в ext4, включая контроль над SMR — это было бы ещё лучше :)