Как вообще можно пользоваться интернетом через эту штуку? Ведь интернет - это всегда обмен. Даже простейший GET запрос сайту и ответ на него - это двунаправленный обмен.
Я имею в виду сделать такое непосредственно в процессоре (как если бы мы разрабатывали процессор с новой архитектурой). Не таблично, не алгоритмически, а именно комбинаторно. Биты угла преобразуем напрямую в биты синуса с помощью сложного каскада логических вентилей.
Зачем такое нужно? Да просто интересна сама возможность, чисто теоретически. Интересно будут ли в такой схеме прослеживаться какие-то закономерности по мере увеличения разрядности.
Интересно, пробовали ли получить логическую функцию для вычисления синуса побитово напрямую (хотя-бы для fixed point представления углов и самого синуса)? По типу того как получают код для семисегментного индикатора по числу, через карты Карно и прочее.
Эх... фундаментальный недостаток всех анонимных сетей - это сами IP-адреса как таковые. Что мешает цензуроумышленникам отправлять такие же письма таким же скриптом, и сразу же автоматически вносить полученные адреса в списки блокировок?
Phind пишет что там есть хардлинки и симлинки, но нет альтернативных файловых потоков, расширенных атрибутов или чего-то подобного. Для меня это уже критично.
Настолько надёжна, что, если копировать на диск файлы в несколько потоков (из-под линукс), то диск потихоньку умрёт
Если это так, то вообще это очень важная информация, явно требующая отдельных исследований (и статей на Хабре:) ). К сожалению, разработчики различных ОС до сих пор не породили единый универсальный стандарт современной файловой системы. И приходится выбирать между существующими системами... в частности в какой ФС должны быть (внешние) диски для хранения данных? Думаю что большинство выбирает именно NTFS, просто потому что у большинства винда, NTFS кажется достаточно надежной по сравнению с FAT, и Линукс тоже умеет с ней работать. А вот насколько хорошо умеет?
XOR это обратимая симметричная операция и очень удобна для того, чтобы быстро обновлять хеш файла при изменении хеша одного блока этого файла. Конечно, большие файлы как правило read-only, но допустим, у вас есть файл на несколько гигов, вы дописали в конец несколько байт. При классическом подходе нужно пересчитать хеш для всех этих нескольких гигов. При моем - только для измененного блока.
Интересный проект. Сайт в браузере с моноширинным шрифтом выглядит потрясающе.
Вообще, играя в такие системы, было бы интересно заменить ассемблер каким-то своим языком программирования, но так чтобы по возможности не получить ни единого лишнего байта при компиляции. Это весьма любопытно потому, что потенциально позволило бы получить в высокоуровневом языке абстракции, вероятно не имеющие аналогов даже в Си, и соответственно обогатить языки программирования как таковые какими-то новыми подходами.
Пишут что в линуксовых ФС есть extended file attributes (XFA, xattrs), в яблочной HFS+ есть "forks". Отличие XFA от ADS в том что там размер вроде как фиксированный и равен размеру блока ФС. Это конечно немного напрягает концептуально, но в целом для тегов подходит (строчка с тегами редко занимает больше 10..20 байт). Но если там хранить много разной метаинформации, то конечно лучше чтобы ограничений не было.
Еще обратил внимание на то, что в статье упоминаются "контрольные суммы". Это довольно интересно, потому что давно уже есть потребность иметь хеши для файлов на уровне ФС без их явного пересчета (особенно актуально для больших файлов, гигабайты и более). ZFS и Btrfs вроде как поддерживают sha256 для блоков данных, и используют их для контроля целостности данных; при изменении блока рассчитывается (и очевидно где-то сохраняется) и его хеш. Имея хеши блоков, вполне можно было бы поддерживать и хеши файлов на уровне ФС, как простой XOR хешей всех блоков файла (причем очевидно, что при изменении блока достаточно сделать XOR хеша файла со старым хешем блока, посчитать новый хеш блока и сделать XOR хеша файла с новым хешем блока, т.е. пересчитывать хеши всех блоков файла не надо). Иметь готовые хеши на уровене ФС очень удобно, к примеру для различных децентрализованных пиринговых сетей. А вот винда (ReFS) как всегда пошла другим путем и хеши там всего лишь 64-битные (а в NTFS их нет вообще), что для идентификации файла во всяких DHT совершенно недостаточно.
Мне кажется и в Windows и в Linux полно легаси... только оно разное. Взять хотя-бы все эти bash скрипты, это же ужас какой-то а не язык. Аналогично make-файлы (впрочем на мой взгляд все системы сборки странные). Да и сам язык Си уже порядком устарел, инклуды и макросы это далеко не самое лучшее решение.
А в винде много корпоративного шлака. Но NTFS мне нравится, в ней есть ADS которые я приспособил для хранения тегов к файлам. В связи с предстоящим неизбежным переходом на линукс пока непонятно, есть ли там аналог (говорят что есть какие-то "расширенные атрибуты", но не факт что это то же самое). Вообще очень жаль что не пошли по пути интеграции ФС и БД, как предполагалось... это было бы очень вкусно.
Непонятно зачем в вашей статье картинки, которые тоже отжирают мегабайты, когда можно было просто написать текстом или лучше табличкой:) Ну да ладно.
Я вообще далек от современной web-разработки. Сейчас у меня есть домашний проект - веб-интерфейс к социальному графу вконтакте. Там всякое - скачивание, пагинация (классическая а не эти дурацкие бесконечные прокрутки), поиск, фильтрация, установка тегов, сортировка, но сделано все абсолютно минималистически без каких-бы то ни было фреймворков и украшательств (я их просто не знаю). js-файл к этому 12 килобайт:) и css 3 килобайта.
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз. Хотя возможно ли это для интерпретируемого языка, в котором код теоретически может сам по себе сгенерироваться в рантайме? Может потому так и не делают...
Супер:) Это уже не просто "в стиле" а прямо точная копия (на самом деле я не имел в виду точную копию win95, а скорее подразумевал просто строгие классические оконные интерфейсы с хорошо продуманным дизайном, которые были в до-планшетные времена, но попробовать вот такую точную имитацию тоже весьма интересно).
А что лучше с точки зрения легковесности, быстродействия, стабильности, распространенности софта - Lubuntu/LXQT или Xubuntu/XFCE?
Я не настолько часто пользуюсь линуксом, но был период когда немного пользовался Linux Mint. У меня там что-то случилось с меню "пуск". Уже не помню точно что именно, но какой-то жуткий баг, возможно все надписи исчезли (хотя сами пункты меню остались и по ним "вслепую" можно было нажимать) или что-то типа такого. В общем давно уже остановился на Lubuntu, с этой вроде все нормально пока:)
Еще ведь есть TeX, который тоже язык разметки и появился на 15 лет раньше html. Я его не знаю, но пару раз сталкивался (кажется на форуме dxdy), и этого оказалось достаточно чтобы понять - хорошая штука, для формул точно лучше чем громоздкий MathML.
Кстати, а какой DE в Linux максимально классический (в стиле Windows 95/98/2000, строгие и четкие рамки и заголовки окон, никакой помеси десктопа и тачскрина, минимум пустого места в диалоговых окнах) и легковесный (никаких "визуальных эффектов" вообще не надо). И при этом чтобы это была не редкая экзотика, а что-то распространенное.
На виртуалке с линуксом использую LXQT в Lubuntu, в целом все достаточно неплохо, но вдруг есть еще что-то получше? Из недостатков которые с ходу приходят в голову - неразвитость средств интеграции в контекстное меню, в частности многие программы под Linux, умеющие интегрироваться в контекстное меню, про PCManFM не знают.
Как вообще можно пользоваться интернетом через эту штуку? Ведь интернет - это всегда обмен. Даже простейший GET запрос сайту и ответ на него - это двунаправленный обмен.
Я имею в виду сделать такое непосредственно в процессоре (как если бы мы разрабатывали процессор с новой архитектурой). Не таблично, не алгоритмически, а именно комбинаторно. Биты угла преобразуем напрямую в биты синуса с помощью сложного каскада логических вентилей.
Зачем такое нужно? Да просто интересна сама возможность, чисто теоретически. Интересно будут ли в такой схеме прослеживаться какие-то закономерности по мере увеличения разрядности.
Интересно, пробовали ли получить логическую функцию для вычисления синуса побитово напрямую (хотя-бы для fixed point представления углов и самого синуса)? По типу того как получают код для семисегментного индикатора по числу, через карты Карно и прочее.
Эх... фундаментальный недостаток всех анонимных сетей - это сами IP-адреса как таковые. Что мешает цензуроумышленникам отправлять такие же письма таким же скриптом, и сразу же автоматически вносить полученные адреса в списки блокировок?
Phind пишет что там есть хардлинки и симлинки, но нет альтернативных файловых потоков, расширенных атрибутов или чего-то подобного. Для меня это уже критично.
Если это так, то вообще это очень важная информация, явно требующая отдельных исследований (и статей на Хабре:) ). К сожалению, разработчики различных ОС до сих пор не породили единый универсальный стандарт современной файловой системы. И приходится выбирать между существующими системами... в частности в какой ФС должны быть (внешние) диски для хранения данных? Думаю что большинство выбирает именно NTFS, просто потому что у большинства винда, NTFS кажется достаточно надежной по сравнению с FAT, и Линукс тоже умеет с ней работать. А вот насколько хорошо умеет?
XOR это обратимая симметричная операция и очень удобна для того, чтобы быстро обновлять хеш файла при изменении хеша одного блока этого файла. Конечно, большие файлы как правило read-only, но допустим, у вас есть файл на несколько гигов, вы дописали в конец несколько байт. При классическом подходе нужно пересчитать хеш для всех этих нескольких гигов. При моем - только для измененного блока.
А зачем блокчейн?
Интересный проект. Сайт в браузере с моноширинным шрифтом выглядит потрясающе.
Вообще, играя в такие системы, было бы интересно заменить ассемблер каким-то своим языком программирования, но так чтобы по возможности не получить ни единого лишнего байта при компиляции. Это весьма любопытно потому, что потенциально позволило бы получить в высокоуровневом языке абстракции, вероятно не имеющие аналогов даже в Си, и соответственно обогатить языки программирования как таковые какими-то новыми подходами.
Пишут что в линуксовых ФС есть extended file attributes (XFA, xattrs), в яблочной HFS+ есть "forks". Отличие XFA от ADS в том что там размер вроде как фиксированный и равен размеру блока ФС. Это конечно немного напрягает концептуально, но в целом для тегов подходит (строчка с тегами редко занимает больше 10..20 байт). Но если там хранить много разной метаинформации, то конечно лучше чтобы ограничений не было.
Еще обратил внимание на то, что в статье упоминаются "контрольные суммы". Это довольно интересно, потому что давно уже есть потребность иметь хеши для файлов на уровне ФС без их явного пересчета (особенно актуально для больших файлов, гигабайты и более). ZFS и Btrfs вроде как поддерживают sha256 для блоков данных, и используют их для контроля целостности данных; при изменении блока рассчитывается (и очевидно где-то сохраняется) и его хеш. Имея хеши блоков, вполне можно было бы поддерживать и хеши файлов на уровне ФС, как простой XOR хешей всех блоков файла (причем очевидно, что при изменении блока достаточно сделать XOR хеша файла со старым хешем блока, посчитать новый хеш блока и сделать XOR хеша файла с новым хешем блока, т.е. пересчитывать хеши всех блоков файла не надо). Иметь готовые хеши на уровене ФС очень удобно, к примеру для различных децентрализованных пиринговых сетей. А вот винда (ReFS) как всегда пошла другим путем и хеши там всего лишь 64-битные (а в NTFS их нет вообще), что для идентификации файла во всяких DHT совершенно недостаточно.
Мне кажется и в Windows и в Linux полно легаси... только оно разное. Взять хотя-бы все эти bash скрипты, это же ужас какой-то а не язык. Аналогично make-файлы (впрочем на мой взгляд все системы сборки странные). Да и сам язык Си уже порядком устарел, инклуды и макросы это далеко не самое лучшее решение.
А в винде много корпоративного шлака. Но NTFS мне нравится, в ней есть ADS которые я приспособил для хранения тегов к файлам. В связи с предстоящим неизбежным переходом на линукс пока непонятно, есть ли там аналог (говорят что есть какие-то "расширенные атрибуты", но не факт что это то же самое). Вообще очень жаль что не пошли по пути интеграции ФС и БД, как предполагалось... это было бы очень вкусно.
А вот интересно, что там такого дает ассемблер что не дают языки типа Си?
Непонятно зачем в вашей статье картинки, которые тоже отжирают мегабайты, когда можно было просто написать текстом или лучше табличкой:) Ну да ладно.
Я вообще далек от современной web-разработки. Сейчас у меня есть домашний проект - веб-интерфейс к социальному графу вконтакте. Там всякое - скачивание, пагинация (классическая а не эти дурацкие бесконечные прокрутки), поиск, фильтрация, установка тегов, сортировка, но сделано все абсолютно минималистически без каких-бы то ни было фреймворков и украшательств (я их просто не знаю). js-файл к этому 12 килобайт:) и css 3 килобайта.
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз. Хотя возможно ли это для интерпретируемого языка, в котором код теоретически может сам по себе сгенерироваться в рантайме? Может потому так и не делают...
Да и сама тема эзотерических языков регулярно всплывает. Первый раз еще можно почитать ради прикола, следующие разы уже скучно:)
Хоть бы написали где этот файл скачать))
Супер:) Это уже не просто "в стиле" а прямо точная копия (на самом деле я не имел в виду точную копию win95, а скорее подразумевал просто строгие классические оконные интерфейсы с хорошо продуманным дизайном, которые были в до-планшетные времена, но попробовать вот такую точную имитацию тоже весьма интересно).
А что лучше с точки зрения легковесности, быстродействия, стабильности, распространенности софта - Lubuntu/LXQT или Xubuntu/XFCE?
Я не настолько часто пользуюсь линуксом, но был период когда немного пользовался Linux Mint. У меня там что-то случилось с меню "пуск". Уже не помню точно что именно, но какой-то жуткий баг, возможно все надписи исчезли (хотя сами пункты меню остались и по ним "вслепую" можно было нажимать) или что-то типа такого. В общем давно уже остановился на Lubuntu, с этой вроде все нормально пока:)
Еще ведь есть TeX, который тоже язык разметки и появился на 15 лет раньше html. Я его не знаю, но пару раз сталкивался (кажется на форуме dxdy), и этого оказалось достаточно чтобы понять - хорошая штука, для формул точно лучше чем громоздкий MathML.
Кстати, а какой DE в Linux максимально классический (в стиле Windows 95/98/2000, строгие и четкие рамки и заголовки окон, никакой помеси десктопа и тачскрина, минимум пустого места в диалоговых окнах) и легковесный (никаких "визуальных эффектов" вообще не надо). И при этом чтобы это была не редкая экзотика, а что-то распространенное.
На виртуалке с линуксом использую LXQT в Lubuntu, в целом все достаточно неплохо, но вдруг есть еще что-то получше? Из недостатков которые с ходу приходят в голову - неразвитость средств интеграции в контекстное меню, в частности многие программы под Linux, умеющие интегрироваться в контекстное меню, про PCManFM не знают.
Ну может лет через 100 его вытащат и поместят в музей:)
Прозрачный экран идеально подошел бы для прозрачного тюремного ноутбука :)