Где-то читал (сейчас точно не найду источник), что предел прочности на разрыв имеющихся материалов всё портит.
Супермаховик это ведь не сплошной диск, вращающийся в вакууме, потому что сплошные порвёт, из чего ни делай — физика. Это скорее катушка из сверхпрочных волокон, хитрым способом привязанная к оси спицами, примерно как велосипедное колесо. Так вот спицы из современных материалов тоже рано или поздно рвутся. И единственный материал, который теоретически подходит под такие нагрузки — это углеродные нанотрубки. Но их пока не научились получать нужной длины, и тем более пока непонятно, как свить из них трос. Если научатся, тогда, возможно, что-то и выйдет.
Верно. О том, что там внутри (если это «внутри» вообще имеет смысл) нельзя иметь представления, потому как никакая информация чёрную дыру не покидает по определению.
Но так как мы наблюдаем ЧД (точнее, некоторые феномены, ведущие себя как ЧД по косвенным параметрам — непосредственно их наблюдать нельзя) снаружи, можем для описания того, что наблюдаем, пользоваться здешней физикой, и в нашей системе отсчёта у каждого них есть и объём, и масса, и, следовательно, средняя плотность.
Размер горизонта чёрной дыры в простейшем приближении зависит только от её массы, и при этом растёт линейно. А это значит, что у сверхмассивных чёрных дыр средняя плотность (т.е. отношение массы к объёму, который под горизонтом) может быть сколь угодно малой. Вот у той, что в центре нашей галактики, она по всей видимости меньше плотности воздуха.
Да, именно с самими принципами проблема. Вот какая сейчас есть научно обоснованная и подтверждённая теоретическая основа для искусственной гравитации/антигравитации? Никакой. Возможно, когда-нибудь смогут создать теорию, которая будет включать в себя текущую Стандартную модель как крайний случай, и в то же время разрешит и такие феномены. Но пока — увы, её нет.
+ Силовые поля и прочий hard light.
+ Искусственная гравитация.
+ Перенос сознания с wetware на hardware.
+ Digistruct-материализация предметов из ничего по «цифровому шаблону».
Это из самого частого, что постоянно появляется в фантастическом кино и играх. И всё на текущий момент остаётся недостижимым, а то и в принципе невозможным.
Вот так номер. У меня ведь было аж две таких мыши A4Tech с двумя колёсиками — и помнится, что они действительно вели себя под линухом весьма нехорошо. Впрочем, обе давно уже умерли от старости и износа, прежде чем дождались таки поддержки в ядре…
У меня стандартный при каждом обновлении через windows update автоматически заменяется на фирменный :\ даже если ставлю в настройках флажок, чтобы не обновлял. Не знаю зачем. Так что проще оказалось вырубить memory integrity.
Основной драйвер режима ядра да, перезагружает. Но не вспомогательный user mode driver, который как раз и отваливатся, — а в котором из кучи нвидиевских процессов он живёт, я так и не нашёл. Так что только перелогин, увы.
В 1803 добавилось проблем с драйверами. Теперь по умолчанию включены всякие memory integrity и прочие новомодные защитные вещи в свете программных заплаток от процессорных багов, а некоторые производители злостно забивают на поддержку старых дивайсов. Особенно Logitech и Samsung. Уроки Vista их не научили :(
Если у вас тоже отвалилась вебкамера, попробуйте проставить в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity — Enabled=0 и перезагрузиться.
Ещё после восстановления из гибернации периодически перестаёт инициализироваться D3D контекст на некоторых видюхах NVidia — какая-то дурная проблема с user mode driver в текущей сессии, который корректно не переинициализируется. В этом случае помогает перелогин, а нормального решения пока нет.
Безотносительно остальных аргументов, уже давненько заметен тренд на тёмные по умолчанию интерфейсы в дизайнерских инструментах, везде, где надо сделать акцент на контент, а интерфейс увести в фон. Графические редакторы, 3d, аудио — все тёмные после установки. Но обычно тему можно поменять на светлую.
Среды разработки и офисный софт обычно тоже имеет такую опцию, но это опять же инструменты из разряда productivity, в которых пользователи просиживают часами. Для приложений вне этой категории воообще-то особенной разницы нет, тёмный UI или светлый. Идеально, если программа будет следовать настройкам выставленной в системе темы, и не выпендриваться.
По мнению представителя Роскомнадзора, Telegram «прячется за живой щит из подсетей крупных транснациональных компаний и конкретных ресурсов, которые находятся с ним в одном хостинге».
Перевожу на русский: «мы до сих пор не понимаем, как у провайдеров облачных сервисов работает динамическое выделение адресов виртуальным машинам клиентов из имеющегося пула».
Блокировка же отдельных адресов производится лишь после того, как ведомство убеждается в том, что «там нет иных ресурсов».
«Ресурс — это то, что доступно по HTTP, а других протоколов по нашему мнению в интернете не существует.»
На самом деле скорее всего всё это они понимают, но коли уж велено непущать и запрещать, то обратной дороги нет. Печально это.
1) Я юзал и GHE, и ББ, когда он ещё назывался Stash. Как-то сумел обойтись без плагинов в обоих случаях. Максимум тупенький скрипт на крон вешал, чтобы дёргать через штатный REST targeted builds (+deployments) по различным токенам в комментах. Интегрировался не с Дженкинсом, а с Тимсити, но это в целом без разницы.
2) Править надо в рамках одного коммита. Любое изменение должно быть атомарное, и это догма, нарушать нельзя. Разработчик правит разметку — значит он автоматически обязан поправить и тест ДО того как тот упадёт на CI. А если вы оторвали тесты от кода (и уж тем более разнесли по разным репозиториям и отдали их разным людям) — у меня для вас опять плохие новости. Так нельзя делать, потому что это ересьвыстрел в ногу. В обе ноги.
3) Ваш проект не уникален, даже если вам так кажется. И уж тем более не является чем-то исключительным по меркам индустрии (потому что таких вообще нет, всё украдено задолго до нас). Вполне можно юзать опыт товарищей из действительно промышленных контор, которые собаку на этом съели. Вот что Мозилла, что Майкрософт весьма подробно описывают в блогах, как они рулят своими проектами. Просто нужно потратить немного (вру, довольно много) времени, чтобы правильно врубиться. Синдром NIH опасен, он хоронит проекты. Я это видел вживую и даже участвовал пару раз. С тех пор учусь на чужих ошибках, а то на своих слишком дорого.
4) Эт у вас прозвучало как-то совсем не смешно :/
5) Нет ничего проще, чем уволить плохого разработчика. Но, скорее всего, он сам уйдёт после третьего подряд разгромного ревью кода, особенно если провести таковое в присутствии коллег. Либо ему придётся браться за ум и расти до уровня старших товарищей. И таковые должны не сидеть в своём углу и делать что-то непонятное, а общаться с остальными на постоянной основе, и задавать некий правильный тон в коллективе. Это отнимает время и стоит дорого, но оно в самом деле того стоит.
Насчёт оценок. Ну… я имею наглость считать себя экспертом (почти два десятка лет код пишу всё-таки, вдобавок, ещё и читаю в гораздо больших объёмах, чем пишу), поэтому очень субъективен, крайне пристрастен, и исхожу из эстетических критериев. Качественный код с моей точки зрения выглядит прилично, опрятен, прост, минималистичен, бездушен, полностью лишён индивидуальных черт, и какого-либо влияния автора. Написан с расчётом на то, чтобы его в любой момент можно было отдать любому другому члену команды. Желательно, делает ровно то, что написано в ТЗ. И если я, глядя на экран кода, не могу понять за пять минут, как он это делает, я его скорее всего заверну. Также меня мало волнует производительность разработчика в строках за день (потому что это вообще не показатель), меня волнует, чтобы фича была реализована корректно. А сколько итераций она пройдёт в процессе — вопрос для отдельного согласования. Как-то так.
Во-первых, знатно навелосипедили там, где вполне можно было обойтись стандартным набором функций. (Я, конечно, максимум на 40 человек процесс CI/CD масштабировал, но не думаю, что проект на всего в три раза большую команду как-то сильно сложнее в этом плане.)
Также, не стоит продвигать плохие практики. Для «зависимых» PR в разных репозиториях обычно поддерживают версионность API и обратно совместимые протоколы. Это нормально, а вот то что вы делаете — это какая-то дичь.
Наконец, если одной из решаемых проблем является «кумовство», то у меня плохие новости. Проблемы подобного рода нельзя в принципе решать техническими средствами, только административными регламентами, и повышением общей культуры разработки. Есть такая штука как «мотивация», например. И если разработчик не отвечает за качество кода перед собственной совестью прежде всего, то это плохой разработчик, его надо увольнять, а не обвешивать PR кнопочками.
Публичный IPv4-адрес штука ныне дефицитная, поэтому иметь для каждого виртуального экземпляра таковой на постоянной основе, работает он сейчас или нет, большая роскошь — и стоит денег (более того, в любом дата-центре Амазона постоянных адресов тебе дают всего 5 штук, и увеличивают этот лимит ну с очень большим скрипом).
Это один из тех моментов, которые не продуманы от слова совсем. Сейчас в блоклисте несколько тысяч доменных имён, которые доступны для регистрации кому угодно. И ими вполне можно так злоупотребить. Другое дело, что большая часть таких доменов в зоне .ru, и регистраторы могут самостоятельно вести какой-то свой реестр и отказывать в делегации. Вероятно, такая практика имеет место.
Да легко. Инстанс поднимается, и сразу пишет свой IP в базу, например, как часть скрипта разморозки. Откуда её и читает балансер. А когда инстанс дохнет, балансер может это прочухать периодическим опросом, например, и вынести запись из базы.
Мы не знаем подробностей, но звучит вся эта история так, как будто Зелло выпросило себе много Elastic IP и постоянно по ним скакало. Это на самом деле свинство.
Сначала клиент обращается к сервису-трамплину, который отвечает адресом свободного сервера, и потом уже идёт туда. А адреса трамплинов Телеграм шлёт через системные пуш-уведомления.
DNS устроен так, что можно сопоставить сколько угодно IP-адресов одному и тому же доменному имени. Браузер обратится к случайному из указанных, а в следующий раз к какому-то другому.
Супермаховик это ведь не сплошной диск, вращающийся в вакууме, потому что сплошные порвёт, из чего ни делай — физика. Это скорее катушка из сверхпрочных волокон, хитрым способом привязанная к оси спицами, примерно как велосипедное колесо. Так вот спицы из современных материалов тоже рано или поздно рвутся. И единственный материал, который теоретически подходит под такие нагрузки — это углеродные нанотрубки. Но их пока не научились получать нужной длины, и тем более пока непонятно, как свить из них трос. Если научатся, тогда, возможно, что-то и выйдет.
Но так как мы наблюдаем ЧД (точнее, некоторые феномены, ведущие себя как ЧД по косвенным параметрам — непосредственно их наблюдать нельзя) снаружи, можем для описания того, что наблюдаем, пользоваться здешней физикой, и в нашей системе отсчёта у каждого них есть и объём, и масса, и, следовательно, средняя плотность.
Размер горизонта чёрной дыры в простейшем приближении зависит только от её массы, и при этом растёт линейно. А это значит, что у сверхмассивных чёрных дыр средняя плотность (т.е. отношение массы к объёму, который под горизонтом) может быть сколь угодно малой. Вот у той, что в центре нашей галактики, она по всей видимости меньше плотности воздуха.
+ Искусственная гравитация.
+ Перенос сознания с wetware на hardware.
+ Digistruct-материализация предметов из ничего по «цифровому шаблону».
Это из самого частого, что постоянно появляется в фантастическом кино и играх. И всё на текущий момент остаётся недостижимым, а то и в принципе невозможным.
Если у вас тоже отвалилась вебкамера, попробуйте проставить в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity — Enabled=0 и перезагрузиться.
Ещё после восстановления из гибернации периодически перестаёт инициализироваться D3D контекст на некоторых видюхах NVidia — какая-то дурная проблема с user mode driver в текущей сессии, который корректно не переинициализируется. В этом случае помогает перелогин, а нормального решения пока нет.
Среды разработки и офисный софт обычно тоже имеет такую опцию, но это опять же инструменты из разряда productivity, в которых пользователи просиживают часами. Для приложений вне этой категории воообще-то особенной разницы нет, тёмный UI или светлый. Идеально, если программа будет следовать настройкам выставленной в системе темы, и не выпендриваться.
Перевожу на русский: «мы до сих пор не понимаем, как у провайдеров облачных сервисов работает динамическое выделение адресов виртуальным машинам клиентов из имеющегося пула».
«Ресурс — это то, что доступно по HTTP, а других протоколов по нашему мнению в интернете не существует.»
На самом деле скорее всего всё это они понимают, но коли уж велено непущать и запрещать, то обратной дороги нет. Печально это.
2) Править надо в рамках одного коммита. Любое изменение должно быть атомарное, и это догма, нарушать нельзя. Разработчик правит разметку — значит он автоматически обязан поправить и тест ДО того как тот упадёт на CI. А если вы оторвали тесты от кода (и уж тем более разнесли по разным репозиториям и отдали их разным людям) — у меня для вас опять плохие новости. Так нельзя делать, потому что это
ересьвыстрел в ногу. В обе ноги.3) Ваш проект не уникален, даже если вам так кажется. И уж тем более не является чем-то исключительным по меркам индустрии (потому что таких вообще нет, всё украдено задолго до нас). Вполне можно юзать опыт товарищей из действительно промышленных контор, которые собаку на этом съели. Вот что Мозилла, что Майкрософт весьма подробно описывают в блогах, как они рулят своими проектами. Просто нужно потратить немного (вру, довольно много) времени, чтобы правильно врубиться. Синдром NIH опасен, он хоронит проекты. Я это видел вживую и даже участвовал пару раз. С тех пор учусь на чужих ошибках, а то на своих слишком дорого.
4) Эт у вас прозвучало как-то совсем не смешно :/
5) Нет ничего проще, чем уволить плохого разработчика. Но, скорее всего, он сам уйдёт после третьего подряд разгромного ревью кода, особенно если провести таковое в присутствии коллег. Либо ему придётся браться за ум и расти до уровня старших товарищей. И таковые должны не сидеть в своём углу и делать что-то непонятное, а общаться с остальными на постоянной основе, и задавать некий правильный тон в коллективе. Это отнимает время и стоит дорого, но оно в самом деле того стоит.
Насчёт оценок. Ну… я имею наглость считать себя экспертом (почти два десятка лет код пишу всё-таки, вдобавок, ещё и читаю в гораздо больших объёмах, чем пишу), поэтому очень субъективен, крайне пристрастен, и исхожу из эстетических критериев. Качественный код с моей точки зрения выглядит прилично, опрятен, прост, минималистичен, бездушен, полностью лишён индивидуальных черт, и какого-либо влияния автора. Написан с расчётом на то, чтобы его в любой момент можно было отдать любому другому члену команды. Желательно, делает ровно то, что написано в ТЗ. И если я, глядя на экран кода, не могу понять за пять минут, как он это делает, я его скорее всего заверну. Также меня мало волнует производительность разработчика в строках за день (потому что это вообще не показатель), меня волнует, чтобы фича была реализована корректно. А сколько итераций она пройдёт в процессе — вопрос для отдельного согласования. Как-то так.
Во-первых, знатно навелосипедили там, где вполне можно было обойтись стандартным набором функций. (Я, конечно, максимум на 40 человек процесс CI/CD масштабировал, но не думаю, что проект на всего в три раза большую команду как-то сильно сложнее в этом плане.)
Также, не стоит продвигать плохие практики. Для «зависимых» PR в разных репозиториях обычно поддерживают версионность API и обратно совместимые протоколы. Это нормально, а вот то что вы делаете — это какая-то дичь.
Наконец, если одной из решаемых проблем является «кумовство», то у меня плохие новости. Проблемы подобного рода нельзя в принципе решать техническими средствами, только административными регламентами, и повышением общей культуры разработки. Есть такая штука как «мотивация», например. И если разработчик не отвечает за качество кода перед собственной совестью прежде всего, то это плохой разработчик, его надо увольнять, а не обвешивать PR кнопочками.
— это я как раз про Elastic IP говорю.
DNS устроен так, что можно сопоставить сколько угодно IP-адресов одному и тому же доменному имени. Браузер обратится к случайному из указанных, а в следующий раз к какому-то другому.