Можно было, но у SCTP+UDP были некоторые недостатки, которые в том числе хотелось решить. QUIC быстрее устанавливает защищённое соединение, и он умеет в миграцию соединения если клиент перемещается из сети в сеть (был на мобильном интернете, стал через Wi-Fi и т.д.), наверняка и какие-то другие преимущества есть. Вы посмотрите сколько реализаций QUIC в разработке. Протокол интересен далеко не только одной Google. Это совместное усилие, потому что преимущества того что предложил Google 8 лет назад были очевидны всем, поэтому идею и подхватили и начали развивать вместе. И это прекрасно, так как это как бы повышает шансы, что стандарт пишется не в стол, а будет на самом деле применяться.
Синдром NIH — это когда какая-нибудь Apple делает свой изначально проприетарный ALAC, который совершенно непонятно зачем вообще создавался, потому что он буквально во всём хуже FLAC, который был создан раньше и был изначально свободным.
А если есть возможность предложить что-то лучшее, чем уже существует, то это уже не NIH, а развитие технологий. Если при этом компания кооперируется с другими заинтересованными сторонами для того, чтобы получить ещё более продуманный стандарт — это ещё лучше.
Ссылки тоже проверил. Не сохраняются. Но непонятно как их сохранять, если они куда-то за пределы архива указывают. Только если все ссылки на какие-то файлы внутри архива, тогда понятно. Думаю, наверняка можно добавить такое расширение.
Разработкой QUIC занимается целый ряд заинтересованных организаций под флагом IETF. Google только предложил первую версию в 2013 году. С тех пор разрабатывается всеми заинтересованными компаниями, и сильно отличается от того, что предлагал Google. И нет, у Google там не большинство голосов. Только 8 лет спустя все пришли к какому-то консенсусу и основная часть стандарта уже почти закончена (но продолжается работа по расширениям типа пересылки UDP-подобных пакетов через QUIC-соедиение).
Визуально кажется что уровней столько же, но UDP там используется только для совместимости с существующими сетями, потому что только так сегодня можно добавить новый протокол транспортного уровня без замены всего железа по всему миру (что близко к невозможному). То есть его роль только в совместимости с существующими сетями. Сам по себе QUIC несёт себе функции TCP, UDP, TLS и мультиплексирования нескольких потоков через одно соединение (что ранее было частью HTTP/2), с кучей новых классных возможностей. То есть раньше часть задач транспортного уровня был вынужден брать на себя HTTP/2 (мультиплексирование нескольких потоков), что было не очень логично, и оно работало плохо из-за всей этой матрёшки (потеряли один пакет одного потока — застряли сразу все потоки), сейчас это ушло куда и положено, на новый транспортный протокол в лице QUIC (который ещё и заменяет TLS, так как только при такой интеграции можно избавиться от недостатков старой связки TCP+TLS+мультиплексор потоков).
Проблемы с битыми архивами остались где-то в 90-х и нулевых, вместе с дискетами и оптическими дисками. То есть то что вы описываете к 2021 году лишь стало менее актуальным. А вот полноценный бэкап не утратил актуальность: риск полного отказа HDD или SSD хоть и мал, но всегда есть. Но это делается другими средствами.
Соглашусь, что как опция такая функция не помешала бы. Но на мой взгляд свободность 7-zip перевешивает это преимущество RAR.
Часто инсталляторы состоят из кучи файлов. Даже если инсталлятор одним файлом, к нему иногда хочется приложить readme.txt или ещё что-то. Ну и ещё вариант — в архиве может быть много разных инсталляторов =)
Вы не поняли. Не интегрированное решение, а такой «бутерброд», будут делать много лишней работы. Нельзя посмотреть список файлов без расшифровки и распаковки всего потока. Невозможно сделать запароленный архив с видимым списком файлов. Одно специализированное решение, которое совмещает в себе все нужные функции, может позволить себе быть более гибким в этих вопросах.
Это как новый протокол QUIC (поверх которого работает новый HTTP3). Он совмещает в себе функции TCP, TLS, плюс мультиплексирование потоков в стиле HTTP2. И это даёт ему множество преимуществ по сравнению со старым решением, где надёжная доставка, шифрование и мультиплексирование делалось отдельными технологиями.
Вроде как по крайней мере сохранение прав (те что устанвливаются chmod) работает. Только что специально проверил предоставленной бета-версией. Не знаю как оно в p7zip было.
Решение где это всё интегрировано просто удобнее. Например, вам не нужно расшифровывать и разжимать весь поток данных, чтобы посмотреть какие файлы там хранятся. Вы можете опционально зашифровать имена файлов, или оставить их в нерасшифрованном виде, что тоже бывает удобно. Сжатие также работает лучше в 7-zip, так как он для разных типов файлов в архиве умеет автоматически применять различные фильтры для повышения степени сжатия. Если архивировать всё в tar, а потом запаковывать в xz, то сжатие может оказаться значительно хуже, чем если бы всё архивиловалось и сжималось в 7z.
Речь идёт про Smart Tabs, это когда отступы делаются табами, а выравнивание пробелами. Расширение для VSCode, на которое сослались выше, делает именно это. На мой вкус, это самый правильный стиль, так как сочетает преимущества и пробелов, и табов, но, увы, не самый популярный среди разработчиков, поэтому не в каждом текстовом редакторе есть инструменты для удобного следования такому подходу =(
Так а разве когда-то он требовался в C++? Я его добавляю во все текстовые файлы по двум причинам: нормальный вывод через cat, и отсутствие модификации последней строки при добавлении новых строк в конец файла. На сколько я могу судить, в различные code style добавляют это требование по этим же причинам, а не потому что какому-то компилятору это было нужно. Когда вижу файл без финального перевода строки, так и тянется рука его добавить =) В файлы, которые вы привели для примера, я бы тоже добавил финальный перевод строки.
Но в голову приходит пример, когда это было бы неуместно. Например, на PHP после завершающего `?>` это выглядело бы неуместным, хоть перевод строки после `?>` и игнорируется, да и не принято писать завершающий `?>` уже больше 10 лет. Разработчики GitHub наверняка не пишут на PHP, но это можно было бы использовать как аргумент реализовать поддержку `.editorconfig` и брать соответствующую настройку из него.
Ну большинство стандартов кодирования что я видел требуют завершающий перевод строки. Но да, было бы разумно, если бы оно искало `.editorconfig` и следовало тому что там указано. Хотя, а зачем там вообще есть веб-интерфейс для редактирования файлов в репозитории? Звучит как что-то ненужное =)
Тут вообще нужно понимать, что там ведь по сути трудится та же команда что и до поглощения. Microsoft выделила денег на то чтобы сделать новые классные бесплатные возможности, но она же не увольняла всю старую команду.
К сожалению, не самая востребованная функция. Ни один из редакторов что я использую это не умеет =( Для VSCode хоть нормально работающее расширение есть. Для Notepad++ есть плагин, но он как-то криво работал, когда я пробовал. Авторы Notepad++ и Scintilla дали добро на то, что если кто-то заимплементит такую фичу адекватным образом, что они её примут, но желающих заимплементить это пока что не нашлось. Для обычной Visual Studio что-то такого плагина не нашёл.
Раз в полгода удаляю слишком жирные приложения. Телефон — Galaxy S9+ 2018 года. До маленьких приложений, даже если они не очень нужны, очередь не доходит. А раздутое и не очень нужное удаляется даже с каким-то удовольствием.
Данные о поведении и геолокации, часто получаемые в режиме реального времени, позволяют точно связаться с людьми с сообщением в нужном месте и времени (например, «Здравствуйте! Вы чувствуете себя сонным? Сегодня со скидкой [здесь стоимость акции]»).
Чтобы на баг в таком популярном продукте обратили внимание, нужно чтобы жалобы были массовыми. То есть, если пожалуетесь вы, кто-то ещё, и ещё, и ещё, то вероятность что его начнут изучать повышается. Так что лучше всё же зарепортить проблему, чем не зарепортить =)
Я тоже занимаюсь разработкой одного продукта с десятками миллионов пользователей. Одиночные жалобы не идут дальше техподдержки. Слишком дорого их разбирать. Но иногда просачиваются. Обычно источником проблемы оказывается какой-то сторонний софт на компьютере пользователя. Например, я как-то пару дней потратил на изучение проблемы пользователя, которая, как оказалась, была вызвана сторонним ПО для наушников Razer, потому что они внедряли свою библиотеку во все процессы (чтобы якобы научить их выводить «объёмный» звук), и хукали там какие-то системные функции крайне небезопасным образом (вот прям вообще никогда нельзя так делать, как там было реализовано), что при определённом стечении обстоятельств приводило к падениям. Разные сторонние антивирусы и тому подобное ПО, что внедряется в систему, тоже могут быть источником неприятностей.
Ну в Windows 10 приложения уже несколько лет могут использовать UTF-8 в системных вызовах. Эта возможность конечно же должна явно активироваться манифестом приложения, так как иначе сломались бы все существующие ANSI-приложения. Но это упрощает написание новых кроссплатформенных приложений, так как в принципе возможно.
я хочу, чтобы windows поддерживала posix
Совместимость на уровне сорсов у POSIX-совместимых ОС так себе. Я вам приводил пример выше. Таких различий полно. А Windows совсем другая ОС, её API уровня пользователя проектировался для совместимости с исходным кодом под Win16, а не POSIX. Подсистема POSIX там тоже была, но не прижилась.
чет эплу годы не мешают что-то там менять
Возьмём Age of Empires II под мак (2001 года выпуска). Есть ли шанс запустить? Давайте подумаем. Сколько раз там сломали совместимость? Даже если не считать поломки совместимости на уровне API, можно ещё вспомнить переход с PowerPC на Intel x86-32, затем на Intel x86-64, а теперь вот на ARM. PowerPC не поддерживается уже забыли сколько лет, от поддержки Intel x86-32 отказались относительно недавно, через пару лет откажутся и от Intel x86-64. На фоне этого то что совместимость API в процессе часто ломалась как-то не очень уже и заметно. У Age of Empires II под мак просто нет шансов.
Apple ничего не мешает, так как их политика «никакой совместимости, никакого старого ПО». А Microsoft прикладывает очень много усилий в обеспечение совместимости. Хотя кажется, что они пробуют найти путь, как бы снять с себя эту непростую ношу. Windows RT провалилась, на очереди Windows 10X.
Хотя… Вроде же как NSString хранится в UTF-16? Я в последний раз писал под макось/айос много лет назад, но кажется, что было так. Сомневаюсь, что это переделали. Слишком много возни, хотя с их периодическим полным отказом от старого ПО они и могли бы такое провернуть.
Синдром NIH — это когда какая-нибудь Apple делает свой изначально проприетарный ALAC, который совершенно непонятно зачем вообще создавался, потому что он буквально во всём хуже FLAC, который был создан раньше и был изначально свободным.
А если есть возможность предложить что-то лучшее, чем уже существует, то это уже не NIH, а развитие технологий. Если при этом компания кооперируется с другими заинтересованными сторонами для того, чтобы получить ещё более продуманный стандарт — это ещё лучше.
Визуально кажется что уровней столько же, но UDP там используется только для совместимости с существующими сетями, потому что только так сегодня можно добавить новый протокол транспортного уровня без замены всего железа по всему миру (что близко к невозможному). То есть его роль только в совместимости с существующими сетями. Сам по себе QUIC несёт себе функции TCP, UDP, TLS и мультиплексирования нескольких потоков через одно соединение (что ранее было частью HTTP/2), с кучей новых классных возможностей. То есть раньше часть задач транспортного уровня был вынужден брать на себя HTTP/2 (мультиплексирование нескольких потоков), что было не очень логично, и оно работало плохо из-за всей этой матрёшки (потеряли один пакет одного потока — застряли сразу все потоки), сейчас это ушло куда и положено, на новый транспортный протокол в лице QUIC (который ещё и заменяет TLS, так как только при такой интеграции можно избавиться от недостатков старой связки TCP+TLS+мультиплексор потоков).
Соглашусь, что как опция такая функция не помешала бы. Но на мой взгляд свободность 7-zip перевешивает это преимущество RAR.
1. github.com/billziss-gh/winfsp
2. github.com/dokan-dev/dokany
3. github.com/crossmeta/cxfuse
Это как новый протокол QUIC (поверх которого работает новый HTTP3). Он совмещает в себе функции TCP, TLS, плюс мультиплексирование потоков в стиле HTTP2. И это даёт ему множество преимуществ по сравнению со старым решением, где надёжная доставка, шифрование и мультиплексирование делалось отдельными технологиями.
Но в голову приходит пример, когда это было бы неуместно. Например, на PHP после завершающего `?>` это выглядело бы неуместным, хоть перевод строки после `?>` и игнорируется, да и не принято писать завершающий `?>` уже больше 10 лет. Разработчики GitHub наверняка не пишут на PHP, но это можно было бы использовать как аргумент реализовать поддержку `.editorconfig` и брать соответствующую настройку из него.
Тут вообще нужно понимать, что там ведь по сути трудится та же команда что и до поглощения. Microsoft выделила денег на то чтобы сделать новые классные бесплатные возможности, но она же не увольняла всю старую команду.
Я тоже занимаюсь разработкой одного продукта с десятками миллионов пользователей. Одиночные жалобы не идут дальше техподдержки. Слишком дорого их разбирать. Но иногда просачиваются. Обычно источником проблемы оказывается какой-то сторонний софт на компьютере пользователя. Например, я как-то пару дней потратил на изучение проблемы пользователя, которая, как оказалась, была вызвана сторонним ПО для наушников Razer, потому что они внедряли свою библиотеку во все процессы (чтобы якобы научить их выводить «объёмный» звук), и хукали там какие-то системные функции крайне небезопасным образом (вот прям вообще никогда нельзя так делать, как там было реализовано), что при определённом стечении обстоятельств приводило к падениям. Разные сторонние антивирусы и тому подобное ПО, что внедряется в систему, тоже могут быть источником неприятностей.
Совместимость на уровне сорсов у POSIX-совместимых ОС так себе. Я вам приводил пример выше. Таких различий полно. А Windows совсем другая ОС, её API уровня пользователя проектировался для совместимости с исходным кодом под Win16, а не POSIX. Подсистема POSIX там тоже была, но не прижилась.
Возьмём Age of Empires II под мак (2001 года выпуска). Есть ли шанс запустить? Давайте подумаем. Сколько раз там сломали совместимость? Даже если не считать поломки совместимости на уровне API, можно ещё вспомнить переход с PowerPC на Intel x86-32, затем на Intel x86-64, а теперь вот на ARM. PowerPC не поддерживается уже забыли сколько лет, от поддержки Intel x86-32 отказались относительно недавно, через пару лет откажутся и от Intel x86-64. На фоне этого то что совместимость API в процессе часто ломалась как-то не очень уже и заметно. У Age of Empires II под мак просто нет шансов.
Apple ничего не мешает, так как их политика «никакой совместимости, никакого старого ПО». А Microsoft прикладывает очень много усилий в обеспечение совместимости. Хотя кажется, что они пробуют найти путь, как бы снять с себя эту непростую ношу. Windows RT провалилась, на очереди Windows 10X.
Хотя… Вроде же как NSString хранится в UTF-16? Я в последний раз писал под макось/айос много лет назад, но кажется, что было так. Сомневаюсь, что это переделали. Слишком много возни, хотя с их периодическим полным отказом от старого ПО они и могли бы такое провернуть.