LINUX.ORG.RU

Вышел архиватор Rar 5.0 для Linux и FreeBSD с поддержкой нового одноимённого формата

 , ,


4

3

Из нововведений стоит отметить:

  • Увеличенный размер словаря вплоть до 1 ГБ.
  • Улучшенная, многопоточная распаковка.
  • Дата сохраняется во всемирном координированном времени (UTC), а не в локальном времени.
  • Кодировка UTF-8 по умолчанию для комментариев и имён файлов.
  • Новая схема коррекции ошибок на кодах Рида-Соломона, а также современный хеш BLAKE2sp длиной 256 бит позволят обнаруживать какие бы то ни было ошибки и восстанавливать даже сильно повреждённые архивы.
  • Алгоритм шифрования изменён с AES-128 на AES-256 в режиме CBC. Функция деривации ключа основана на PBKDF2 с использованием HMAC-SHA256 и другие улучшения безопасности.
  • Поддерживается определение символьных ссылок, жёстких ссылок и дубликатов файлов.
  • Понимание формата сжатия XZ и многое-многое другое.


>>> Подробности

anonymous

Проверено: Pinkbyte ()
Последнее исправление: unfo (всего исправлений: 2)
Ответ на: комментарий от hobbit

Пардон опечатался. Во втором предложении должно быть «форматы».

hobbit ★★★★★
()
Ответ на: печалька от anonymous

Не нужно сюда портировать проприентарную фигню. Исходники нужны для синергетического эффекта, когда не нужно каждую проблему с нуля решать.

Люди, которые пилят свободный андроид, получают в гугле вполне себе нормальную зп. Как, впрочем и те, кто пилят несвободные компоненты для этого же андроида. И вряд ли их зарплата вообще зависит от открытости исходников.

ForwardToMars
()
Ответ на: комментарий от zgen

Ладно, изучай дальше как через cmd.exe сдампить и смержить два коцанных файла, вендузятнег.

steemandlinux ★★★★★
()

ждем ебилдов

PS Тред не читал..

Jam_666
()
Ответ на: комментарий от ForwardToMars

Не нужно сюда портировать проприентарную фигню. Исходники нужны для синергетического эффекта, когда не нужно каждую проблему с нуля решать.

Дык беда-то какая, не может всё сообщество изготовить гуёвый архиватор с таким же набором кнопочек, не получается у него пока синергетического эффекта в данной области.

Люди, которые пилят свободный андроид, получают в гугле вполне себе нормальную зп. Как, впрочем и те, кто пилят несвободные компоненты для этого же андроида.

К десктопному линуксу это имеет не очень большое отношение.

Napilnik ★★★★★
()
Ответ на: комментарий от emulek

«потому-что сжатие после архивации — часто используемая дополнительная фича. потому-что сжатие ПОСЛЕ архивации ты вовсе не обязан делать»

Плюрализм в одной голове. Как обычно.

Oleaster ★★★
()
Ответ на: комментарий от anonymous

Во-первых, в худшем случае 6 страниц. Во-вторых, «Евгений разрабатывает продукт» не для сотни лоровских болтунов, у половины из которых и линукса-то нет, а для пользователей, коих более 30 млн.

Oleaster ★★★
()
Ответ на: комментарий от galanthus

И всё это дерьмо нефункциональное, кривое, прибитое гвоздями к оболочкам и плохо поддерживаемое.

Oleaster ★★★
()
Ответ на: комментарий от question4

Думаю, это можно обойти, если кто-то опишет алгоритмы глядя на исходники. Но я не юрист

Там всё старо как мир: LZ77+Huffman+фильтры для типов данных. Весь rar лишь в особенностях конкретной реализации. Т.е. воссоздавать конкретно rar нет никакого смысла, т.к. тот же LZMA (LZ77+RС) куда эффективнее by design. Rar интересен/полезен исключительно как комбайн, чем и заслужил признание пользователей

frame ★★★
()
Ответ на: комментарий от anonymous

Да нехай зарабатывает, его право. Только вот надо пожелать ему многия лета. Потому как, не ровён час, помрёт, а в программе найдётся Страшная Уязвимость, да и просто в венде апи чуть поломают — и всё, аллес капут. GPL в этом отношении понадёжней будет.

Oleaster ★★★
()
Ответ на: комментарий от question4

Пожалуй, для этого нужен математик уровня Рошала или Павлова, а им уже есть чем заняться.

Oleaster ★★★
()
Ответ на: комментарий от frame

Смысл в том, что уже есть наработанная пользовательская база и миллиарды файлов. Поэтому, имея точный алгоритм, сделать ещё один такой же комбайн было бы заманчиво. Но я думаю, что действительно лучше сосредоточиться на LZMA и 7zip.

Oleaster ★★★
()
Ответ на: комментарий от frame

Там всё старо как мир: LZ77+Huffman+фильтры для типов данных.

С ZIP не путаешь? RAR использует арифметическое сжатие. Да, один из его предельных случаев — алгоритм Хаффмана, но на разные варианты арифметического сжатия выдана куча патентов.

question4 ★★★★★
()
Ответ на: комментарий от Napilnik

Синергетический эффект от исходников - он долгий. 15 лет назад про ядро так же говорили, как сейчас про гуевые архиваторы, а 10 лет назад - про веб-серверы. То, что занято опенсорсом, проприентарщиной обратно занять крайне трудно - слишком высокий порог входа. Но и обратное верно - опенсорс занимает ниши очень медленно.

К десктопному линуксу это имеет не очень большое отношение.

И что? Речь о том, что чел не знает, как денег заработать на опенсорсе, поэтому зарабатывает +15% на shareware (видимо).

ForwardToMars
()
Ответ на: комментарий от Oleaster

Даже на не столь экзотических случаях Nero оказывается надёжнее. У меня были случаи, когда k3b глючил, а Nero просто работал.

Например, довольно-таки типовая ситуация: отмечаешь в k3b, что записанный диск необходимо проверить, запись происходит нормально, диск выезжает... и обратно не втягивается. Всё, завершить запись после этого невозможно, можно только прервать. Не смертельно (в конце концов, проверить запись можно и другими средствами).

Гораздо хуже была эпическая история, которая произошла со мной ещё на генте. Там, кстати, как раз про unix-way vs комбайны...

hobbit ★★★★★
()
Ответ на: комментарий от emulek

Опять рассуждаешь о том о чём понятия не имеешь. Или просто жирный тролль. В любом случае бан по тебе плачет.

anonymous
()
Ответ на: комментарий от Napilnik

xml говно приближающее энергетический кризис на планете.

Эт ты о том, что ресурсов черезмерно уйдет?

А потом раздадутся вопли: на бюджетном ПК с 32 гектарами оперативы и 12 ядерным процом не хватает ресурсов для плавной прокрутки и поиска в 2 Гб xml документе.

От меня же и раздадутся :) 2 гб офисный документ? ССЗБ-шность 3й степени

pihter ★★★★★
()
Ответ на: комментарий от TEX

У тебя аргументы почему программа должна выполнять ОДНУ и ТОЛЬКО ОДНУ задачу есть ?

У меня есть. Такой подход (и текстовый интерфейс) позволяют комбинировать разные программы в той степени, в которой это нужно администратору. И не только архиватор с компрессором, а вообще что угодно с чем угодно. Это основа основ юникса и большинства систем, которые из него выросли. Именно поэтому cp умеет только копировать файл, даже перемещать не умеет, хотя, казалось бы, ооооооочень смежные задачи.

pihter ★★★★★
()
Ответ на: комментарий от TEX

ОФигенно ... вот оно чо. facepalm.jpg.

Да да. Именно системная. К ней можно прикрутить красивый интерфейс для человеков, но такого толка утилита должна оставаться системной.

Следи за руками: бэкенд - системная утилита, фронтенд - гуй. При том, естственно, бэкенд должен быть вполне функционален и без фронтенда в данном случае.

Нужно поинтересоваться у Рошала, много они с братом на своей системной утилите наваривают, поди дешевять, по цене прикладного софта продают

Неприятный саркастический тон создаешь, ты что в этом споре, корову проигрываешь? Сарказм можно - но добрый и веселый, какая тебе радость от негатива - в упор не пойму.

Конкретно сабж, не смотря на то, что продается как прикладная программа, обладает богатым системным функционалом, отлично скриптуется. С чего бы, если архиватор - не системная программа? Просто в то время на оффтопике все такое было - не рыба не мясо. Молодо-зелено

pihter ★★★★★
()
Ответ на: комментарий от anonymous

Как там ваш системд поживает ?

Это в каком месте он наш? init отлично поживает, есть мнение, нас с тобой переживет

А иксы ?

А иксы чем не угодили? Может и не идеально, но, имхо, вполне в духе веяний юникса. (сразу скажу - я толком не в курсе как он технически устроен, так, по ЛОРу...)

Может этот ваш унипс-вэй и работал когда надо было перегонять текстовые файлики по конвееру но не сейчас...

Как поживается без GNU Utils? Как только мир СПО откажется от идеалов юникса - он скатится в сраную винду (кто сказал систем дэ?)

Юникс вей - универсален. Чем текстовые интерфейсы сейчас плохи? Чем утилиты (отлаженные десятилетиями уже) сейчас плохи? До только лучше стало все для юникс вея

pihter ★★★★★
()
Ответ на: комментарий от emulek

Ну и да, сжатие — это вовсе не отдельная задача, а распространённая фича.

Ай.. до этого момента все верно говорил. :) ну как отдельная задача имеет право на жизнь, не?

pihter ★★★★★
()
Ответ на: комментарий от Oleaster

С тех пор, как Рошал обнаружил, что архиватор может выглядеть красиво — он стал программой для людей.

Ну максимум для людей компьютерно-грамотных, но не для бухгалтерш. Для людей - браузер, плеер и тд

Нечего людям в такие дебри залазить. Это для них сложно сильно. Вот управлять государством - это просто, это знаний не требует, меня тут давеча спрашивали как, а архиватор - сильно сложно для людей

хехехе

pihter ★★★★★
()
Ответ на: комментарий от TEX

Дальше расскажи зачем нужны эти опции именно в tar, если он мало того что нарушает прицип ОДНОЙ ЗАДАЧИ,

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

так еще и свою основную задачу по добавлению файлав в архив вкупе с эти опциями выполняет ХРЕНОВО, а вовсе не ХОРОШО ?

потому что опцию сжатия решили выкинуть и не выкинули только чтоб не ломать совместимость, потому и смысла допиливать фичу компрессии нет: компрессию решили пилить отдельно ибо, повторяю, появилась потребность использовать ее отдельно от архиватора (поэтому лепить ее в архиватор не правильно: а что если я хочу использовать компрессию без архиватора?)

Так почему же даже такая вещь, как tar включенный в posix, так легко и просто нарушает принципы unix-way ?

Не нарушает. Тар - архиватор (с хреновым подобием компрессора) но, как архиватор - не нарушает. вот тебе пример того что получится если лепить комбайн - комбайн будет уступать по гибкости и фичастости союзу двух этих сущностей отдельно

Или не так с людьми что возводят принципы в абсолют и в упор не хотят видеть что оно нарушается сплошь и рядом

Мы возводим в абсолют только в идеальном мире, как цель, как стремление. К правовому государству тоже стремиться не нужно? Ведь принципы не убий и не укради

нарушается сплошь и рядом

По твоей логике, раз нарушаются - значит и стремиться в идеальный мир, где нарушаться не будут, не нужно?

pihter ★★★★★
()
Ответ на: комментарий от TEX

LOL што ? Пряма таки «невозможно» ? Рошал тебе по рукам линейкой лупит, когда ты его архив в pgp заворачиваешь ? Бывает чо

А чой-та ты конвейерные принципы применяешь? Разве хорошая программа не должна сама хорошо шифровать? оО

Или все-таки шифровалка - шифровать, компрессор - сжимать, а архиватор - управлять архивами?

pihter ★★★★★
()
Ответ на: комментарий от anonymous

Всем ноющим по поводу ZIP — сам формат поддерживает он и большие файлы (добавлено в спецификацию в 2005-м году), и юникод (2006–2007 годы), проблемы есть только с поддержкой со стороны архиваторов.

Тада беру свои слова обратно :) зипу - быть (но он все равно не совсем юниксвейный :Р )

pihter ★★★★★
()
Ответ на: комментарий от Deleted

Очень пухлые получаются. Толку от такой текстовости, если вручную ты всё равно JPEG редактировать в блокноте не будешь :)

Признаю, перегнул с разгону :)

Правильнее всего, имхо, бала бы совокупность файлов, слепленые таром. А компрессор - опционально.

Хотя может я и не прав: я тут совсем не специалист :)

pihter ★★★★★
()
Ответ на: комментарий от anonymous

Вот жеж подлец! Деньги зарабатывает. За свой труд. Нет бы, как приличному человеку, отдать сорцы сообществу. Улучшили бы, оптимизировали, баги пофиксили.

Хоть раз тут про него такое сказали? Вы пытаетесь выставить нас неадекватами, показывая свою неосведомленность о наших настроениях? Толсто и грубо, мы - совсем не такие, мы - нашки :)

Автора сабжа тут уважают и никто его к GPL и BSD не принуждает, напротив, все рады что под онтопик тоже есть версия: приятно что о нас помнят.

Под какой лицензией выпускать код - дело автора, мы ему не учителя, спроси тут любого. СПО - дело добровольное

pihter ★★★★★
()
Ответ на: комментарий от pihter

а тар? :)

А он тут при чем?

Если о совместимости версий, то GNU tar, насколько я знаю — самый навороченный, понимает все старые варианты, описанные POSIX, и еще что-то сверх того. Подробно не выяснял.

question4 ★★★★★
()
Ответ на: комментарий от Napilnik

путаешь назначение встречи в реале с виртуалом

И в чем разница, если во встрече принимают участие люди из разных часовых поясов? В любом случае подразумевается привязка к одному универсальному времени. «Сбор в десять вечера. Специально для москвичей: в 19:00, если всё ещё хотите присоединиться» — вполне из жизни пример.

Не один ты считаешь себя пупом земли и не хочешь «скрипеть мозгами и вычислять сдвиг». Поэтому в любом нормальном форумном движке при регистрации или в профиле можно указать часовой пояс, многие определяют этот сдвиг автоматически. Тебе показывают московское время не потому, что так принято, а чтобы не напрягался. Человек из Челябинска или Анадыря тоже обычно видит своё локальное время.

…какое мне дело до интересов неандертальцев…
…мну их шевеления сугубо до лампочки…

Просто пойми или прими как данность: неандерталец в меньшинстве — это ты. Во всех UNIX системах часы идут в UTC, эталонные источники времени идут в UTC, часы синхронизируются в UTC, все совместные работы между учеными и инженерами разных стран идут в UTC, бизнес использует UTC. Локальное или местечковое время используется только при локальных контактах.

baka-kun ★★★★★
()
Последнее исправление: baka-kun (всего исправлений: 1)
Ответ на: комментарий от xsektorx

нельзя к гпл применить дополнительные условия. к бзд можно, применяя дополнительные условия можно из бзд сделать гпл

Т.е. берем BSDL, снизу дописываем GPL и требуем соблюдения GPL? Ладно, берем GPL, снизу дописываем BSDL и брюки превращаются... превращаются брюки... точно! В BSDL!

GateKeeper ★★
()
Ответ на: комментарий от baka-kun

У нас на серверах временная зона стоит в UTC. Тот кто не понимает необходимости UTC - житель дерени никогда из нее не вибирающийся

vromanov ★★★
()
Ответ на: комментарий от pihter

А чой-та ты конвейерные принципы применяешь?

А что прости такого ? Ты где то увидел что я писал что они не нужны ?

Разве хорошая программа не должна сама хорошо шифровать?

Она шифрует

Или все-таки шифровалка - шифровать, компрессор - сжимать, а архиватор - управлять архивами?

Еще раз спрашиваю что делает в tar опции по управлению фильтрами сжатия ?

TEX ★★★
()
Ответ на: комментарий от pihter

Мир не идеален, тар - тоже :)

просто во время его разработки еще не было очевидно то, что компрессию следует выводить в отдельную юникс-сущность,

Пруф ?

поэтому в то время решили запилить как фичу архиватора,

Твою ж налево, это «фича» архиватора вызывает внешнюю программу фильтр. Тупо что бы ты не писал конвеер. Надеюсь ты не будешь бредить что когда рождался unix и соотвественно tar конвееров еще не было - их мол придумали потом ?

, а потом решили выносить в отдельную сущность (оказалось что сжимать нужно не только архивы)

Пруф ?

потому что опцию сжатия решили выкинуть и не выкинули только чтоб не ломать совместимость,

Как думаешь - что важнее - абстрактный unix-way или таки совместимость ?

Не нарушает.

Нарушает - программа своими опциями создает архив с которым потом сама же и не может выполнять свои основные функции. Вот если бы пользователь самостоятельно сжал архив - тогда вопросов не было.

Мы возводим в абсолют только в идеальном мире, как цель, как стремление.

Идеальный мир это глупость. Стремление приблизиться к идеалу - глупость. Реальные и работающие решения - это всегда компромисс.

По твоей логике, раз нарушаются - значит и стремиться в идеальный мир, где нарушаться не будут, не нужно?

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

TEX ★★★
()
Ответ на: комментарий от pihter

Да да. Именно системная.

Определение системной утилиты в студию.

Следи за руками: бэкенд - системная утилита, фронтенд - гуй.

То есть по твоему всё что бэкэнд - системная утилита да ? Скажи когда я на сервере для преобразования отчета из txt в rtf/odf/xlsx, ну скажем вызываю опенофис или excel, он срочно становиться системной утилитой ?

При том, естственно, бэкенд должен быть вполне функционален и без фронтенда в данном случае.

Надеюсь ты не будешь отрицать что в этом случае у бэкенда может быть свой личный и вполне прикладной интерфейс ?

С чего бы, если архиватор - не системная программа?

Еще раз - определение системной программы в студию.

TEX ★★★
()
Ответ на: комментарий от emulek

потому-что сжатие после архивации — часто используемая дополнительная фича.

Дополнительная говоришь ? Будь добр поясни в каком месте фразы «программа должна делать ЛОГИЧЕСКИ ОДНУ ВЕЩЬ и делать ХОРОШО» ты видишь дополнительные вещи ?

Дополнительная фича уже нарушение unix-way, особенно когда эта фича один фиг реализуется через внешние программы

а зачем мне оборачивать няшный рар в gpg, если в этом вашем раре есть своё шифрование?

Что бы потом не бредить про «невозможно» - горе ты логик. facepalm.png

TEX ★★★
()
Ответ на: комментарий от question4

А он тут при чем?

Там не при чем, я для интересу спросил :)

Если о совместимости версий

Да, об этом. Спасибо

pihter ★★★★★
()
Ответ на: комментарий от TEX

А что прости такого ? Ты где то увидел что я писал что они не нужны ?

БЛДЖАД, ты мне с пеной у рта доказываешь что все необходимые для работы функции должны быть в одной программе (в архиваторе компрессор, шифровальшик и все другое, что может пригодится) а я тебе доказываю что лучше (в конечном итоге) если все эти сущности разносить по отдельным программам. Так?

И тут же говоришь что ничего не имеешь против конвейера. Дак что-таки правильно: конвейер или комбайн а ля сабж? Мы тебе тут хором доказываем что встраивать шифровалку в архиватор - глупо потому что можно написать отдельную шифровалку, это удобно на тот случай если мне понадобится архиватор без шифровалки и на тот, если мне потребуется шифровалка без архиватора. Кроме того, сравнивать по проф показателям отдельную шифровалку и шифровалки, встроенные в архиваторы - даже не смешно - получается что шифровалки в архиваторах убогие, по сравнению с внешними аналогами и получается так именно из-за нарушения юникс вэя (автор архиватора просто отводит шифровалку на второй план, ведь он архиватор пишит, а не шифровалку).

Она шифрует

Убого же. И причины этого - отход от принципов юникса.

Еще раз спрашиваю что делает в tar опции по управлению фильтрами сжатия ?

Я предполагаю (сразу говорю: точно я не знаю) что во времена разработки тара еще не было необходимости делить компрессор и архиватор, она назрела потом, но убирать не стали, совместимости ради

pihter ★★★★★
()
Ответ на: комментарий от pihter

Такой подход (и текстовый интерфейс) позволяют комбинировать разные программы в той степени, в которой это нужно администратору.

То есть если программа, внезапно, будет делать не ОДНУ а ДВЕ или БОЛЕЕ вещи, то её уже не получиться скомбинировать да ?

Это основа основ юникса и большинства систем, которые из него выросли.

Это не основа, это философия. Не путай тёплое с мягким. Философия даже не RFC, и уж тем более не ISO. Один emacs чего стоит.

Именно поэтому cp умеет только копировать файл, даже перемещать не умеет, хотя, казалось бы, ооооооочень смежные задачи.

Бугога - cp умеет делать резервные копии файлов, это как раз функция переименования файл - то задача mv

$ touch cp1.txt && touch cp2.txt && ls -i cp*
273218 cp1.txt  273219 cp2.txt

$ cp -b cp1.txt cp2.txt && ls -i cp*
273218 cp1.txt  273220 cp2.txt  273219 cp2.txt~

А еще она умеет не просто копировать файлы, а удалять существующие файлы, в которые происходит копирование - хотя есть команда rm

А еще умеет рекурсивно копировать директории зачем то - хотя согласно unix-way пользователь должен был составить конвеер из find и cp

TEX ★★★
()
Ответ на: комментарий от Napilnik

Если в атрибутах файла есть только информация о времени в UTC то теряется.

дык и хорошо. Зачем тебе знать, где я нахожусь? ВРЕМЯ ты узнаешь, что тебе ещё надо-то от временного штампа?

emulek
()
Ответ на: комментарий от pihter

БЛДЖАД, ты мне с пеной у рта доказываешь что все необходимые для работы функции должны быть в одной программе

Правда что ли ? Не будешь ли столь любезен указать где именно я тебе такое доказывают ?

И тут же говоришь что ничего не имеешь против конвейера.

Если у тебя в голове слышны голоса, то я то тут причем ?

Я предполагаю (сразу говорю: точно я не знаю) что во времена разработки тара еще не было необходимости делить компрессор и архиватор

Пруф в студию, пруф того что tar умел сжимать свои архивы, то есть что не разделял архив и компрессор.

Хотя уже сейчас я могу сказать что скорее всего ты этот пруф найти не сможешь - ибо запись сжатого архива на ленту это полный фейл с точки зрения доступа

TEX ★★★
()
Ответ на: комментарий от pihter

Убого же. И причины этого - отход от принципов юникса.

Тебе кто то запрещает шифровать не убого ? Расскажи как и кто ?

TEX ★★★
()
Ответ на: комментарий от TEX

просто во время его разработки еще не было очевидно то, что >>компрессию следует выводить в отдельную юникс-сущность,

Пруф ?

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

Их никто не позиционирует как жесткие законы. Это лишь - набор идей, принципов.

Как думаешь - что важнее - абстрактный unix-way или таки совместимость ?

Если выбор стоит прямо сейчас - совместимость, если есть возможность спроектировать по юникс вею - в долгосрочной перспективе, таки юникс вей

Нарушает - программа своими опциями создает архив с которым потом сама же и не может выполнять свои основные функции. Вот если бы пользователь самостоятельно сжал архив - тогда вопросов не было.

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

Вот если бы пользователь самостоятельно сжал архив - тогда вопросов не было.

Самостоятельно, указав ключ. Решение принял пользователь.

Идеальный мир это глупость. Стремление приблизиться к идеалу - глупость.

Еще раз - стремление к правовому государству, где соблюдаются все законы и все права всех людей - это глупость? Все же понимают что такого не будет никогда, дак что и идти теперь в эту сторону глупо?

Реальные и работающие решения - это всегда компромисс.

С этим не спорю. Но вектор развития мы ведь можем менять? Это не нереально? Направить его в сторону идеального мира == работать в конструктивном направлении, а не в деструктивном, нет?

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

Просто для иллюстрации глупости твоего заявления:

Вот я выдвигаю два принципа:

- нельзя воровать - нельзя убивать людей

и предлагаю, значит, развивать законодательную базу с опорой на эти принципы. Тут влетает ТЕХ и громогласно заявляет:

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

а на мой недоуменный взгляд (мол воруют и убивают же постоянно), заявляет:

пора уже взрослеть.

pihter ★★★★★
()
Ответ на: комментарий от Napilnik

Пролетая на самолёте над часовыми поясами наручные часы/мобила постоянно будут передавать приветы то из прошлого то из будущего но это никого не трогает. Точно так будет и с файлом.

ты бредишь. Никакого прошлого/будущего не будет. Как можно быть таким упоротым?

Повторяю ещё раз:

1. я создаю файл в 20:00 по своим часам, и отправляю файл тебе

2. ты принимаешь файл в 20:10 по моим часам, и в 15:10 по твоим часам.

3. дата создания файла у меня 20:00

4. дата создания файла(моего!) у тебя 15:00

5. и я и ты видим, что файл был создан 10 минут назад.

где ты видишь «файлы из будущего»???

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.