Наверно, все хотя бы слышали о китайских флешках с прошитыми контроллерами, которые показывают бОльшую ёмкость, чем на самом деле. Всё бы ничего, да при попытке записи всего объёма либо выдаст сообщение о переполнении, либо затрёт старые данные. Понятно, что почитав отзывы, такой накопитель никто не купит.
Но я подумал - а что, если в флешку/жёсткий диск добавить процессор для сжатия информации? При записи данные будут сжиматься и умещаться на небольшой накопитель. А при чтении разжиматься и пользователю будет казаться, что у него просто большой винчестер.
Например, была такая штука, как модем со сжатием. Он позволял достичь скорости 320 кбит/с вместо 56 при dial-up подключении. Интересно, почему эту технологию похерили? Сжатие в пять раз! Подключаешь 100 мбит/с, а у тебя 500 по факту. Видно, провайдерам невыгодно.
Разные данные по разному сжимаются. Плейнтекст и всяческие веб запросы - сжимаются хорошо. Видео, музыка - в разы хуже. Всякие запароленные архивы с шифрованием - вообще никак. Сегодня и так все нормальные ссд контроллеры так делают чтобы писать на ссд меньше (стало быть сохранять ресурс), а вообще сжатие происходит на уровне файловой системы, но шинда со своей сраной ntfs сосет бибу, как всегда, но даже тут можно включить компрессию файлов.
А если специализированный проц для сжатия разработать? ASIC особый. Ты на своём корай7 хуй биток помайнишь, а на асике будет толк. Так же и обычный проц хуёво сжимает, а асик будет очень хорошо сжимать.
Наркоман, сжатием занимается файловая система, туда УЖЕ пишется все сжатым (ну если это настроено)
Да и уже не то время, чтобы было сложно купить диск с большим объёмом
Ты не понял, я не про сжатие в винде, а в самом жёстком. Типа ставишь пластины на 500 Гб, а определяется как 1 Тб из-за сжатия в два раза. И продаёшь дороже.
Мимо >>252940156
Так оно не сожмёт КАЖДЫЙ тип данных в 2 раза, это не так работает
> Так оно не сожмёт КАЖДЫЙ тип данных в 2 раза, это не так работает
А если для каждого типа свой алгоритм?
> скорости 320 кбит/с вместо 56 пр
> предлагает отскалировать до 100 мбит
Ты ебанутый? Тебе в модем придется квантовый компьютер поставить, чтобы столько сжимать-разжимать. Алсо, а где твои сжатые пакеты разжимаются, у провайдера?
Их же тысячи
Да и банально мп3 ты уже никак не сожмёшь, потому что он и так сжатый донельзя
Т.к. данные сжимаются по разному то писать 1тб нельзя, ведь хз что ты там будешь хранить - если книги, тогда и 5 тб можно написать, а фоточки с дачи - 400 гб потолок.
А вообще на LTO лентах так и пишут размер после сжатия, например, наебывая пользователей.
> И да, асик стоит дороже нового диска для файлопомойки в разы
Не скажи. У меня ноут hd фильмы медленно кодирует. В то время как телефон за 5к пишет fullhd в реалтайме. Потому что там специальный видеопроцессор. Стоит копейки, но мощный.
>добавить процессор для сжатия информации?
Ведь он будет дороже, чем настоящий винт на +500гб.
Этому ноуту 20 лет?
> > скорости 320 кбит/с вместо 56 пр
> > предлагает отскалировать до 100 мбит
> Ты ебанутый? Тебе в модем придется квантовый компьютер поставить, чтобы столько сжимать-разжимать.
Так со времён дайлапа мощность процев выросла в сотни раз.
> Алсо, а где твои сжатые пакеты разжимаются, у провайдера?
Вроде бы да. Вот и не хотят ставить оборудование на своей стороне.
>пакеты
Там везде шифрование, пакеты в голом виде никто уже не шлет практически
Просто видеокарта слабая. А так 5 лет.
Можно битрейт понизить. Почти вся музыка сейчас в 320 кбит, я пробовал 32 делать - разницы нет, даже стерео слышно.
А причём тут шифрование? Мы про сжатие, а не шифрование.
Это уже транскодирование, "разжать" такое не получится
Так-то оно да, но бля, вы слишком заморачиваетесь в 2021 году с этой компрессией. Как будто воду дома экономите
Тем более зачем хранить медиа локально? Есть же облако/яндекс музыка
В том что шифрованную кашу из данных хуй сожмешь, т.к. она часто упорядочена чуть менее чем никак.
Да, но пользователь нихуя не заметит если он не аудиофил ебанутый
> Тем более зачем хранить медиа локально? Есть же облако/яндекс музыка
FTP://oblako.fsb.ru
Трипл, наверно, правду говорит. А если процессор для сжатия очень мощный и заточенный под конкретный формат шифрования?
Очень многое зависит от профиля кодека, параметров кодирования и всего такого. Если проц не совсем дремучее говно, то у него есть аппаратный энкодер h264. В штеудах он с 6 поколения. Но чтобы он кодировал видео надо чтобы параметры кодирования были настроены под аппаратный энкодер, иначе кодирование идет в софтверном режиме, отчего и отсос в производительности. Мобила пишет видос со сторого определенными параметрами кодирования, если ты попытаешься писать видос с камеры софтом, который позволяет настраивать пресеты кодека, упаковку кадра, количество проходов итд, то телефон соснет. К тому же на вход энкодеру в мобиле приходит несжатый сырец. А пекарне его надо еще декодировать.
Давай определимся - нахуя?
Тогда можно и МАСПА навернуть заместо сливочного, разницы-то нет!
Вообще это отношения к сжатию не имеет особого, скорее твои личные предпочтения и жмотство за любой килобайт.
>>252940913
Современные процессоры неплохо с этим и так справляются, гугли файловые системы которые пользуют всякие гуглы и фейсбуки (zfs, gfs, hadoop и т.д.)
мп3 можно еще процентов на 10-15 пожать. Packmp3.
>заточенный под конкретный формат шифрования
Такое нельзя запилить. Потому что после любого шифрования получаются данные с высокой энтропией. Чем выше энтропия, тем хуевее сжатие. Любое сжатие после современных алгоритмов шифрования неэффективно.
Я так понял, что там типа при сжатии ищутся закономерности - длинные цепочки из одного символа, часто встречающиеся символы и т.д. А что если найти закономерности в шифрованном файле?
Ну потратишь уйму вычислительной мощности и времени чтобы сжать шифрованый файл на 0.01% окда.
А их там нет. Смысл шифрования как раз в том, чтобы в шифрованных данных не было закономерностей. Если там прослеживаются какие-либо закономерности, значит алгоритм шифрования - говно.
Так. А если поставить сжимающий чип перед шифрующим? Типа данные будут сначала сжиматься, потом шифроваться, потом записываться на диск/ идти в модем?
>сжимать перед компрессий
Ну, вообще так уже и делается везде где только можно, например в этих ваших интернетах. Правда наверное не супер-круто чтобы не вредить производительности.
А как думаешь, всякие йоба технологии типа ИИ и квантовых компов могут найти такие закономерности? Вот дай последовательность 1 4 9 16 25 человеку с образованием и подпивасу. Первый скажет, что это квадраты, второй, что просто какие-то числа. Можно ещё сложнее 1 1 2 3 5 8 13... Если мы не можем найти закономерность, это не значит, что её нет.
>>252942002
Промазал
Это уже частично реализовано. Например HTTP может сжиматься на серваке, а у тебя на пекарне разжиматься, и только потом рендериться в браузер. Понятное дело, что жмется не все подряд, потому что например жатие видосов еще раз смысла не имеет.
Если говорить про сжатие данных для хранения на дисках, тогда возникает проблема с доступностью. Несжатые данные ты можешь прочитать с любого места, а вот сжатые - хуй. Перед чтением, тебе нужно все распаковать. Даже если тебе нужен 1 байт из гигабайтного файла, придется распаковывать весь гигабайт.
Если жать блоками, то там тоже есть нюансы, да.
Нет, сколь-нибудь практически пригодные для сжатия закономерности не найдут даже ИИ и квантовые пекарни. Это же элементарная математика.
> Это же элементарная математика.
Нихуя себе элементарная математика. Читал как работает это шифрование современное, нихуя не понял. Сосед вообще препод и говорит, что тоже нихуя не понимает. Хотя по молодости программировал для банков шифрование.
Ну это уже какие-то странные фантазии пошли. Контракты тоже денег стоят и их нужно в отличие от уже распаянных на флешке чипов - продлевать. Плюс нужно питать ту же флешку пока она кидает файлы в облако. А еще и покрытия может и не быть.
А вообще опять же - идея не новая, правда сервер нужно самому поднимать.
Ну ты можешь посчитать уже сейчас без всяких ИИ энтропию файла. Там только логарифмы нужны вроде. Сравни один и тот же шифрованный файл и исходный файл. Например, у исходного файла энтропия буде 30%, а у шифрованного 99,95. Если охуенно сильно упрощать, то потанцевал сжатия исходного файла 70%, а шифрованного 0,05%. Вот эти 0,05% и будет пытаться пожать нейросеточка.
Лёха бабушкин, ты?
Не, Бабушкин пытался обратить хеш взад. Но, как известно, фарш невозможно прокрутить назад.
> Не, Бабушкин пытался обратить хеш взад. Но, как известно, фарш невозможно прокрутить назад.
Типа данные повреждаются? А если очень мощный комп (теоретический)?
Вот смотри, есть у меня файл с порнухой на гиг. Я считаю от него хэш и этот хэш занимает десятки байт. Потом начинаю перебирать все возможные файлы размером 1 гиг (да, их очень много, так что теоретически). Если хэш совпал, прога пытается запустить файл через плеер. Если плеер не выдал ошибку и воспроизвёл, ура, мы восстановили исходный файл.
Стоп, если у шифрованного файла сжимаемость 0.05%, это неплохо. Шифруем, сжимаем до 99.95%. Потом снова шифруем, снова сжимаем. И так до бесконечности. Или при шифровании размер файла увеличивается?
Вопрос не по теме треда, но близко. Почему похерили или не развили технологию WebDav? Можно было облака подключать как тупа внешний диск в проводнике, но ни гугл, ни яндекс, ни мейл, ни вандрайв в такое не могут(гугл и вандрайв могут с костылями). Могут только какие-то ноунеймы и то не факт. В чем их невыгода от того что я буду использовать сторонний софт, а не их приложения? Я понимаю что есть коммерчиские приколы, которые по сути выполняют эту функцию, типа Диск О: от мейла, но явно остальные с этого профита не получают.
Ну это и предлагал Бабушкин.
>начинаю перебирать все возможные файлы размером 1 гиг
А откуда ты знаешь, что он гиг занимал? Хеш не содержит такой инфы.
Ну и вообще, посчитай сложность и прикинь сам, справится ли с этим квантовый комп за приемлемое время.
>>252944422
Это значит что у него примерно такой потанцевал. Шифрование может немного увеличить файл до последнего длины блока. На практике у тебя уже через пару итераций файл будет немного больше, чем исходный.
Напиши сам, если API добудешь. Вот на андроиде файловый менеджер+ гугл и яндекс диск видит как флешку или папку.
Кто тебе его так просто даст, лол?
> контроллер идет по пизде
> все данные на диске одномоментно всё, SMART даже хрюкнуть не успел
Нужно общими усилиями развивать и продвигать общий API для файловых систем вместо того, чтобы городить свой закрытый велосипед. Например, нужно как-то запрещать установку игор на эти диски, индексацию, дрочение этого диска антивирусами етц. Ну его на хуй.
мимо-разработчик
> Ну это и предлагал Бабушкин.
> >начинаю перебирать все возможные файлы размером 1 гиг
> А откуда ты знаешь, что он гиг занимал? Хеш не содержит такой инфы.
> Ну и вообще, посчитай сложность и прикинь сам, справится ли с этим квантовый комп за приемлемое время.
Сохранять ещё и размер файла. Он мало занимает. Я говорю сугубо о теоретической возможности или технологии следующих тысячелетий.
>>252945127
А если js в браузерной версии поковырять?
Это почему еще данные всё?
Лол, кто и зачем станет туда игры ставить? Какой бы у тебя не был быстрый интернет, в любом случае выйдет неиграбильное говно. Да и я думаю в самих ОСях есть защита от всей этой хуйни из коробки. От держателей облак требуется только дать доступ.
А ну ваще вот.
https://yandex.ru/dev/disk/webdav/
https://github.com/Soladiem/GoogleDiskAPI
У мейла ничего не нашел.
Ты много думаешь, не понимая при этом сложности реального мира.
В подобных ситуациях сложно опираться на сторонние интерфейсы и протоколы, потому что в какой-то момент их начинает не хватать и нужно их изменять. Это нужны консорциумы, конференции, сотрудничество между крупными игроками етц.
Вместо того, чтобы сделать свой полностью контролируемый велосипед, который в любой момент можно наизнанку вывернуть, когда появится новое бизнес-требование. Свои велосипеды проще, дешевле и понятнее всегда для бизнеса, и никому на хуй не упало WebDAV для горстки энтузиастов поддерживать и тем более развивать.
Ну допустим. Я вообще это пишу, потому что вчера пытался это все подключить, в итоге нашел левый работающий с перебоями софт cloudmounter и смог приделать вандрайв и гугол.
В процессе несколько раз возникало горение жопы с того что ничего нормально не поддерживается, а если поддерживается нормально как в диск о: от мейла, то надо платить деньги.
>>252939617 (OP)
Сожми свое очко и перестань говно выливать в борду.
Нихуя не шаришь в ИТ - или учись или сожми очко.
Сжиматель хуев. Все уже сжато до тебя ещё в прошлом веке, а ты только проснулся и, расжав очко, высрал нам тут свое говно.
Сожми очко, ещё раз говорю!
Хорошо.
Держи Очко.zip
Я отвечаю на твой вопрос, почему именно вебдав не поддерживается и почему вообще все компании склонны делать свои велосипеды. Всегда в начале все садятся и начинают перебирать существующие технологии и альтернативы, потом одна за другой отметаются из-за каких-то недостатков, а самые продуманные штуки отметаются из-за самого главного недостатка -- NIH и на основе изученных технологий/протоколов велосипедится своя с блэкджеком и шлюхами. Вот WebDAV на HTTP, вроде, опирается, а в компания_нейм аналитики и разработчики захотели бинарный протокол. Всё, WebDAV уже не рассматривается дальше.
А можно написать виртуальную машину с браузером, где если хочешь воспользоваться файлом, прога будет его качать, имитируя нажатие мышкой, а потом переделывать с ЖД виртуальной машины на твой жд?
>для сжатия информации
Я даже название твоему стартапу придумал: "ПЕГИЙ ДУДОЧНИК" (c).
>Но я подумал - а что, если в флешку/жёсткий диск добавить процессор для сжатия информации?
Давно уже есть. Только минусов слишком много. Здесь и замедление работы, и трудности с восстановлением информации при отказе. Плюс многие файлы сжимаются хреново, так что выгода мизерная.
А если сжимать раз в 5?
Шиза какая-то, проще на линуксовом FUSE виртуальный драйвер для ФС сделать. Примерно так программы вроде >>252945968, разрабатываемые энтузиастами или мелкими подвальными разработчиками.
Примерно так и работают, в общем.