Тут в описании пропущено существенное, согласен. Сначала надо найти точку посредине проезжей части улицы, к которой данный объект (наиболее важное место его доступ, типа крыльца или ворот, если нет - то самая выделяющаяся) ближе всего, затем считается расстояние от этой точки до начала улицы (плюс какая-то константа, заданная в паспорте этой улицы), и наконец расстояние проецируется на пространство номеров (например, делится на 10 метров и дальше округляется до ближайшего чётного или нечётного номера, согласно стороне). Погрешность в несколько метров и пару процентов несущественна, пока нет нумерованных в обратном порядке. В случае, если несколько объектов получили бы один номер, добавляем буквы, как сейчас принято.
А это неважно. Главное, чтобы номера были не меньше, если какой-то запас и нумерация начинается, например, с 19 и 20 - не страшно, у нас целых чисел на всех хватит.
Удлинение улицы с её формального начала - редчайший случай. Скорее в таком случае кусок называют другим именем. Укорачивание ничего не меняет. Разрыв - тоже. В предполагаемом варианте я допускаю добавление константы к номерам, общей на всех, поэтому если улица начнётся с номеров 251/252 - ничего плохого, если дальше будет увеличение по расстоянию.
В любом случае это лучше того бардака, что сейчас почти везде.
Ничего из описанного вами не является причиной для падений. Кстати, аддонов у меня там нету.
Аналогичные периоды падений были и раньше, как-то прекращались. Видимо, метод тестирования на живых пользователях разработчикам хрома нравится не меньше, чем мелкомягким.
Хром активно развивается и поддерживает функционал на любой случай жизни, хотелось бы аргументированных претензий в его адрес.
Неудобный и ограниченный UI. Например, я хочу вертикальный список табов, на хроме такого не сделать. FF не даёт выключать нафиг не нужный в этом случае свой родной список, но хотя бы даёт добавлять. Или вот переход между последними табами по Ctrl+Tab, FF сделал несколько лет назад, в хроме нет, для моего удобства это почти критически важно. Тут можно долго перечислять. (К сожалению, Firefox пошагово движется в сторону хрома, принимая самые тупые решения. Но хотя бы делает это с отставанием на несколько лет и не во всём.)
Прожорливость, особенно по процессору. (Спорный момент, некоторые утверждают про наоборот, но у меня почему-то хром жрёт в разы больше лисы.)
Профили - хочу запускать и приостанавливать их раздельными процессами.
Поэтому смотрю в хроме только всякие google meet или linkedin (который не всегда, но очень регулярно хочет чего-то такого, чего нет в FF).
Про шифрование уже сказали, добавлю: я доверяю механизмам с master password, который я назначаю сам, но не когда оно основывается на ХЗ чём в плане шифрования паролей.
Демонстрируешь свою тушку железке, она ее параметры запоминает. В следующий раз демонстрируешь - она понимает, что ты это ты и отрывает ключики Passkey-ев
"Ваш вес не соответствует образцу. Предъявите настоящего владельца или похудейте взад"
"У владельца этого акаунта 2 ноги, а у вас только одна. Предъявите вторую ногу"
А всякие ФИО - смартфону, например, не нужны же, чтобы экран разблокировать. Вот и тут так же.
Переход от "что умеет" до "чем владеет", конечно, защищает - если владение сложно украсть. Но если его лишиться - то ой.
Pull request в Gerrit называется review, и функциональности для собственно сопровождения изменения больше, чем у GitHub даже сейчас. (Я не говорю про CI, там намеренно отдельный, а у GitHub, Gitlab, etc. встроенный. Но какой-нибудь Jenkins прикрутить не так сложно.) И редактирование пользователей есть. Причём это было ещё в ≈2013, когда я впервые увидел Gerrit. Вы, видимо, с чем-то попутали.
Вообще тут надо делить по признакам 1) наличия/отсутствия встроенного в тот же флакон CI, wiki и прочих, 2) удобства для тех, для кого Git или Hg это просто ещё одна централизованная VCS, только с несколькими центрами, а в остальном им лениво думать - и для тех, кто хочет максимальных возможностей по управлению контентом. GitHub как раз максимально работает для ленивых.
Ну вот вы описали в данном комментарии, всего в ~500 символов, как решать проблемы. Можно добавить примерно на столько же, что за проблемы. Вот и получается заметка на пол-экрана в духе "STM32KPTFH201stereo: эти [censored] переломали модули X, Y, Z, лечение: <вот оно>". Статья - в стиле как тут, с фото, вводной, как ваша шелезяка пишет "превед хаббръ" и прочее - не нужна. Минимум данных, для тех, кто в теме вообще, но не в данной проблеме. По крайней мере у меня в аналогичных случаях работало всегда.
А тема, что вы дали ссылку - в таком заметочном фонде заслуживает не одного файла, а минимум каталога, возможно, и с подкаталогами. Потому как инфы действительно дофига и самой разной.
Это при запуске mc в подходящем терминале и не через ssh и не через screen/tmux (которые тоже могут специфически транслировать коды). Есть масса случаев, когда эти условия не выполняются, поэтому в общем я на них не рассчитываю.
Я работал в книготорговле в конце 90-х, и впечатлений набрался надолго. Как раз закончился поток всего того, что накапливалось ранее. Лазарчук, Лукьяненко и 100500 прочих имён. И рывком наступила пустыня. Тогда начали активно искать "молодых талантливых авторов", даже сокращение придумали - МТА. Искали, с фонарями. Мало кого нашли. Это всё задолго до 2010-х, которые автор статьи считает точкой перелома. Не было там такого перелома, разве что совсем уже наступила пустыня.
Сейчас я регулярно захожу в книжные магазины. Иногда таки покупаю. Но подавляющее большинство того, что есть - аж никак не цепляет. Листаешь, спрашиваешь "нафига оно мне?" и ставишь обратно. Лучше даже сказать, что 99% того, что я вижу в типичном книжном это просто гадательная литература, какой бы ни был автор, жанр, направление - годится только на то чтобы открыть, найти аргумент за или против тому, что хотел сделать, и закрыть.
Автор статьи, вероятно, рассчитывает на формат, когда любая хоть сколько-то пошумевшая новинка покупалась всеми, кто хотел изобразить, что он "современный", "в теме" и пр. Но так уже давно не работает. И проблема не в неоплате авторов. Проблема в том, что у авторов нет, чем заинтересовать читателя, чтобы имело смысл перечитывать. Читатели уходят в другие форматы контента.
Ну и по вкусам:
Лично я рекомендую купить «Все, способные держать оружие...» — одну из лучших повестей в современной русской фантастике.
Если что, у меня ещё бумажная района 97-го года с обложкой в розовых тонах. Если говорить о её вставной части "Иное небо" - то тут согласен, только не в современной, а в позднесоветской. Но всё ВСДО целиком... нет нет и нет. Лазарчук отлично начинает, но сливает концовки в ноль, и про путешествия во времени надо писать так, чтобы не было по триста роялей в каждом кустике, чтобы была хоть какая-то логика. (Не он один такой...) И в ВСДО ещё какой-то намёк на связность, а вот в "Опоздавших к лету"... цитируя Хайнлайна, это такой же вариант эпилога, как "и тогда мальчик свалился с кровати и проснулся". Ну и вообще, это 80-е. Даже если не по фактическому написанию, по замыслу. Нового-то что будет? И откуда?
Роулинг создала мрачную антиутопию на современном материале, прикрыв её стандартной героической эпопеей - и именно в этом не промахнулась. На Линдгрен как-то не похоже.
Самая сложная часть тут, мне кажется, это первичная сортировка. В каком-то изделии типа холодильника может быть и несколько сортов стали (и не только стали, а и алюминия и пр.), а разбирать его - ручная дорогая работа. И уже после выплавки разбираться, "что это мы сварили и куда его применить"?
Если + или / не может значить ничего, кроме простого сложения-деления-итд двух примитивных типов, значительно легче следить за происходящим - что у этого нет побочных эффектов. Максимум, что есть, если, например, складываются или делятся два int64_t, int128_t на 32-битной платформе, и это сделано через функцию - но таких функций всего несколько на всю программу. А вот если они могут значить что угодно и надо следить за типами - это усложняет чтение, вплоть до потери следа.
Да, граница не абсолютна, но она есть. Я бы не допускал такое просто так без учёта, где именно что сложно потерять контекст.
Добавка к C таких возможностей C++, как пространства имён и модификаторы видимости членов классов, как раз очень бы помогла. А вот дальнейшее развитие - уже ХЗ, как уже говорили в комментариях, уже начиная с переопределения операторов, когда ты не знаешь, что сделает конкретный a+b, становится стрёмным. И виртуальные функции это уже где-то на грани, надо тщательно подумать, прежде чем допускать.
Тут в описании пропущено существенное, согласен. Сначала надо найти точку посредине проезжей части улицы, к которой данный объект (наиболее важное место его доступ, типа крыльца или ворот, если нет - то самая выделяющаяся) ближе всего, затем считается расстояние от этой точки до начала улицы (плюс какая-то константа, заданная в паспорте этой улицы), и наконец расстояние проецируется на пространство номеров (например, делится на 10 метров и дальше округляется до ближайшего чётного или нечётного номера, согласно стороне). Погрешность в несколько метров и пару процентов несущественна, пока нет нумерованных в обратном порядке. В случае, если несколько объектов получили бы один номер, добавляем буквы, как сейчас принято.
А это неважно. Главное, чтобы номера были не меньше, если какой-то запас и нумерация начинается, например, с 19 и 20 - не страшно, у нас целых чисел на всех хватит.
Удлинение улицы с её формального начала - редчайший случай. Скорее в таком случае кусок называют другим именем. Укорачивание ничего не меняет. Разрыв - тоже.
В предполагаемом варианте я допускаю добавление константы к номерам, общей на всех, поэтому если улица начнётся с номеров 251/252 - ничего плохого, если дальше будет увеличение по расстоянию.
В любом случае это лучше того бардака, что сейчас почти везде.
Хорошо бы этот вариант, как самый простой и надёжный, реализовать везде:)
Втекает == доходы
вытекает == расходы
Мне сложно представить себе, что для кого-то будет наоборот.
??? Не понимаю, как можно было так интерпретировать мои слова ???
Ничего из описанного вами не является причиной для падений. Кстати, аддонов у меня там нету.
Аналогичные периоды падений были и раньше, как-то прекращались. Видимо, метод тестирования на живых пользователях разработчикам хрома нравится не меньше, чем мелкомягким.
Насколько видно из публичных данных, как раз втекало бы в разы меньше. Вытекало бы меньше, да, но насколько - ХЗ.
А ещё хром стал что-то в последнее время у меня каждый день крэшиться, даже если ничего в нём не делаю. И вроде никаких необычных сайтов не открыто.
Да, anecdotal evidence, взгляд юзера (в вебе я юзер, не выше) и всё такое, но - такое "активно развивается" и приводит к альтернативам.
Неудобный и ограниченный UI. Например, я хочу вертикальный список табов, на хроме такого не сделать. FF не даёт выключать нафиг не нужный в этом случае свой родной список, но хотя бы даёт добавлять. Или вот переход между последними табами по Ctrl+Tab, FF сделал несколько лет назад, в хроме нет, для моего удобства это почти критически важно. Тут можно долго перечислять. (К сожалению, Firefox пошагово движется в сторону хрома, принимая самые тупые решения. Но хотя бы делает это с отставанием на несколько лет и не во всём.)
Прожорливость, особенно по процессору. (Спорный момент, некоторые утверждают про наоборот, но у меня почему-то хром жрёт в разы больше лисы.)
Профили - хочу запускать и приостанавливать их раздельными процессами.
Поэтому смотрю в хроме только всякие google meet или linkedin (который не всегда, но очень регулярно хочет чего-то такого, чего нет в FF).
Про шифрование уже сказали, добавлю: я доверяю механизмам с master password, который я назначаю сам, но не когда оно основывается на ХЗ чём в плане шифрования паролей.
"Ваш вес не соответствует образцу. Предъявите настоящего владельца или похудейте взад"
"У владельца этого акаунта 2 ноги, а у вас только одна. Предъявите вторую ногу"
Переход от "что умеет" до "чем владеет", конечно, защищает - если владение сложно украсть. Но если его лишиться - то ой.
Pull request в Gerrit называется review, и функциональности для собственно сопровождения изменения больше, чем у GitHub даже сейчас. (Я не говорю про CI, там намеренно отдельный, а у GitHub, Gitlab, etc. встроенный. Но какой-нибудь Jenkins прикрутить не так сложно.) И редактирование пользователей есть. Причём это было ещё в ≈2013, когда я впервые увидел Gerrit. Вы, видимо, с чем-то попутали.
Вообще тут надо делить по признакам 1) наличия/отсутствия встроенного в тот же флакон CI, wiki и прочих, 2) удобства для тех, для кого Git или Hg это просто ещё одна централизованная VCS, только с несколькими центрами, а в остальном им лениво думать - и для тех, кто хочет максимальных возможностей по управлению контентом. GitHub как раз максимально работает для ленивых.
Ну вот вы описали в данном комментарии, всего в ~500 символов, как решать проблемы. Можно добавить примерно на столько же, что за проблемы. Вот и получается заметка на пол-экрана в духе "STM32KPTFH201stereo: эти [censored] переломали модули X, Y, Z, лечение: <вот оно>".
Статья - в стиле как тут, с фото, вводной, как ваша шелезяка пишет "превед хаббръ" и прочее - не нужна. Минимум данных, для тех, кто в теме вообще, но не в данной проблеме.
По крайней мере у меня в аналогичных случаях работало всегда.
А тема, что вы дали ссылку - в таком заметочном фонде заслуживает не одного файла, а минимум каталога, возможно, и с подкаталогами. Потому как инфы действительно дофига и самой разной.
Это при запуске mc в подходящем терминале и не через ssh и не через screen/tmux (которые тоже могут специфически транслировать коды). Есть масса случаев, когда эти условия не выполняются, поэтому в общем я на них не рассчитываю.
Я работал в книготорговле в конце 90-х, и впечатлений набрался надолго. Как раз закончился поток всего того, что накапливалось ранее. Лазарчук, Лукьяненко и 100500 прочих имён. И рывком наступила пустыня. Тогда начали активно искать "молодых талантливых авторов", даже сокращение придумали - МТА. Искали, с фонарями. Мало кого нашли. Это всё задолго до 2010-х, которые автор статьи считает точкой перелома. Не было там такого перелома, разве что совсем уже наступила пустыня.
Сейчас я регулярно захожу в книжные магазины. Иногда таки покупаю. Но подавляющее большинство того, что есть - аж никак не цепляет. Листаешь, спрашиваешь "нафига оно мне?" и ставишь обратно. Лучше даже сказать, что 99% того, что я вижу в типичном книжном это просто гадательная литература, какой бы ни был автор, жанр, направление - годится только на то чтобы открыть, найти аргумент за или против тому, что хотел сделать, и закрыть.
Автор статьи, вероятно, рассчитывает на формат, когда любая хоть сколько-то пошумевшая новинка покупалась всеми, кто хотел изобразить, что он "современный", "в теме" и пр. Но так уже давно не работает. И проблема не в неоплате авторов. Проблема в том, что у авторов нет, чем заинтересовать читателя, чтобы имело смысл перечитывать. Читатели уходят в другие форматы контента.
Ну и по вкусам:
Если что, у меня ещё бумажная района 97-го года с обложкой в розовых тонах. Если говорить о её вставной части "Иное небо" - то тут согласен, только не в современной, а в позднесоветской. Но всё ВСДО целиком... нет нет и нет. Лазарчук отлично начинает, но сливает концовки в ноль, и про путешествия во времени надо писать так, чтобы не было по триста роялей в каждом кустике, чтобы была хоть какая-то логика. (Не он один такой...) И в ВСДО ещё какой-то намёк на связность, а вот в "Опоздавших к лету"... цитируя Хайнлайна, это такой же вариант эпилога, как "и тогда мальчик свалился с кровати и проснулся". Ну и вообще, это 80-е. Даже если не по фактическому написанию, по замыслу. Нового-то что будет? И откуда?
Роулинг создала мрачную антиутопию на современном материале, прикрыв её стандартной героической эпопеей - и именно в этом не промахнулась. На Линдгрен как-то не похоже.
Самая сложная часть тут, мне кажется, это первичная сортировка. В каком-то изделии типа холодильника может быть и несколько сортов стали (и не только стали, а и алюминия и пр.), а разбирать его - ручная дорогая работа. И уже после выплавки разбираться, "что это мы сварили и куда его применить"?
Ну да, обычно делают через промежуточный указатель (в Unix мире он обычно зовётся softc).
Но метод с явными указателями в каждом экземпляре применён, например, в Berkeley DB.
Если + или / не может значить ничего, кроме простого сложения-деления-итд двух примитивных типов, значительно легче следить за происходящим - что у этого нет побочных эффектов. Максимум, что есть, если, например, складываются или делятся два int64_t, int128_t на 32-битной платформе, и это сделано через функцию - но таких функций всего несколько на всю программу. А вот если они могут значить что угодно и надо следить за типами - это усложняет чтение, вплоть до потери следа.
Да, граница не абсолютна, но она есть. Я бы не допускал такое просто так без учёта, где именно что сложно потерять контекст.
Добавка к C таких возможностей C++, как пространства имён и модификаторы видимости членов классов, как раз очень бы помогла.
А вот дальнейшее развитие - уже ХЗ, как уже говорили в комментариях, уже начиная с переопределения операторов, когда ты не знаешь, что сделает конкретный a+b, становится стрёмным.
И виртуальные функции это уже где-то на грани, надо тщательно подумать, прежде чем допускать.