Как стать автором
Обновить
14
0
Дмитрий Павличенко @godlin

Пользователь

Отправить сообщение
Лично я использовал для распорки прозрачную картинку — браузеры сами сохраняют её пропорции при указании, например, только ширины.
Почему-то прочитал первый диалог голосами пингвинов из Мадагаскара xD
Обязательно разрекламирую ваш пост в подвластных мне соцгруппах! Такие дела надо поддерживать! :)
Ну, если так рассуждать, то аглифай и минифай делается уже после того, как весь код написан и отлажен, потому что отлаживать минифай — это то еще удовольствие. Поэтому иметь возможность отлаживать сразу исходники, а не скомпилированный код — это всё таки большой плюс.
Во-первых, есть подозрение, что если всё будет совсем плохо, то бюрократическому аппарату придётся поумерить требования.
Во-вторых, эти процедуры надо начинать делать уже сейчас, а не ждать пандемии. В общем, в большую вероятность (зомби-)апокалипсиса я не верю.
В-третьих, а нам и не надо все триста антибиотика сразу, нам надо сначала создать один работающий, а через некоторое время — другой, потом — третий и так далее.
В-четвертых, я читал об исследованиях (пруфы сейчас не смогу найти, извините), намекающие, что можно сделать цепочку (точнее, кольцо) противомикробных препаратов, такое, что для адаптации к препарату номер N в цепочке, бактерия вынуждена пожертвовать адаптацией к препарату номер N-M, т.е. через некоторое количество поколений, когда бактерия адаптируется к более поздним препаратам, она гарантированно потеряет резистентность к более ранним — и тогда можно вновь их использовать. И так по кругу.
Допустим… И какой Вы из этого хотите вывод сделать?
Никто и не говорит, что работа учёных — это легко и просто. Я, конечно же, сильно упростил, но, согласитесь, 300 модификаций за вполне разумные сроки — это вам не балалайкой по ведру. :) А теперь примите во внимание медленное, но верное развитие квантовых компьютеров, которые скоро будут такие расчёты щелкать как семечки просто.
nplus1.ru/news/2017/09/15/quantum-computer-simulation

Или Вы скептически к таким перспективам относитесь?
Я какое-то читал об исследовании, в котором антибиотики генерили как конструктор практически:
riaami.ru/2016/05/27740

Думаю, генная инженерия решит проблему нехватки антибиотиков в ближайшие 10-20 лет.
Да, есть тысячи способов это сделать. Речь о том, чтобы это можно было сделать на уровне ФС. Но вообще, это просто первый пример, который пришел в голову. Возможно, он не очень удачный)
Это ничем не будет отличаться от того, что есть сейчас — и, как следствие, не будет униформности.


Униформность — это вопрос стандартов/спецификаций. Так же, как есть спецификация структуры jpg или png, и вообще любого файла, с которым вы работаете, кроме, может быть, чистых текстовых файлов. Ну, или я не понимаю, что Вы пытаетесь сказать.

Так может надо сначала посмотреть, чтобы понять, осмысленно ли это предлагать?

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

Между «у нас между объектами циклическая ссылка, их можно удалить» и «у нас между объектами циклическая ссылка, их надо вернуть… гм, как?» есть фундаментальная разница.


И в чем же эта фундаментальность, простите?

А у меня все десктопы (рабочие станции, ноутбук) включаются только тогда, когда мне от них что-то надо — например, поработать. Для постоянной работы есть сервер.


Ну, видите, у всех по-разному. А Вы, когда работаете, прям нагружаете свой компьютер по полной, гоняете все время бэнчмарки, игры и майните биткоин? Или, скажем, есть время, когда Вы просто сидите стрОчите комментарии в Хабр, а компьютер в это время по большей части отдыхает? ;)

Вот только не «удобства», а «экономии места». И диски сейчас дешевле, чем мое время, поэтому спасибо, нет.


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

поэтому спасибо, нет.

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


Вы это информацией пользуетесь, значит это и ваша информация тоже.
Опять же, никто не мешает вам точно так же работать со своими форматами, а в системной базе хранить только базовые атрибуты. Т.е. никто ж не мешает хранить произвольные данные в блоке данных. У вас просто появляется возможность хранить части файла сразу в виде разных полей объекта базы данных, а не хотите — можете всё единым бинарным блоком засунуть в единственное кастомное поле, и тогда это будет практически ничем не отличаться от обычного файла.

Ну так это и плохо: я как программист теряю контроль за тем, что меня волнует (а меня волнует эффективность хранения «объектов» — это если у меня вообще объекты).


См. предыдущий пункт. Программист волен выбрать, что ему важнее. Эффективность сжатия данных? Храни блобы. Удобство доступа? Храни объекты. В чем проблема-то? Мы не теряем то, что имели, а только добавляем новые возможности.

Вот на месте «ту, которую захочет программист» и проблема.

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

В реляционных не решаются. В объектных и графовых — возможно, но сколько это стоит?

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

В сборщиках мусора немного другие задачи решаются.

В сборщиках мусора в том числе решаются проблемы циклических ссылок.

«То густо, то выключено», вы хотели сказать?


Не знаю, как у вас, но лично у меня компьютер выключается максимум раз в два-три месяца, когда я больше, чем на день, куда-то уезжаю :)

Это типичный copy-on-write, давно реализованный. Просто дорого.

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

Один формат сериализации to rule them all? Спасибо, нет.


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

Циклические ссылки в масштабе все системы?


В базах данных эти вещи решаются. А в сборщиках мусора вообще в реальном времени решаются. И живут как-то)

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


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

Не понял, при чем тут «ярлык» вообще. Высылаться должны данные, а ссылки живут только в рамках передаваемого или хранимого блока. Т.е. просто необходимо подобные связные файлы передавать единым блоком данных, а не разрозненными частями. Т.е. такие ссылки имеют смысл только в рамках БД или пересылаемого дампа.
Я так понимаю, автор видит идеальность в максимальном упрощении протоколов взаимодействия приложений между собой и с ОС, а так же в реализации в рамках ОС большого количества универсальных модулей, предназначенных для решения стандартных задач пользователя. И третья идея в том, чтобы приложения тоже были более модульными и более зависимыми от ОС. В принципе, в этом есть рациональное зерно.

И мне, кстати, кажется, что база данных, встроенная прямо в ОС — это очень крутая тема.

Я даже больше скажу: у меня есть предположение, что хранение данных в виде файлов, возможно, — не лучшая парадигма. И хранение данных в виде нереляционной БД было бы куда как интереснее и удобнее.

Ведь что такое обычный файл? Это имя-размер-несколько простых атрибутов и всё. Чтобы корректно прочитать данные из файла, вам надо сначала разобраться (или знать заранее), а что, собсно, за данные в нём находятся, потом, зная его структуру, распарсить, выделить необходимые данные и т.д.

А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования. Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.

Допустим, есть у меня сайт с большим количеством статических html-страниц, у которых у всех одинаковые шапки и подвалы. В обычном режиме я просто буду хранить в каждом файле свои копии шапок и подвалов, но имея под рукой вышеописанную систему, я мог бы выделить их в два отдельных файла и подключить к другим файлам через ссылки. А затем я мог бы и эти html-страницы отдавать не собранными, а прямо в виде подграфа объектов, выдранного из БД, и браузер бы уже сам собирал эти страницы.

Конечно, здесь у нас вылазят сразу все проблемы, связанные с синхронностью, дэдлоками и общим усложнением системы хранения, но это же решаемые вещи — все базы данных так или иначе их решают.
Так же, как и Черниговская, кстати.
Это уже нюансы, конечно. Человеку надо было попроще объяснить — я объяснил :)
Но в любом случае спасибо за замечание.
Если речь о градациях серого, то суммируем три компоненты цвета точки и делим на три: M= R+G+B/3, затем выставляем все три компонента в M: R=M; G=M; B=M

Если говорить о чисто чёрно-белом изображении, то можно так: вычислить M, как в предыдущем варианте, затем, если М больше некоего порогового значения (например, 0.5), то делаем точку белой, иначе — чёрной. Пороговое значение можно варьировать, получая разные результаты.
Что-то я перечитывал-перечитывал, но так и не понял, откуда взялось "(100/3)%"…
«x стало в три раза больше» означает «x*3», почему Вы делите-то? О_о
Кстати, Чурюмова-Герасименко — тоже, если приглядеться, двусоставная…
В Джимме я познакомился со своей женой ^_^
Ностальжи…

Информация

В рейтинге
Не участвует
Откуда
Ярославская обл., Россия
Зарегистрирован
Активность