Хотел посмотреть как это выглядит в ленте статей (есть ли ссылка, или вообще ничего нет), но вы, хабр показывает только 50 страниц, а статья явно где-то раньше.
Я все сохраняю в mhtml. Для этого достаточно в браузере на базе хрома включить опцию save-page-as-mhtml. Но вот все спойлеры приходится открывать заранее перед сохранением, это явно какая-то недоработка формата (они же наверняка не по ajax запрашиваются при открытии, а сразу приходят вместе со страницей? в общем непонятно)
POD - фигня полная, если я вижу вашу персональную страничку в браузере, то ничто не мешает мне скопировать эти данные себе в оффлайн, в каком бы POD они там на стороне сервера не хранились. Интернет - это пространство свободы, и пора уже понять, что все что один раз попало в интернет - там и остается, навсегда.
Главную опасность для Интернета представляют даже не корпорации, а государства. В особенности авторитарные государства. Это сила куда более могущественная чем все корпорации вместе взятые, и именно неограниченная власть государств является основным вызовом для современной цивилизации.
Как вообще можно пользоваться интернетом через эту штуку? Ведь интернет - это всегда обмен. Даже простейший 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 килобайта.
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз. Хотя возможно ли это для интерпретируемого языка, в котором код теоретически может сам по себе сгенерироваться в рантайме? Может потому так и не делают...
На mega.nz
Хотел посмотреть как это выглядит в ленте статей (есть ли ссылка, или вообще ничего нет), но вы, хабр показывает только 50 страниц, а статья явно где-то раньше.
Я все сохраняю в mhtml. Для этого достаточно в браузере на базе хрома включить опцию save-page-as-mhtml. Но вот все спойлеры приходится открывать заранее перед сохранением, это явно какая-то недоработка формата (они же наверняка не по ajax запрашиваются при открытии, а сразу приходят вместе со страницей? в общем непонятно)
Это какая конкретно статья?
Кстати, было бы неплохо собрать все такие статьи в архив и распространять скажем торрентом.
POD - фигня полная, если я вижу вашу персональную страничку в браузере, то ничто не мешает мне скопировать эти данные себе в оффлайн, в каком бы POD они там на стороне сервера не хранились. Интернет - это пространство свободы, и пора уже понять, что все что один раз попало в интернет - там и остается, навсегда.
Главную опасность для Интернета представляют даже не корпорации, а государства. В особенности авторитарные государства. Это сила куда более могущественная чем все корпорации вместе взятые, и именно неограниченная власть государств является основным вызовом для современной цивилизации.
Как вообще можно пользоваться интернетом через эту штуку? Ведь интернет - это всегда обмен. Даже простейший 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 килобайта.
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз. Хотя возможно ли это для интерпретируемого языка, в котором код теоретически может сам по себе сгенерироваться в рантайме? Может потому так и не делают...
Да и сама тема эзотерических языков регулярно всплывает. Первый раз еще можно почитать ради прикола, следующие разы уже скучно:)
Хоть бы написали где этот файл скачать))