Это историческая орфография, поэтому и пишем жи/ши с буквой и, понятно что слово парашют и жюри заимствованное. Также и морфологически. Например окончание глаголов ишь/ешь. Мягкий знак тут не влияет на звук ш, а лишь обозначает 2 лицо. Или сочетание сч, если с относится к приставке, а ч к корню, то пишется сч, если обе относятся к корню, то щ. А также обратные нелогичные исключения, когда бы писалась другая буква. Например всем известное йод, хотя правильнее было бы писать ёд. Так же и с "е" которая произносится как э в некоторых словах. В орфографии есть некоторые правила в параграфах, например на конце слов пишется е, после гласных э. Но это больше напоминает придумывание правил с исключениями под реальность, а не реальность под правила.
Зависит назначения. Если нужно для обратного преобразования, для сохранения побуквенной орфографии, то нужно писать bassjejn, если требуется чтобы иностранец прочитал слово близко к русскому звучанию, то basein. В предыдущем коменте я привёл ещё больше примеров. Пускай будет своя орфография для транслита без исключений, вроде жи/ши всегда с буквой и. Идея использовать h для служебного значения имеет право на жизнь. А вот использовать x как ш мне не нравится. И что что в каком-то испанском обозначает ш, если там произошёл переход, это не значит что нужно и нам использовать. Это как в английском a это эй, а i это ай. Это же не значит что нужно использовать a вместо э и i вместо а. Конечно чем меньше диграфов, тем лучше, но не уходить в абсолют. Раз уж всё равно у нас гласные остаются диграфами, одним больше - одним меньше.
Тоже с буквой е, либо её передавать как je, это дело привычки, либо всегда писать e. Либо для е использовать ě, либо для э использовать è, чтобы их различать. Поэтому наиболее универсальным остаётся уже существующий стандарт ISO 9/ООН 1987, где есть варианты с диакритикой и без.
Вообще кириллицу сложно передавать без диакритики. Почти во всех европейских языках есть буквы с диакритикой, а значит не стоит её боятся и понятно что это буквы с модификацией. А варианты для выбора уже есть, белорусская латинка, чешский алфавит с диакритикой или изобретать свои буквы как в сербском Ђ Ћ Џ только для латиницы.
Не знаю что тут так много спорят. Но спорят об разном. Про передачу побуквенно, так чтобы можно было восстановить обратно слово потом. Так тогда не нужно ничего выдумывать, а берём гост или iso пользуемся, там где kh → х, ya/ia → я и тд. Если нужно передать фонетический образ слова, тогда во-первых есть несколько славянских языков пользующихся латиницею и в зависимости от этого можно пойти 3 разными путями. Если у нас есть латиница с диакритикой, тогда берём чешский вариант, где č → ч, š → ш, ž → ж. Если у нас нет диакритики, тогда польский вариант, без вариантов нужны будут диграфы: cz → ч, sz → ш, zs → ж. Как видим, что латиница без диакритики плохо подходит для передачи кириллицы. Дальше третье, гласные. Можно изобрести диакритики для йотированных гласных, такие как ö → ё, ä → я, ü → ю, ě → е, они будут понятны европейским, такие умляуты есть например в немецком, турецком, скандинавских. Опять же, если у нас нет диакритики, то можно пойти по хорватскому варианту, использовать диграф для йотированных гласных, будем использовать букву йот: ja → я, je → е, ji → и, jo → йо, ju → ю, а не ya/ia, потому что y → ы, i → и. Дальше остались мягкий и твёрдый знак, в целом они менее важные, но используем йот j для смягчения как в хорватском и сербском и апостроф ' для твёрдого знака как в украинском и белорусском. Что же касается буквы щ, то это исторически диграф ш+ч, и в некоторых словах хоть и произносится щ, продолжает писаться шч или сч. Щ одна из менее частотных букв, тот тут записываем диграфом šč - щ или szcz = щ, объяснение дальше. Далее, даже более важное, про фонетический облик слова, и тут все начинают путать его с орфографией, она больше мешает тут. Чтобы передать слово латиницей, как оно приблизительно звучит не нужно смотреть какие действительно буквы используются. Потому что счастье/щастье/шчастье/щястье, счёт/щьот/шчёт, йод/ёд/ёт, мужчина/мущина/мущына, сделаешь/зделаеш, пишется/пишеца/пишэцца, съезд/сьезт/сйэзт, лыжи/лыжы, каньон/каньйон/каньён если произнести, то для русского это звучит одинаково. Потому что ш, ж, ц всегда твёрдые, а ч, щ, всегда мягкие. Звук щ передаётся следующими буквами: щ/сч/шч/зщ/сщ/жд. Буква ё появилась сравнительно недавно и если бы эти слова были заимствованы сейчас, то писались бы более правильно без исключений: йод → ёд, йогурт → ёгурт, Токио → Токё, Тойота → Тоёта, Нью-Йорк → Нью-Ёрк. Поэтому чтобы передать русское звучание, не нужно соблюдать исключения в орфографии побуквенно, нужно писать lyžy → лыжи, а не lyži; žoltovo → жёлтого, а не žjoltogo; kafe → кафе[э], а не kafje.
Не рекомендую. Горизонтальное выравнивание не нужно, ни для запятых, ни для знака равно. Вы говорите про trailing comma, чтобы не портить diff, но при этом используете выравнивание пробелами. Это плохо работает. Например, я через IDE переименовываю функцию, и это сразу нужно во всех файлах ещё проследить чтобы аргументы остались выровненными. Или если само имя функции уже настолько длинное, что аргументы будут уже за границами. Или подряд две похожие функции с разной длиной имени, но одинаковыми аргументами будут иметь разные отступы аргументов. Я пришёл к выводу что простой одинарный отступ (принятый в вашем языке) лучше всего. Почему первому аргументу такое особое отношение? Если уж переносить, то переносить всё, либо ничего.
CallFunc(
arg1,
arg2,
arg3);
Или выравнивание по равно. Это тоже портит будущие дифы. Кроме того не автоматизируется. Этот кусок кода не получится скопировать в другое место без переформатирования. А если они в разных блоках, разделены вызовом функции, то они должны иметь одинаковый или у каждого блока свой? Так же каждый раз смотреть в конец строки чтобы понять какая логика там на самом деле неудобно. Вот было:
a = 3;
bcd = 4;
А потом добавили/удалили новый и придётся все выравнивать по новой.
Мне кажется это проф деформацию Unity. Что в первом примере, что во втором. Может в юнити так принято перегружать операторы и использовать рефлексию направо-налево. Там всё странно, он как будто вообще не имеет ничего общего с C#, кроме синтаксиса. Взять хотя бы метод GetComponent<> никто в энтерпрайзе так не делает, иерархия наследования всего от MonoBehaviour, использование event, public/private. Там нет привычных DI, контроллеров, сервисов. Поэтому там скорее всего свои соглашения по хорошему коду.
Вот когда будет больше 3 параметров, тогда и можно делать. Что исходит из KISS/YAGNI, не нужно заранее делать, работает не трогай.
Хороший подход к рефакторингу. Первый раз делаешь плюёшься, второй раз (когда в том же месте исправление) примечаешь и только на третий раз рефакторишь.
Во-первых, он делает оптимизации только под конкретный случай, а что если кроме квадратов и прямоугольников добавятся другие фигуры, то придётся переписывать весь код, вместо добавления одного нового класса.
Во-вторых, зачем считать виртуальные вызовы, кешлайны, бранч предиктор в 2к24. Особенно в тех местах где производительность не важна, у нас например поход по сети, и по сравнению с ним вычисление площади не занимает ничего. Да виртуальные вызовы это дольше. Так давайте перепишем всё на процедурный стиль и свитчи. Но сами вызовы функций это тоже долго, давайте всё заинлайним в одну длинную функцию, но и это долго, давайте перепишем на ассемблер. Нужно же где-то остановиться. Оптимизацию производительности нужно производить там, где это нужно по профайлеру. Преждевременная оптимизации корень всех зол - цитата Дональда Кнута как ни что подходит сюда.
В-третьих, девиртуализировать вызовы, разворачивать циклы, заменять наследования на свитчи всё это должен делать оптимизирующий компилятор, он машина - он пускай работает, и не нужно руками делать ту работу которую автоматизация делает лучше. И если компиляторы что-то из этого сейчас не умеют, то научаться и с наследованием будет также быстро, как со свитчами. Хорошее замечание, что например в IDE автодополнение методов-членов после точки у этой переменной, но не функций принимающую данную переменную как параметр, что уже провоцирует писать в определённом стиле. Паттерны банды четырёх для Java были нужны, когда не было возможностей написать по другому.
Я тут не защищаю именно ООП, есть и другие подходы, например Rust где есть только структуры и методы, или Haskell где всё функции с типами. Каждому инструменту своё место.
Странный отказ от гугла когда покупаешь гугл пиксель, ставишь на него прошивку без гугл-сервисов, которая идёт только на гугл пиксель и ставить гугл-сервисы. А потом автор пишет, что задумывается купить айфон.
Была нормальная статья по замене сервисов гугл, свободными или приватными сервисами, а не это вот. В основном нужна лёгкая замена поиска и почты. Хранилище заменяется вообще всем что угодно, хоть гугл драйв, главное чтобы был webdav доступ из своего приложения. Облачные документы, если используются в компании, то это сложно заменить, нужно ставить собственный и использовать odt вместо docx.
Отказ от гугла, это не отказ от гугла в пользу эпла или микрософт. Это отказ от шпионящих сервисов на открытые или сохраняющие конфиденциальность как DuckDuckGo.
Всё есть файл это удобная концепция. Гораздо удобнее иметь единый интерфейс. Что угодно, хоть память программы, хоть медиа файл. Что-то из них для записи, что-то только для чтения. Некоторые имеют размер, некоторые не имеют размер пока не прочитаешь до конца (например файл на сжатом носителе, имеет реальный и хранимый размер). И это позволяет имеет единые инструменты для работы с файлами. Можно подключить файл как файловую систему - SquashFS, CDFS. Можно подключить сетевой диск как файловую систему - NFS, sshfd. Сетевое хранилище - s3fs, ipfs. Память процесса - procfs. Вполне возможно подключить mp4 файл как файловую систему и внутри неё будут как отдельные файлы, аудио- и видео-дорожка. Про стримы не понимаю в чём разница. Да медиа стрим это не файл, но стримы хранятся внутри файла. Например mp4 файл имеет аудио и видео стрим, но при этом и сам является стримом. Также и один поток может храниться в отдельных файлах-чанках. То есть если смешивать файлы и стримы, то граница стирается. Например каждый файл в архиве это свой поток. Пример про регистратор не верный, потому что регистратор записывает не стримы, а файлы, можно писать раздельно звуковую и видео дорожку, но циклическая перезапись файлов, а не потоков. Ничего не мешает, например прозрачно копировать в архив или в /dev/null. Поэтому гораздо удобнее представить любой файл/поток/устройство/сетевое устройство и получить кучу существующих утилит для работы с файлами, а ее изобретать на каждое понятие свой API и ждать пока появятся утилиты. Всё есть объект это тоже универсальный интерфейс, но такие операционные системы не распространены и меньше инструментов для работы с объектами. И мы не видим всплеска интереса к таким системам, не многие даже смогут назвать пару. Но как размышление статья хорошая.
Только все принимаемые коммиты контролируются командой Google. В движок вшито много гугловых сервисов, выпилить или просто выключить их нетривиальная задача. А уж говоря про браузер Google Chrome, то он не является открытым и никому не известно какие пакости туда встраиваются на этапе сборки.
Так в этом случае надо не браузер менять, а поставить плагин для смены юзерагента. Или не пользоваться такими сайтами. Поддержка стандартов в браузерах примерно на одном уровне, а это значит что разработчики сайта не захотели делать по стандарту, а не проблемы у браузера. Был бы Firefox популярнее в миг бы починили.
Была уже похожая тема от Holden Shearer. И в защиту приводили точно такие же доводы. А давайте хранить госномера/парковочное место в NFT блокчейне. Ведь тогда сразу будет понятно, кому принадлежит то-то. Но конечно это надо делать централизовано, чтоб государство хранило блокчейн базу. Только вот доступ к проверке, должен быть через единое API. Но зачем тогда заложенная децентрализация блокчейна? Да любой может скачать блокчейн базу себе и поднять ноду, но всё равно любое приложение будет проверять принадлежность владения через единое API. Да, госудаство внутри API может делать это распределённо на нескольких нодах, но зачем это когда все ноды контролирует одно лицо, и никто не будет использовать конценсус с твоей нодой. Да, но зачем так усложнять простое хранение госномеров, тратя впустую киловатты и такты процессора, если можно просто хранить эти записи в простой базе без блокчейна.
NFT имеет целиком спекулятивную стоимость, так же как и биткоин. Но биткоин является средством обмена, а NFT является лишь записью ссылки на объект. Также как фиатные деньги не обеспечиваются материальным, но являются средством обмена, но их гарантию обеспечивает центробанк по федеральным законам. NFT имеет ценность, но лишь ту ценность что покупатель готов заплатить. Купили вы NFT первого твита за 2 миллиона, смогли продать его дороже - вы молодцы, вам предлагают лишь 200 долларов - вы неудачник и потратили 2 миллиона впустую.
NFT это лишь фикция имущества. И есть много проблем. Покупая NFT токен, вы лишь покупате в запись в базе данных, что такой-то URL принадлежит вам. Может ли копия этого урла быть в другом NFT блокчейне? - да. Гарантирует ли NFT имущественные или другия права владения и распоряжения? - нет. Гарантирует ли NFT сохранность объект лежащего по ссылке? - нет. Например, можно иметь NFT ссылку на изображение обезьяны, но сервер по скрипту через запрограммированное время станет отдавать эмодзи какашки, или просто например ограничивать доступ по ip, или сервер где хранится картинка банально закроется.
Есть случаи когда OpenSea удалял NFT токен. Казалось бы блокчейн, как можно удалить что-то из базы, а вот оказалось можно. Потому что проверка происходит на сайте OpenSea, через его единое API, которое обращается к его личной ноде. То есть это не является настоящим блокчейном, это лишь то что эмулирует децентрализацию, но нам самом деле является обычной централизованной базой данных по продаже ссылок.
Нет, даже если перейти ссылка не расшифровывается, что видно обведено на первом скрине в статье. А уж запрещать копировать это не нормально, это нарушает определение гипертекста. Это они уже сделали в своём приложении. На крайний случай должна быть кнопка поделится ссылкой, но она опять будет со ключами слежения.
Что случится, если я попрошу друга скинуть мне ссылку на новость? Он скопирует её со своим личным ключём слежения получается. То тогда моё посещение зачтётся ему получается? И главное что он никак не может предотвратить это даже если хочет. Если раньше опытный пользователь мог удалить мусор из ссылки перед тем как посылать другу, то теперь это сделать никак.
Фейсбук ломает понятие веб-паутины и URL. И он это делает лишь потому, что им пользуются миллионы людей и не могут отказаться.
Мне никогда не нравилась эта вещь кого кто-то скидывает ссылку, а к ней прикреплены параметры слежения, из-за чего ссылка становится километровой длины.
Я бы хотел расширение которое показывает чистую ссылку всегда. Взять тот же сокращатель t.co во-первых, этот сайт не всегда доступен без vpn, во-вторых хотелось бы видеть что скрывается под ссылкой сразу virus.xxx/download.exe или ru.wikipedia.org/article/123. Да, ссылки t.co не уникальные, но их без посещения сайта расшифровать нельзя.
Это пошло не от Линуса и всего прочего. Пишут "Add" в повелительно наклонении именно потому, что когда мейнтейнер принимает патч (или письмо с патчем), а в более простых случаях принимает Merge request, то сообщение коммита говорит "добавить кнопку" и мейнтейнер делает выбор yes/no. То есть коммит говорит, какое действие он сделает при применении. Об этом ещё в Pro Git Book написано и много чего другого.
Удивительно, но движки оптимизируют что они могут парсить и исполнять мегабайты js кода на лету, но отобразить несколько килобайт текста это создаёт нагрузку.
Это историческая орфография, поэтому и пишем жи/ши с буквой и, понятно что слово парашют и жюри заимствованное. Также и морфологически. Например окончание глаголов ишь/ешь. Мягкий знак тут не влияет на звук ш, а лишь обозначает 2 лицо. Или сочетание сч, если с относится к приставке, а ч к корню, то пишется сч, если обе относятся к корню, то щ. А также обратные нелогичные исключения, когда бы писалась другая буква. Например всем известное йод, хотя правильнее было бы писать ёд. Так же и с "е" которая произносится как э в некоторых словах. В орфографии есть некоторые правила в параграфах, например на конце слов пишется е, после гласных э. Но это больше напоминает придумывание правил с исключениями под реальность, а не реальность под правила.
Зависит назначения. Если нужно для обратного преобразования, для сохранения побуквенной орфографии, то нужно писать bassjejn, если требуется чтобы иностранец прочитал слово близко к русскому звучанию, то basein. В предыдущем коменте я привёл ещё больше примеров. Пускай будет своя орфография для транслита без исключений, вроде жи/ши всегда с буквой и. Идея использовать h для служебного значения имеет право на жизнь. А вот использовать x как ш мне не нравится. И что что в каком-то испанском обозначает ш, если там произошёл переход, это не значит что нужно и нам использовать. Это как в английском a это эй, а i это ай. Это же не значит что нужно использовать a вместо э и i вместо а. Конечно чем меньше диграфов, тем лучше, но не уходить в абсолют. Раз уж всё равно у нас гласные остаются диграфами, одним больше - одним меньше.
Тоже с буквой е, либо её передавать как je, это дело привычки, либо всегда писать e. Либо для е использовать ě, либо для э использовать è, чтобы их различать. Поэтому наиболее универсальным остаётся уже существующий стандарт ISO 9/ООН 1987, где есть варианты с диакритикой и без.
Вообще кириллицу сложно передавать без диакритики. Почти во всех европейских языках есть буквы с диакритикой, а значит не стоит её боятся и понятно что это буквы с модификацией. А варианты для выбора уже есть, белорусская латинка, чешский алфавит с диакритикой или изобретать свои буквы как в сербском Ђ Ћ Џ только для латиницы.
Не знаю что тут так много спорят. Но спорят об разном. Про передачу побуквенно, так чтобы можно было восстановить обратно слово потом. Так тогда не нужно ничего выдумывать, а берём гост или iso пользуемся, там где kh → х, ya/ia → я и тд.
Если нужно передать фонетический образ слова, тогда во-первых есть несколько славянских языков пользующихся латиницею и в зависимости от этого можно пойти 3 разными путями. Если у нас есть латиница с диакритикой, тогда берём чешский вариант, где č → ч, š → ш, ž → ж. Если у нас нет диакритики, тогда польский вариант, без вариантов нужны будут диграфы: cz → ч, sz → ш, zs → ж. Как видим, что латиница без диакритики плохо подходит для передачи кириллицы. Дальше третье, гласные. Можно изобрести диакритики для йотированных гласных, такие как ö → ё, ä → я, ü → ю, ě → е, они будут понятны европейским, такие умляуты есть например в немецком, турецком, скандинавских. Опять же, если у нас нет диакритики, то можно пойти по хорватскому варианту, использовать диграф для йотированных гласных, будем использовать букву йот: ja → я, je → е, ji → и, jo → йо, ju → ю, а не ya/ia, потому что y → ы, i → и. Дальше остались мягкий и твёрдый знак, в целом они менее важные, но используем йот j для смягчения как в хорватском и сербском и апостроф ' для твёрдого знака как в украинском и белорусском. Что же касается буквы щ, то это исторически диграф ш+ч, и в некоторых словах хоть и произносится щ, продолжает писаться шч или сч. Щ одна из менее частотных букв, тот тут записываем диграфом šč - щ или szcz = щ, объяснение дальше.
Далее, даже более важное, про фонетический облик слова, и тут все начинают путать его с орфографией, она больше мешает тут. Чтобы передать слово латиницей, как оно приблизительно звучит не нужно смотреть какие действительно буквы используются. Потому что счастье/щастье/шчастье/щястье, счёт/щьот/шчёт, йод/ёд/ёт, мужчина/мущина/мущына, сделаешь/зделаеш, пишется/пишеца/пишэцца, съезд/сьезт/сйэзт, лыжи/лыжы, каньон/каньйон/каньён если произнести, то для русского это звучит одинаково. Потому что ш, ж, ц всегда твёрдые, а ч, щ, всегда мягкие. Звук щ передаётся следующими буквами: щ/сч/шч/зщ/сщ/жд. Буква ё появилась сравнительно недавно и если бы эти слова были заимствованы сейчас, то писались бы более правильно без исключений: йод → ёд, йогурт → ёгурт, Токио → Токё, Тойота → Тоёта, Нью-Йорк → Нью-Ёрк. Поэтому чтобы передать русское звучание, не нужно соблюдать исключения в орфографии побуквенно, нужно писать lyžy → лыжи, а не lyži; žoltovo → жёлтого, а не žjoltogo; kafe → кафе[э], а не kafje.
Не рекомендую. Горизонтальное выравнивание не нужно, ни для запятых, ни для знака равно. Вы говорите про trailing comma, чтобы не портить diff, но при этом используете выравнивание пробелами. Это плохо работает. Например, я через IDE переименовываю функцию, и это сразу нужно во всех файлах ещё проследить чтобы аргументы остались выровненными. Или если само имя функции уже настолько длинное, что аргументы будут уже за границами. Или подряд две похожие функции с разной длиной имени, но одинаковыми аргументами будут иметь разные отступы аргументов. Я пришёл к выводу что простой одинарный отступ (принятый в вашем языке) лучше всего. Почему первому аргументу такое особое отношение? Если уж переносить, то переносить всё, либо ничего.
CallFunc(arg1,arg2,arg3);Или выравнивание по равно. Это тоже портит будущие дифы. Кроме того не автоматизируется. Этот кусок кода не получится скопировать в другое место без переформатирования. А если они в разных блоках, разделены вызовом функции, то они должны иметь одинаковый или у каждого блока свой? Так же каждый раз смотреть в конец строки чтобы понять какая логика там на самом деле неудобно. Вот было:
a = 3;bcd = 4;А потом добавили/удалили новый и придётся все выравнивать по новой.
a = 3;bcd = 4;my_new_long_parameter = 5;Мне кажется это проф деформацию Unity. Что в первом примере, что во втором. Может в юнити так принято перегружать операторы и использовать рефлексию направо-налево. Там всё странно, он как будто вообще не имеет ничего общего с C#, кроме синтаксиса. Взять хотя бы метод GetComponent<> никто в энтерпрайзе так не делает, иерархия наследования всего от MonoBehaviour, использование event, public/private. Там нет привычных DI, контроллеров, сервисов. Поэтому там скорее всего свои соглашения по хорошему коду.
Вот когда будет больше 3 параметров, тогда и можно делать. Что исходит из KISS/YAGNI, не нужно заранее делать, работает не трогай.
Хороший подход к рефакторингу. Первый раз делаешь плюёшься, второй раз (когда в том же месте исправление) примечаешь и только на третий раз рефакторишь.
Помню это обсуждение и пришли новые мысли.
Во-первых, он делает оптимизации только под конкретный случай, а что если кроме квадратов и прямоугольников добавятся другие фигуры, то придётся переписывать весь код, вместо добавления одного нового класса.
Во-вторых, зачем считать виртуальные вызовы, кешлайны, бранч предиктор в 2к24. Особенно в тех местах где производительность не важна, у нас например поход по сети, и по сравнению с ним вычисление площади не занимает ничего. Да виртуальные вызовы это дольше. Так давайте перепишем всё на процедурный стиль и свитчи. Но сами вызовы функций это тоже долго, давайте всё заинлайним в одну длинную функцию, но и это долго, давайте перепишем на ассемблер. Нужно же где-то остановиться. Оптимизацию производительности нужно производить там, где это нужно по профайлеру. Преждевременная оптимизации корень всех зол - цитата Дональда Кнута как ни что подходит сюда.
В-третьих, девиртуализировать вызовы, разворачивать циклы, заменять наследования на свитчи всё это должен делать оптимизирующий компилятор, он машина - он пускай работает, и не нужно руками делать ту работу которую автоматизация делает лучше. И если компиляторы что-то из этого сейчас не умеют, то научаться и с наследованием будет также быстро, как со свитчами. Хорошее замечание, что например в IDE автодополнение методов-членов после точки у этой переменной, но не функций принимающую данную переменную как параметр, что уже провоцирует писать в определённом стиле. Паттерны банды четырёх для Java были нужны, когда не было возможностей написать по другому.
Я тут не защищаю именно ООП, есть и другие подходы, например Rust где есть только структуры и методы, или Haskell где всё функции с типами. Каждому инструменту своё место.
Можно пользоваться и гугловым драйвом, если данные зашифрованы и не использовать их проприетарное приложение или сайт.
Странный отказ от гугла когда покупаешь гугл пиксель, ставишь на него прошивку без гугл-сервисов, которая идёт только на гугл пиксель и ставить гугл-сервисы. А потом автор пишет, что задумывается купить айфон.
Была нормальная статья по замене сервисов гугл, свободными или приватными сервисами, а не это вот. В основном нужна лёгкая замена поиска и почты. Хранилище заменяется вообще всем что угодно, хоть гугл драйв, главное чтобы был webdav доступ из своего приложения. Облачные документы, если используются в компании, то это сложно заменить, нужно ставить собственный и использовать odt вместо docx.
Отказ от гугла, это не отказ от гугла в пользу эпла или микрософт. Это отказ от шпионящих сервисов на открытые или сохраняющие конфиденциальность как DuckDuckGo.
Всё есть файл это удобная концепция. Гораздо удобнее иметь единый интерфейс. Что угодно, хоть память программы, хоть медиа файл. Что-то из них для записи, что-то только для чтения. Некоторые имеют размер, некоторые не имеют размер пока не прочитаешь до конца (например файл на сжатом носителе, имеет реальный и хранимый размер). И это позволяет имеет единые инструменты для работы с файлами. Можно подключить файл как файловую систему - SquashFS, CDFS. Можно подключить сетевой диск как файловую систему - NFS, sshfd. Сетевое хранилище - s3fs, ipfs. Память процесса - procfs. Вполне возможно подключить mp4 файл как файловую систему и внутри неё будут как отдельные файлы, аудио- и видео-дорожка. Про стримы не понимаю в чём разница. Да медиа стрим это не файл, но стримы хранятся внутри файла. Например mp4 файл имеет аудио и видео стрим, но при этом и сам является стримом. Также и один поток может храниться в отдельных файлах-чанках. То есть если смешивать файлы и стримы, то граница стирается. Например каждый файл в архиве это свой поток. Пример про регистратор не верный, потому что регистратор записывает не стримы, а файлы, можно писать раздельно звуковую и видео дорожку, но циклическая перезапись файлов, а не потоков. Ничего не мешает, например прозрачно копировать в архив или в /dev/null. Поэтому гораздо удобнее представить любой файл/поток/устройство/сетевое устройство и получить кучу существующих утилит для работы с файлами, а ее изобретать на каждое понятие свой API и ждать пока появятся утилиты. Всё есть объект это тоже универсальный интерфейс, но такие операционные системы не распространены и меньше инструментов для работы с объектами. И мы не видим всплеска интереса к таким системам, не многие даже смогут назвать пару. Но как размышление статья хорошая.
Уже давно можно использовать
git switchвместоgit checkout, как более простую для пользователей.На дворе 2022 год, и до сих пор перепечатывают одну туже статью.
Более кликбейтный заголовок я видел: Сисадмин пытался найти инопланетян.
Только все принимаемые коммиты контролируются командой Google. В движок вшито много гугловых сервисов, выпилить или просто выключить их нетривиальная задача. А уж говоря про браузер Google Chrome, то он не является открытым и никому не известно какие пакости туда встраиваются на этапе сборки.
Так в этом случае надо не браузер менять, а поставить плагин для смены юзерагента. Или не пользоваться такими сайтами. Поддержка стандартов в браузерах примерно на одном уровне, а это значит что разработчики сайта не захотели делать по стандарту, а не проблемы у браузера. Был бы Firefox популярнее в миг бы починили.
Почему не сделать черный список плохих сайтов и для них отдавать исправленный, а для остальных нормальных отдавать Vivaldi. Было бы приятно видеть.
Была уже похожая тема от Holden Shearer. И в защиту приводили точно такие же доводы. А давайте хранить госномера/парковочное место в NFT блокчейне. Ведь тогда сразу будет понятно, кому принадлежит то-то. Но конечно это надо делать централизовано, чтоб государство хранило блокчейн базу. Только вот доступ к проверке, должен быть через единое API. Но зачем тогда заложенная децентрализация блокчейна? Да любой может скачать блокчейн базу себе и поднять ноду, но всё равно любое приложение будет проверять принадлежность владения через единое API. Да, госудаство внутри API может делать это распределённо на нескольких нодах, но зачем это когда все ноды контролирует одно лицо, и никто не будет использовать конценсус с твоей нодой. Да, но зачем так усложнять простое хранение госномеров, тратя впустую киловатты и такты процессора, если можно просто хранить эти записи в простой базе без блокчейна.
NFT имеет целиком спекулятивную стоимость, так же как и биткоин. Но биткоин является средством обмена, а NFT является лишь записью ссылки на объект. Также как фиатные деньги не обеспечиваются материальным, но являются средством обмена, но их гарантию обеспечивает центробанк по федеральным законам. NFT имеет ценность, но лишь ту ценность что покупатель готов заплатить. Купили вы NFT первого твита за 2 миллиона, смогли продать его дороже - вы молодцы, вам предлагают лишь 200 долларов - вы неудачник и потратили 2 миллиона впустую.
NFT это лишь фикция имущества. И есть много проблем. Покупая NFT токен, вы лишь покупате в запись в базе данных, что такой-то URL принадлежит вам. Может ли копия этого урла быть в другом NFT блокчейне? - да. Гарантирует ли NFT имущественные или другия права владения и распоряжения? - нет. Гарантирует ли NFT сохранность объект лежащего по ссылке? - нет. Например, можно иметь NFT ссылку на изображение обезьяны, но сервер по скрипту через запрограммированное время станет отдавать эмодзи какашки, или просто например ограничивать доступ по ip, или сервер где хранится картинка банально закроется.
Есть случаи когда OpenSea удалял NFT токен. Казалось бы блокчейн, как можно удалить что-то из базы, а вот оказалось можно. Потому что проверка происходит на сайте OpenSea, через его единое API, которое обращается к его личной ноде. То есть это не является настоящим блокчейном, это лишь то что эмулирует децентрализацию, но нам самом деле является обычной централизованной базой данных по продаже ссылок.
Нет, даже если перейти ссылка не расшифровывается, что видно обведено на первом скрине в статье. А уж запрещать копировать это не нормально, это нарушает определение гипертекста. Это они уже сделали в своём приложении. На крайний случай должна быть кнопка поделится ссылкой, но она опять будет со ключами слежения.
Что случится, если я попрошу друга скинуть мне ссылку на новость? Он скопирует её со своим личным ключём слежения получается. То тогда моё посещение зачтётся ему получается? И главное что он никак не может предотвратить это даже если хочет. Если раньше опытный пользователь мог удалить мусор из ссылки перед тем как посылать другу, то теперь это сделать никак.
Фейсбук ломает понятие веб-паутины и URL. И он это делает лишь потому, что им пользуются миллионы людей и не могут отказаться.
Мне никогда не нравилась эта вещь кого кто-то скидывает ссылку, а к ней прикреплены параметры слежения, из-за чего ссылка становится километровой длины.
Я бы хотел расширение которое показывает чистую ссылку всегда. Взять тот же сокращатель t.co во-первых, этот сайт не всегда доступен без vpn, во-вторых хотелось бы видеть что скрывается под ссылкой сразу virus.xxx/download.exe или ru.wikipedia.org/article/123. Да, ссылки t.co не уникальные, но их без посещения сайта расшифровать нельзя.
Это пошло не от Линуса и всего прочего. Пишут "Add" в повелительно наклонении именно потому, что когда мейнтейнер принимает патч (или письмо с патчем), а в более простых случаях принимает Merge request, то сообщение коммита говорит "добавить кнопку" и мейнтейнер делает выбор yes/no. То есть коммит говорит, какое действие он сделает при применении. Об этом ещё в Pro Git Book написано и много чего другого.