сигнал идет до земли 14 часов надо этому зонду РЕЗКО одним пакетом
Поздно будет пить боржоми делать резкие движения :)
по теме — может быть будут применения, но чем дальше, тем дороже оптимизировать код vs увеличить обьем/скорость железа.
ЗЫ. NASA работает над протоколами для космической связи, толерантными к задержкам и множественностью путей. Кому-то повезет делать upgrade на вояджере :)))) или соседей попросим.
Ну что за бред про революцию. Вы видно до этого никогда 256 байт интро не видели. И кстати в России есть демокодер Digimind, который делает не хуже, а даже и лучше :) pouet.net/groups.php?which=1941
Посмотри внимательно как голосуют сценеры на Pouet — Tube от Baze который до этого был эталоном 256 byte через пару суток будет смещен с своих позиций которы он держал с 2000 г.
Под линуксом только «экзешники» (или правильно будет «эльфешники»? :) и нет аналога «комовских» выполнимых файлов?
А если файл загрузить в память и передать на него управление?
Или линукс не даёт напрямую обращаться к видеопамяти? А если из-под рута?
Просто интересно, как оно там, под линуксом. Под досом-то можно было делать, что хочешь.
Ассемблер, как правило, специфичен для конкретной архитектуры, операционной системы и варианта синтаксиса языка, поэтому 99%, что без вайна не запустится. Данная демка скорее всего написана на MASM (код не смотрел).
В линуксе нет прямого обращения к железу, только через ядро, даже из-под рута.
DOSBox народ не рекомендует для нее. Рекомендуют VirtualBox или VirtualPC, но их надо настраивать. Проще запускать виндовый вариант.
Download a virtual machine (VirtualBox (intel) or VirtualPC (amd or older) ) and install ms-dos on it. It will run really faster than dosbox (almost same speed as guest cpu).
I know it requires a little more tweaking than DOSBox at first (specially if you want to use a soundcard) but once you have created and configurated your virtual machine its really easy to use. also: all of these products are free.
На самом деле windows версия действительно более менее нормально запускается (я предупреждал о проблемах с DOS версией). Смотрите ее и просто апроскимируйте в голове что это 512 байт.
> заодно заставляет задуматься, насколько много ресурсов поедает ОС (сравнив размеры кода под DOS и Windows).
Ну что за глупость? Даже если оставить в стороне вопросы выравнивания и PE-заголовков, то как вообще размер файла коррелирует с ресурсами, поедаемыми ОС?
Размер файла — ничем не ресурс ОС.
Это просто константа (в случае исполняемого файла — специфичная для конкретного исходного кода и конкретного компилятора).
Ну что ж, кому как :)
Если без дураков — в инете неоднократно пробегали статьи (по-моему, и на хабре было), что можно продать какую-нибудь двушку-трёшку в крупном городе у нас и переехать в виллу на Гоа, где будет инет и хабр ;)
Продавать не надо. При нынешних ценах на сдачу жилья в Москве для жизни на Гоа хватает даже сдачи однушки. А на проданную 2-3 квартиру можно построить роскошный дом и замутить неслабый бизнес.
Если кого-то это прет.
О чём задуматься? Вот мне только в голову приходит, что да, данную конкретную интруху можно запихать в данный конкретный объём. Дальше этого мысль не простирается :)
Так мы это так и рассмотриваем, это автор поста начал зачем-то ВНЕЗАПНО придумывать этому какие-то из… пальца сосанные примеры практической применимости.
Эти примеры немного не для аудитории Хабра — точнее не для подавляющего количества людей. Они для простых юзернеймов которые знают что в байте 8 бит, а буквы можно написать в Word и отправить письмо через Outlook в соседний кабинет.
Типичному читателю Хабра разжовывать не надо — он по первому абзацу все поймет, а по ссылкам найдет искомое.
ну положим с смс-кой сравнивать некорректно, все таки такие демки упаковывают UPX или чем нибудь подобным, поэтому реальный размер байткода, который разворачивается в память, выше в 2-5 раз.
И как тут ужать UPX если сам распаковщик кучу места занимает, да и обычно в данных демках код генерируется на лету. Занимался на Z80 демомейкингом, писал в 128 и 256 байт эффектики небольшие, которые разворачивались на всю память компа и код исходной демки крайне тяжко ужимался.
300 бод для Вояджера многовато. Скорость обмена данными с аппаратом «Новые горизонты», запущенного в 2007 году, когда он достигнет Плутона в 2015 году, составит 768 бод.
Данная тема в очередной раз натолкнула меня на определённые размышления в продолжение вотэтих топиков. Помимо ОС я также краем уха слышал о том, что некоторые умельцы частично переписывают некоторые игры на «ассемблере» (по-моему, это были несколько уровней в Думе). И всё это весит и «кушает» сущие копейки. Так вот, будучи человеком очень далёким от программирования, прошу разъяснить сведущих людей некоторые моменты (заранее извиняюсь за возможные некорректные высказывания или термины).
Я понимаю, что написание на «ассемблере» гораздо трудозатратнее, но совершенно не представляю насколько. Мне было бы интересно сравнение написания таких программ как Notepad, Firefox и, например, игры «Ведьмак», на том языке, на котором они существуют, и «ассемблере». Я имею ввиду именно сравнение количества программистов и временного отрезка. Также хочу узнать, какие трудности помимо времени препятствуют развитию данной «технологии».
Ну и на последок, есть ли какое-то реальное будущее у подобного пути развития, если верить в тот факт, что увеличение производительности железа не безгранично, а также учитывая возникающие проблемы с энергосбережением и т.п.
Дело в том, что как показывает практика разработки ПО, скорость разработки прямо зависит от количества строк в программе, причем зависимость от языка программирования довольно незначительна. Иначе говоря, если программа А занимает по 1000 строк, будучи написанной на языке X и Y, то трудозатраты на разработку будет примерно одинаковыми.
Таким образом получается, что ввиду того, что языки высокого уровня генерят десятки и сотни строк ассемблера на свою каждую строку, то и трудозатраты будут соответственно выше. Зависимость не сильно линейная, ибо на ассемблере делают более оптимальный код, но все же речь идет как минимум о разах, а то и десятках раз.
Понятно, что на ассемблере можно делать макросы и т.п., что сокращает время на разработку, и порой существенно, но в конечном итоге это еще один способ сокращения кол-ва строк, делая ассемблер более «высокоуровневым».
У языка программирования есть такой относительный параметр как лаконичность.
Выражается средним числом строк на ассемблере эквивалентным 1 строке на каком-то другом языке программирования.
ассемблер = 1 (одна строка на асме = 1 строка на асме)
Си = 4
С++ = 6 (это на вскидку, я чисел точных не помню)
Чем больше — тем меньше строк занимает программа (но от этого она меньше памяти занимать не будет) ее текст легче воспринимать, работать с ним
Вот и вся разница в трудоемкости
Как-то не особо понятно про строчки :)
Какая-нибудь строчка типа:
std::copy(sl.begin(), sl.end(), std::ostream_iterator<std::complex>(std::cout, " "));
Займёт довольно много строчек на си и уж уйму на аммеблере.
Выражается СРЕДНИМ числом строк. А различного рода надстройки в виде библиотек и фрэймворков для того и нужны, чтобы эту лаконичность еще улучшить.
А приведенный вами пример — да, целая большая куча асма :) Целый алгоритм
Был сайт такой 256b.com, но он куда-то улетучился, подобных цикличных 3D эффектов было несколько штук, плюс куча всего интересного сверх того, типа игр в 256 байт. Все это было с исходниками. Но, это очень круто. Одно дело написать пламя или плазму и уложиться в те же 256 байт, а другое дело вот это! :)
Для контраста: сейчас, снеся лиц. неро для того чтоб поставить CDXPBurner (просто для записи дисков) пришлось ставить DotNet метров 200 загадивший диск…
Слышал где-то что в пиндосии если ваша программа мало занимает и ставится менее 10 минут — коммерческого интереса вызывать не будет и продажи будут идти плохо...(типа что мол программа может если она за 2 секунды ставится) увы.
Вид сабжа напоминает внутренности какого-то наноассемблера. Вот, кстати, еще одна потенциальная сфера применения подобного микронанокода:) — девайсы, в которых по определению функционал должен быть минимальным.
Puls — революция в 256 byte intro