Из недавнего ещё: ESR — сооснователя и президента OSI — забанили в списке рассылки OSI, где всерьёз обсуждалась абсурдная возможность внедрения в open source лицензии пунктов, запрещающих использование софта определённым "плохим" людям и организациям.
TikTok скорее клон Vine (который в своё время всех настолько достал, что к публикуемым в интернете роликам стали дописывать "NOT VINE"), в рекламу которого вкачали ещё больше денег.
Но ведь семантика терминов «whitelist» и «include[list]» совершенно разная!
Во-первых, как «blacklist», так и «whitelist» — списки исключений. Например, в каком-нибудь условном адблоке адреса из белого списка являются исключениями из общих правил блокировки, не должны проверяться регулярками и пролетать насквозь. И точно также адреса из чёрного списка являются исключениями из общих правил — они тоже не должны проверяться, а сразу блокироваться. Уже здесь назревает путаница, потому что в новой терминологии теперь есть свои «исключения» — «exclude»! А «include» рядом ещё и создаёт впечатление, что для того, чтобы с объектом было проведено какое-то действие, он должен быть «включён» в список «includelist», а это не так.
Во-вторых, разные проекты заменяют «неполиткорректные» старые термины разными новыми. Где-то это «blocklist», где-то «stoplist», где-то «excludelist», где-то просто «exclude». Такая фрагментация только добавит проблем.
В-третьих, новые термины ещё и весьма неоднозначные — например в xdebug теперь есть XDEBUG_PATH_INCLUDE. Это что — путь, по которому что-то лежит? Как CPLUS_INCLUDE_PATH? Нет. А читается именно так.
Эту дичь следует остановить немедленно. Я уверен, что людей, которые не одобряют такие изменения, достаточно, однако всеобщее внедрение в проектах «кодексов поведения» приводит к тому, что они даже боятся высказаться против, потому что «Расист! Расист!». Наблюдаем ru.wikipedia.org/wiki/Спираль_молчания во всей красе.
Потому что YouTube по решению левой пятки отключает монетизацию у людей, которые снимают качественный контент и где я смотрел бы какой-нибудь 5-секундный преролл, зато вот такой откровенный скам откручивают в рекомендациях по нескольку месяцев к ряду совершенно без проблем, и все жалобы им до одного места. А «решение», которое предлагает саппорт — «включить персонализацию рекламы на основе интересов». Спасибо, идите в жопу.
У меня вся выдача гугла по техническим кейвордам засрана сайтами с автопереводами. Раньше был qaru.site, а теперь сотни их — overcoder.net, stackoverrun.com, coderoad.ru, progi.pro, ruphp.com… Спасает только VPN из Голландии. Вот эта черезмерная гугловская «локальность» последние несколько лет только мешает.
Но poetry и ему подобные инструменты могут "замораживать" установленные версии пакетов. Poetry записывает эти версии в poetry.lock.
Так ведь и pip freeze делает то же самое — замораживает текущие установленные версии пакетов. Этого достаточно для того, чтобы воспроизвести окружение позже.
Другое дело, что в замороженный requirements попадают и зависимости, и зависимости зависимостей вперемешку, что может приводить к конфликтам в будущем, если список этих-самых зависимостей у какого-нибудь пакета изменится, однако на практике лично мне это никогда не мешало — достаточно просто держать отдельно requirements.txt со списком "зависимостей первого уровня" и requirements.freeze.txt для воспроизводимого окружения.
Через трёхэтажный мастер импорта Data -> External Data -> From Text?
В последний раз когда я под русской Windows двойным кликом пытался открыть CSV в кодировке UTF-8, Excel 2016 открывал его с крокозябрами, считая, что файл в CP1251. На Stackoverflow тогда предлагали использовать костыль — сохранять csv для экселя в кодировке UTF-8 with BOM. Это почти работало, за исключением того, что при последующей попытке сохранить такой csv открывался диалог «Сохранить как» с предложением сохранить в новый файл в формате «Текст Юникод (*.txt)» (а при использовании «Отправить по электронной почте» — просто молча отправлял вместо CSV txt-файл с непонятными разделителями).
Как же достала эта мода с выбором из двух аля «прямо сейчас/спросить позже».
Если onion-адрес нельзя запомнить, то, очевидно, нельзя доверять предложению перейти по адресу, который не помнишь. Ведь теперь это запросто может быть результатом взлома, который владелец ресурса может даже не замечать — вроде того, когда в .htaccess добавляют редирект для посетителей, приходящих из поисковика. И это предложение пойти на другой сайт будет сдобрено плашкой «более безопасный». Ужс.
Из недавнего ещё: ESR — сооснователя и президента OSI — забанили в списке рассылки OSI, где всерьёз обсуждалась абсурдная возможность внедрения в open source лицензии пунктов, запрещающих использование софта определённым "плохим" людям и организациям.
http://esr.ibiblio.org/?p=8609
Дыра Хокинга, простигосподи.
TikTok скорее клон Vine (который в своё время всех настолько достал, что к публикуемым в интернете роликам стали дописывать "NOT VINE"), в рекламу которого вкачали ещё больше денег.
Есть "болванка", "чурка", есть "работа" с корнем "раб", есть "раб Божий" в одной фантастической книге. Почему у нас на это не оскорбляются?
А я бы с удовольствием продаунгрейдился до SVGA и шрифтов, прибитых к пиксельной сетке. Вполне себе ничё так было :)
Во-первых, как «blacklist», так и «whitelist» — списки исключений. Например, в каком-нибудь условном адблоке адреса из белого списка являются исключениями из общих правил блокировки, не должны проверяться регулярками и пролетать насквозь. И точно также адреса из чёрного списка являются исключениями из общих правил — они тоже не должны проверяться, а сразу блокироваться. Уже здесь назревает путаница, потому что в новой терминологии теперь есть свои «исключения» — «exclude»! А «include» рядом ещё и создаёт впечатление, что для того, чтобы с объектом было проведено какое-то действие, он должен быть «включён» в список «includelist», а это не так.
Во-вторых, разные проекты заменяют «неполиткорректные» старые термины разными новыми. Где-то это «blocklist», где-то «stoplist», где-то «excludelist», где-то просто «exclude». Такая фрагментация только добавит проблем.
В-третьих, новые термины ещё и весьма неоднозначные — например в xdebug теперь есть XDEBUG_PATH_INCLUDE. Это что — путь, по которому что-то лежит? Как CPLUS_INCLUDE_PATH? Нет. А читается именно так.
Эту дичь следует остановить немедленно. Я уверен, что людей, которые не одобряют такие изменения, достаточно, однако всеобщее внедрение в проектах «кодексов поведения» приводит к тому, что они даже боятся высказаться против, потому что «Расист! Расист!». Наблюдаем ru.wikipedia.org/wiki/Спираль_молчания во всей красе.
Так ведь и pip freeze делает то же самое — замораживает текущие установленные версии пакетов. Этого достаточно для того, чтобы воспроизвести окружение позже.
Другое дело, что в замороженный requirements попадают и зависимости, и зависимости зависимостей вперемешку, что может приводить к конфликтам в будущем, если список этих-самых зависимостей у какого-нибудь пакета изменится, однако на практике лично мне это никогда не мешало — достаточно просто держать отдельно requirements.txt со списком "зависимостей первого уровня" и requirements.freeze.txt для воспроизводимого окружения.
Это слишком просто
сарказм
В тик-ток какой-нибудь, да мало ли какую фигню ещё через месяц придумают.
В последний раз когда я под русской Windows двойным кликом пытался открыть CSV в кодировке UTF-8, Excel 2016 открывал его с крокозябрами, считая, что файл в CP1251. На Stackoverflow тогда предлагали использовать костыль — сохранять csv для экселя в кодировке UTF-8 with BOM. Это почти работало, за исключением того, что при последующей попытке сохранить такой csv открывался диалог «Сохранить как» с предложением сохранить в новый файл в формате «Текст Юникод (*.txt)» (а при использовании «Отправить по электронной почте» — просто молча отправлял вместо CSV txt-файл с непонятными разделителями).
Сейчас на support.microsoft.com/en-us/office/excel-formatting-and-features-that-are-not-transferred-to-other-file-formats-8fdd91a3-792e-4aef-a5bb-46f603d0e585#bm4 всё ещё есть вот такое смешное замечание:
Если onion-адрес нельзя запомнить, то, очевидно, нельзя доверять предложению перейти по адресу, который не помнишь. Ведь теперь это запросто может быть результатом взлома, который владелец ресурса может даже не замечать — вроде того, когда в .htaccess добавляют редирект для посетителей, приходящих из поисковика. И это предложение пойти на другой сайт будет сдобрено плашкой «более безопасный». Ужс.