Торренты можно искать, например, здесь, а также здесь, здесь и здесь. Вот хорошая, годная статья о том, как/где еще можно искать и качать редкий и малопопулярный контент.
На мой вкус получается довольно лаконично и очень быстро. Не надо страдать и искать какой-нибудь туториал по cmake чтобы сделать какую-то тривиальную вещь
Спасибо за статью (держите плюс), но по личному опыту Bazel это какое-то monstrous over-engineered нечто, к тому же написанное на джаве, разобраться в котором неподготовленному человеку едва ли получится не то что без парочки-другой туториалов, а и пол-литры. Я не большой фанат симейка, но для работы с ним в подавляющем большинстве случаев достаточно лишь документации.
Когда сталкиваюсь с проектом на базельке, первое желание — переписать всю эту магию неявную машинерию на обычные мейк-файлы. :-)
О, как интересно! Спасибо, поковыряю на досуге и, не ровён час, переведу фрёвый порт на ваш форк. Надеюсь, что рано или поздно возможность сборки с ванильным OpenSSL появится и в апстриме.
Меня особенно удивило, когда они внезапно стали требовать авторизацию при попытке просто воспользоваться их поиском (!) через обычный десктопный браузер из некоторых стран. Ну то есть, в каком-нибудь Китае Google не работает из-за цензуры государственной, а Яндекс — из-за цензуры собственной. Слава богу, вроде бы одумались (впрочем, актуальный список стран надо бы уточнить).
Envoy распространяется в бинарниках только как docker образ.
Более того, разработчики прямо говорят: собирать самостоятельно, мол, не советуем, ставьте через докер, а ведь это подходит далеко не всем. Я когда-то хотел заиспользовать Envoy в одном проекте на работе в качестве умного балансера, но оттолкнули его аццкая система сборки (для фрёвого порта я всё это безобразие переписал на обычный make) и жесткая зависимость от BoringSSL (из него вообще уши гугловых методологий разработки торчат довольно сильно). Ну и конфигурируется он действительно нетривиально.
Чем вы мотивируете обычного пользователя перейти на телеграмм?
Есть достаточно старый, но исчерпывающий список преимуществ Телеграма перед конкурентами. Впрочем, я пользуюсь им в первую очередь потому, что клиент открытый и нативный (на Qt), но тут правда ваша — почему-то негикам на такие вещи пофиг. :-(
Допустимый максимум — сначала написать стопицот хвалеб, а потом I would suggest reconsidering what would happen if this function gets a negative number as the input, условно.
Вот да, дико бесит, когда вместо того, чтобы просто написать как встарь, мол, сорян, но твой код говно ломает нам билд, народ пишет что-то типа «Thanks so very much for doing this! Glad to see this effort taking place! Your commit is awesome but could you please take another look as unfortunately it breaks the build? Keep up the good work :) Cheers!» (реальное письмо из рассылки, я лишь незначительно подсократил для удобочитаемости).
Или там в гитхабе толерастия сплошная, терпение к убогим т.е., и за такой даже вежливый посыл будут репрессии? Какая-то нездоровая ситуация.
Именно так, и не только на гитхабе, а вообще в современном IT. За последние 10-15 лет радикально поменялись стандарты общения, уровень терпимости к критике, требования к формулировкам и вообще понятия «что такое хорошо и что такое плохо».
Раньше людей волновали в первую очередь код и его качество. На мелочи типа недостаточно почтительного обращения или lack of showering one with sunshine, rainbows, and ponies никто не обращал внимания, потому что how you feel is unimportant (здесь должна быть ссылка на undeadly.org, но хабрапарсер её упорно портил; нормальная есть в моём старом комментарии). Такой была олдскульная этика.
С тех пор ситуация изменилась: нынче можно обидеться на точку в конце сообщения или любое слово с негативной коннотацией, в проекте легко может быть запрещено исследовать историю коммитов в попытке найти автора, а за can вместо could с вами могут перестать общаться.
Несколько лет назад Скотт Адамс (автор комиксов про Дилберта, если кто не знает) писал у себя в блоге об одном любопытном отличии ньюйоркцев от калифорнийцев:
New Yorkers tend to say whatever they think is true to whoever is standing nearby. Not much filter. Californians say what they think will make you feel good. The California way would feel like lying if it were not so well-meaning. [… Bluntness, honesty, some risk-taking --] that's how the New York style works. At first you hate it because it seems so harsh. In time you start to appreciate the honesty.
Раньше в IT ценились честность и искреннее желание сделать код или документацию лучше. Теперь это не так важно, лишь бы никого не обидеть (вернее, не дать лишнего повода кому-то обидеться).
Ну этот холивар длится уже не первый год. Есть и там, и там, плюсы и минусы.
Этот холивар закончился пора было закончить с появлением ZFS. В 2019 г. нет ни одной веской причины связываться с аппаратными контроллерами, писанными левой ногой темными индийскими ночами проприетарными прошивками и прочими сопутствующими «радостями». Какое же счастье, что весь этот ад остался в прошлом.
Машина нарушила правила игры? Насколько нам известно — нет.
Проблема не в том, что не нарушила (нет), а в том, что ИИ по сути играет в некую другую игру, похожую на оригинал только внешне. В шахматах или го этой проблемы нет (на мой дилетантский взгляд, или же она не настолько выражена); в квейке, старкрафте или доте есть собственно game и т.н. metagame. Люди учатся играть в первую, достигают потолка скилла и переходят на следующий уровень (именно противостояние на нем отличает топовых игроков и делает киберспортивные игры такими интересными). ИИ же не переходит на него, т.к. ему это просто не требуется, когда соперника можно тупо «перекликать», — микро-стратегии оказываются более эффективными при их точном выполнении, as disappointing as that sounds.
Я ещё с утра подумал, почему торренты стали работать без прокси.
Погодите, а разве их когда-то блокировали в России? Сколько ни качаю-раздаю, всё напрямую работает (Питер, Ростелеком). Другое дело, что заблокированы многие трекеры и поисковики, но для 99% не-private торрентов знания info-хэша (btih, который рано или поздно просочится в DHT) вполне достаточно, а они щедро разбросаны по зеркалам/кэшам и проиндексированы поисковиками.
У меня вопрос: что лучше — блокировать такие аморальные сайты, и блокировать политическую рекламу и съезды, или ничего не блокировать и оставить возможность аморальным людям писать аморальные вещи?
Ничего не блокировать, разумеется. Свобода слова она такая, бывает либо для всех, либо для никого. Иначе очень легко стать на скользкую дорожку и не заметить, как «аморальным» внезапно может быть чуть менее, чем всё. Это примерно как с пытками.
Кроме того, на [ноутбучных] клавиатурах может быть много комбинаций, которые вообще обрабатываются только контроллером, — управление подсветкой и всякое такое.
К сожалению, времена хардварных комбинаций, во всяком случае если говорить о ноутбуках, боюсь, давно и безвозвратно прошли: теперь они обрабатываются WMI-драйвером (вернее, там их целый стек), которые вендор-специфичные и в каких-то ОС (более популярных) поддерживаются хорошо, в других — хуже или вовсе плохо; иногда они не работают как надо, и приходится что-то там патчить, в общем, такое.
Ой, простите, это вопрос к akhalat, конечно же.
Так всё-таки, можно конкретный пример, кого вымар(ыв)али из IMDb, хотя бы один? Просто странно получается, Гибсона вы называете по имени, но главный герой вашего комментария выше — некий «один актёр».
хорошей практикой является указание в комментарии к коммиту номера задачи из багтрекера
Конечно, если коммит имеет отношение к какому-то тикету, номер тикета надо указывать, и это-то обычно не забывают делать. Но коммит не обязательно должен закрывать какой-то известный баг или реализовывать запланированную фичу; кроме того, если на каждый коммит надо глядеть в багзиллу и продираться через портянки комментариев, работать с таким кодом (заниматься археологией) становится очень тяжело.
дублировать эту информацию ещё и в коммит кажется несколько избыточным
Репозиторий — штука вполне самодостаточная, и не стоит гвоздями прибивать к нему багтрекер вместо того, чтобы просто писать нормальные логи. :-)
поэтому обычно в описании к коммиту приводится только то что было изменено в данном конкретном коммите
Что было изменено понятно и из диффа, зачем же дифф тупо переводить на английский? Хороший лог должен объяснять, почему были сделаны изменения, причем так, чтобы было понятно и без контекста, годы спустя. Собственно, за этим когда-то и придумали правило-совет про 30%-what-70%-why.
Впрочем, это всё в большей степени касается крупных, «долгих» опенсорсных проектов; в случае закрытой коммерческой разработки, где другие приоритеты и циклы жизни кода значительно короче, качество коммит-логов, наверное, не столь важно.
С принтерами — как было, так и есть — по списку. И даже те, что из списка, работают через раз.
Охотно верю, что с принтерами и прочими бумагопоедающими SOHO-устройствами у фрюниксов до сих пор есть проблемы (опять же — пусть не в лоб, но скорее всего решаемые). Зато, например, когда компания HP прекратила выпускать драйвера для своих старых, но очень популярных лазерджетов тысячных серий, народ взвыл и как только не изголялся, вплоть до virtualbox + ubuntu + cups (хотя чаще всего обычно ставили WinXP в виртуалке). Юниксоиды же, глядя на это, пожимают плечами и просто настраивают cups или lpd без оглядки на поддержку вендора.
… и при этом надежно хранить на нем данные — как раз то, за что любят ZFS.
Когда сталкиваюсь с проектом на базельке, первое желание — переписать всю эту
магиюнеявную машинерию на обычные мейк-файлы. :-)говноломает нам билд, народ пишет что-то типа «Thanks so very much for doing this! Glad to see this effort taking place! Your commit is awesome but could you please take another look as unfortunately it breaks the build? Keep up the good work :) Cheers!» (реальное письмо из рассылки, я лишь незначительно подсократил для удобочитаемости).Раньше людей волновали в первую очередь код и его качество. На мелочи типа недостаточно почтительного обращения или lack of showering one with sunshine, rainbows, and ponies никто не обращал внимания, потому что how you feel is unimportant (здесь должна быть ссылка на undeadly.org, но хабрапарсер её упорно портил; нормальная есть в моём старом комментарии). Такой была олдскульная этика.
С тех пор ситуация изменилась: нынче можно обидеться на точку в конце сообщения или любое слово с негативной коннотацией, в проекте легко может быть запрещено исследовать историю коммитов в попытке найти автора, а за can вместо could с вами могут перестать общаться.
Несколько лет назад Скотт Адамс (автор комиксов про Дилберта, если кто не знает) писал у себя в блоге об одном любопытном отличии ньюйоркцев от калифорнийцев:
Раньше в IT ценились честность и искреннее желание сделать код или документацию лучше. Теперь это не так важно, лишь бы никого не обидеть (вернее, не дать лишнего повода кому-то обидеться).
закончилсяпора было закончить с появлением ZFS. В 2019 г. нет ни одной веской причины связываться с аппаратными контроллерами, писанными левой ногой темными индийскими ночами проприетарными прошивками и прочими сопутствующими «радостями». Какое же счастье, что весь этот ад остался в прошлом.Таки от легитимации пыток и цензуры.
Так всё-таки, можно конкретный пример, кого вымар(ыв)али из IMDb, хотя бы один? Просто странно получается, Гибсона вы называете по имени, но главный герой вашего комментария выше — некий «один актёр».
Репозиторий — штука вполне самодостаточная, и не стоит гвоздями прибивать к нему багтрекер вместо того, чтобы просто писать нормальные логи. :-)
Что было изменено понятно и из диффа, зачем же дифф тупо переводить на английский? Хороший лог должен объяснять, почему были сделаны изменения, причем так, чтобы было понятно и без контекста, годы спустя. Собственно, за этим когда-то и придумали правило-совет про 30%-what-70%-why.
Впрочем, это всё в большей степени касается крупных, «долгих» опенсорсных проектов; в случае закрытой коммерческой разработки, где другие приоритеты и циклы жизни кода значительно короче, качество коммит-логов, наверное, не столь важно.