Пишут что в линуксовых ФС есть 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 не знают.
Написано так что ничего не понятно. Что означает назавание сотового оператора в "пострадавшей стране? Что там в сливе - номера телефонов? Это телефонная база? Или это пароли от твиттера? Или в сливе какой-то софт, трояны, которых удалось внедрить указанным операторам в указанных странах? Или что?
Интересный девайс, но взглянув на картинку я был уверен что это раскладушка. А оказалось что нет. Ну и при такой толщине могли бы ради интереса разместить еще одну камеру на торце (рядом с ИК-светодиодом и лазером).
Qiwi давно не пользуюсь, но на одном из кошельков есть 80 рублей - вчера попытался перевести их на телефон, уже не дает.
А вообще, пользуясь случаем, хочу предложить знающим людям написать статью на Хабр, на тему работы с криптой из РФ для чайников (или хотя-бы накидайте ссылок в комментарии). Вот как-то не интерсовался этим раньше, ну просто это не моё, мне интереснее статью о новом языке программирования почитать, чем углубляться в эту весьма специфическую сферу... но жизнь заставляет.
Кроссплатформа из Swift была бы супер! Сам язык очень интересный. Не такой мозгодробительный как C++ и Rust, но и не такой простой как С или Go. Компилируемый, со строгой статической типизацией, что безусловно плюс. Сбалансированный синтаксис и весьма богатые языковые возможности, при этом в нем еще не накопилось legacy как в C#.
Тогда надо делать полноценную нуллабельность (спецификатор типа "?" и соответствующие операторы). Но кажется уже поздно, в Go указатели нуллабельны, а другие типы - нет, и если делать то получится слегка кривовато как в C#.
Да, смартфоны все больше походят на фотики за счет торчащего "объектива". Тогда бы уж увеличили толщину всего смартфона в целом до толщины "объектива", и разместили в дополнительном объеме что-то полезное.
Что-то навороты какие-то, аж С++ повеяло:) При этом лично я никаких особых потребностей в итераторах и проблем с классическими циклами не испытываю. Ну подумаешь классический цикл с параметром. Зато просто и прозрачно.
Хотя последнее время погрузился в Go, и некоторых вещей действительно не хватает. Самое простое - это как ни странно тернарный оператор c ? x1 : x2 Приходится писать три отдельных строчки кода с объявлением переменной вместо того, чтобы написать нужный код прямо внутри другого выражения.
Еще немного напрягает, что в "методах классов" нет неявного доступа к полям класса
func (app *Applictaion) foo() {
app.x = 100; // ok
x = 100; // error
}
Пишут что в линуксовых ФС есть 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 его вытащат и поместят в музей:)
Прозрачный экран идеально подошел бы для прозрачного тюремного ноутбука :)
Написано так что ничего не понятно. Что означает назавание сотового оператора в "пострадавшей стране? Что там в сливе - номера телефонов? Это телефонная база? Или это пароли от твиттера? Или в сливе какой-то софт, трояны, которых удалось внедрить указанным операторам в указанных странах? Или что?
Интересный девайс, но взглянув на картинку я был уверен что это раскладушка. А оказалось что нет. Ну и при такой толщине могли бы ради интереса разместить еще одну камеру на торце (рядом с ИК-светодиодом и лазером).
Я говорю Джава и Питон:)
Qiwi давно не пользуюсь, но на одном из кошельков есть 80 рублей - вчера попытался перевести их на телефон, уже не дает.
А вообще, пользуясь случаем, хочу предложить знающим людям написать статью на Хабр, на тему работы с криптой из РФ для чайников (или хотя-бы накидайте ссылок в комментарии). Вот как-то не интерсовался этим раньше, ну просто это не моё, мне интереснее статью о новом языке программирования почитать, чем углубляться в эту весьма специфическую сферу... но жизнь заставляет.
Кроссплатформа из Swift была бы супер! Сам язык очень интересный. Не такой мозгодробительный как C++ и Rust, но и не такой простой как С или Go. Компилируемый, со строгой статической типизацией, что безусловно плюс. Сбалансированный синтаксис и весьма богатые языковые возможности, при этом в нем еще не накопилось legacy как в C#.
Тогда надо делать полноценную нуллабельность (спецификатор типа "?" и соответствующие операторы). Но кажется уже поздно, в Go указатели нуллабельны, а другие типы - нет, и если делать то получится слегка кривовато как в C#.
Да, смартфоны все больше походят на фотики за счет торчащего "объектива". Тогда бы уж увеличили толщину всего смартфона в целом до толщины "объектива", и разместили в дополнительном объеме что-то полезное.
Что-то навороты какие-то, аж С++ повеяло:) При этом лично я никаких особых потребностей в итераторах и проблем с классическими циклами не испытываю. Ну подумаешь классический цикл с параметром. Зато просто и прозрачно.
Хотя последнее время погрузился в Go, и некоторых вещей действительно не хватает. Самое простое - это как ни странно тернарный оператор
c ? x1 : x2Приходится писать три отдельных строчки кода с объявлением переменной вместо того, чтобы написать нужный код прямо внутри другого выражения.Еще немного напрягает, что в "методах классов" нет неявного доступа к полям класса