Возможно, толку от этого немножко меньше, чем хотелось бы, ведь всё это время он совершенно точно умел быть участником такой интересной штуки, как BLE mesh, почти наверняка в нём есть микрофон, а если чипсет достаточно свежий, то, наверное, есть и AI inference accelerator
Выражение "у стен есть уши" никогда не было таким буквальным
К сожалению, не совсем так. Даже самая простая прога исполняется в суперсложной среде
Весь этот стек железа (глючного), операционки (глючной), да, скорее всего, под супервизором (глючным). Кстати, супервизор есть даже на голом компе, якобы, не содержащем установленной операционки. Потому что операционка установлена на заводе-изготовителе. Называется загрузчик. Да притом не одна, потому что каждая железка в компе представляет из себя мини-комп со своим загрузчиком
Поэтому на некоторых наборах входных данных на выходе будут нежданчики, называются уязвимостями и поиск их крайне сложен
Грубо говоря, f(1)=1; f(2)=2, но f(2)=2; f(1)=17
Одна и та же функция на один и тот же аргумент выдаёт разные результаты. Конкретные примеры сбоев вычислений можно увидеть, скажем, на SecurityLab
Итак, в тестах надо проверять не только все элементы доменов, но и все возможные последовательности и сочетания, то есть, ни о каком полном покрытии не может быть и речи
Всё это, заметьте, даже при допущении, что аппаратные сбои исключены, и байтики при пересылке не искажаются
Если язык поддерживает передачу и порядковых, и именованных параметров, имеет большой смысл всегда использовать именованные, например, эти две записи в таком языке будут равнозначны:
myfunc(Speed=speed, Height=height)
myfunc(Height=height, Speed=speed)
Размер кода немножко возрастает, но за это получаем аж три бонуса:
можно передавать переменные в любом порядке, в каком они вспомнились;
труднее ошибиться и передать не те параметры;
при чтении кода понятнее, что делает вызов, даже если переменные названы не особо интуитивно
Вы пытаетесь игнорировать природные закономерности, а они мстительные, не любят, когда их игнорируют. Закономерности вот какие:
ненадёжность памяти обусловлена Природой, поэтому "мне помнится, что..." и "на самом деле" - разные вещи;
полное соответствие кода и рукописной документации недостижимо даже теоретически в то время, как код, по-видимому, соответствует сам себе;
комментарии - тоже документация;
с учётом вышесказанного, изучая код, можно быть твёрдо уверенным, что изучаешь действующую логику работы программы, а изучая доки и комменты, в этом уверенным быть нельзя:
нет никаких способов получить программу, "работающую правильно", поскольку для того, чтобы убедиться, что ошибки никогда не возникают, надо провести бесконечное число тестов в бесконечном количестве ситуаций;
раз нельзя быть уверенным в полной надёжности программы, то следует быть готовым к тому, что любая программа со временем будет нуждаться в доработках;
"читабельность", "выразительность", "красота" - не самоцель, но средство получать меньше ошибок в ходе разработки и сопровождения.
Значение оно имеет вот какое: в своём коде по прошествии весьма незначительного времени разбираться приходится примерно так же с нуля, как и в чужом
Вообще, любой код полезно писать с учётом того, что он, скорее всего, будет нуждаться в доработках посторонних людей. Себя также следует включать в число этих посторонних, исходя из того, что память не просто ненадёжна, она крайне ненадёжна
Но в чём тогда суть постоянного "улучшения защиты" мобильных OS, если несистемные процессы без рута могут собирать "сведения о сторонних приложениях"? Я-то по простоте своей полагал, что защита - это, как минимум (если не в первую очередь), изоляция, чтобы процессы не видели ничего за пределами своей "песочницы"
Оно, конечно, и в настольных виндах/линухах кто ни попадя может смотреть списки процессов, что мне всегда представлялось маразменным пережитком досовских времён
— будет и короче, и понятнее, и «питоничнее», и исполняться будет быстрее.
Скобки срочно убрать, это вам не C и не Java!!!
if (os.path.exists(USERDATA_FILE) and new == True):
Ну и так далее.
В общем, линтеры-чекеры в помощь, а то ж глазам больно на такой код смотреть. А ещё лучше — нормальный редактор, который будет в реальном времени текст проверять
А толку указывать вес без указания координат точки, где стояли весы (в том числе и координаты t, потому со временем изменяется как масса Земли, так и положение полюсов), и ускорения в момент измерений
Уверенным я был бы, кабы присутствовал на заседании правления, где бы решали этот вопрос. Но не присутствовал, поэтому, конечно, могу только делать предположения. Но сильно склоняюсь к тому, чтобы считать, что это сделано преднамеренно
Хотя бы потому, что в моём дивайсе есть достаточно массивные фрезерованные металлические части, которые там нафиг не сдались, можно было бы обойтись пластиковым литьём. Именно так и сделано на некоторых других дивайсах, пластик в этом месте служит надёжно, не ломается
Вообще, пластиковые шестерни взамен металлических - это не само по себе плохое техническое решение. Где-то они десятилетиями работают себе и работают, даже и не думают ломаться. Но тут они сделаны на редкость ущербно
Бывает как раз, что купить новую запчасть проблемы вообще нет и даже цена низкая, но конечному юзеру от этого не особо легче
У меня есть некое дохлое устройство. Поломка типовая для целого класса подобных устройств (потому что в них используются типовые узлы) - треснула пополам совершенно конкретная шестерня. Она есть в свободной продаже, цена копеешная. Только вот для замены надо не только раскидать весь дивайс на мельчайшие составные части, но и суметь потом собрать назад. А частей - ой, много... А мелкие-то какие... Плюс восстановить проклейку, смазку и не насажать пыли и жЫрных отпечатков
Чинить за деньги нецелесообразно, потому как в сервисе возьмут немало, а она снова сдохнет, пожалуй и побыстрее, чем новая. Так что вариант один - запастить мешком шестерёнок по оптовой цене и чинить самому. Но понятно ведь, что этот вариант - не так, чтобы вариант
Интересно, если кто-то взялся бы доказывать, что это не "запланированное устаревание", то какие аргументы он сумел бы привести
Индексирование бумажных записей - да, поиск - нет. В том смысле нет, что для поиска надо сначала (вручную) "проиндексировать" и сделать "картотеку для картотеки". И не забывать делать это каждый раз при изменении заметок
И во ещё вспомнил из недостатков бумаги: немного сложноватые бэкапы и история/откат изменений
Мечта 7-скоростного запоминальщика, короче говоря. Дайте две. А лучше три. Или лучше дайте все, что есть на складе
Обсидиан, конечно, рулит. В августе для себя его открыл и уже где-то недельки через две не понимал, как жил без него раньше. А вот к цеттелькастену имею бааааальшие претензии. Очень уж откровенно веет от него душком MLM-презентаций (покупайте наших слонов, и ваши волосы будут мягкими и шелковистыми)
Как будто бы до цеттелькастена люди не писали коротких законченных заметок или не пытались их систематизировать. Да, блин, всё библиотечное дело основано на таких карточках, при этом никто и никогда их не считал чем-то волшебным и решающим все проблемы
Но у заметок от руки есть минимум четыре существенных недостатка, которых нет у компьютерных заметок:
низкая скорость записи (в принципе, лечится при помощи стенографии)
никудышние возможности редактирования, по сути, можно только выкинуть и написать заново (теоретически лечится при помощи рукописной записи на электронном экране, но попробуйте-ка выполнить это на практике)
плохая читабельность заметок (в теории лечится занятиями каллиграфией, на практике, очевидно, не лечится)
никакущие возможности поиска (в теории лечится при помощи картотеки, но, похоже, этот способ мог успешно применять только сам аффтар хвалёного Zettelkasten-а)
В то же время, никто из советующих записывать не проверял, насколько способствует запоминанию интенсивная работа с текстом на компьютере. То есть, не просто записать своими словами (что самоочевидно полезно для запоминания), так ещё оформить текст всякими там красивостями (абзацы, заголовки, списки, отступы, стили, сноски) и перекрёстными ссылками. Особенно ссылками. Потому что надо ведь вспомнить, что уже было, а регулярное вспоминание как раз и способствует переходу инфы в долговременную память
Просто есть у меня подозрение, переходящее в уверенность, что запоминание при записи происходит не автомаГическим образом, а банально из-за выполнения мозгом ассоциативных действий в контексте текущей задачи. Чем больше таких действий на одну замоминаемую единицу, тем лучше запоминание
То есть, можно хоть и вовсе не записывать, а просто крутить мысль так и сяк. И этот способ абсолютно рабочий, каждый из нас его применял, пусть и не специально
Да это пусть себе даёт. Я имел в виду, что авторы убунтовских дистрибутивов, скорее всего, не вполне руководствовались идеей экономии ресурсов. Может, даже и вовсе не руководствовались
Возможно, толку от этого немножко меньше, чем хотелось бы, ведь всё это время он совершенно точно умел быть участником такой интересной штуки, как BLE mesh, почти наверняка в нём есть микрофон, а если чипсет достаточно свежий, то, наверное, есть и AI inference accelerator
Выражение "у стен есть уши" никогда не было таким буквальным
Интересно, думают ли телевизоры об электроовцах?
Лучше замораживать. Во-первых, кристаллы вакуума очень красивые, во-вторых, жидкость протекает
К сожалению, не совсем так. Даже самая простая прога исполняется в суперсложной среде
Весь этот стек железа (глючного), операционки (глючной), да, скорее всего, под супервизором (глючным). Кстати, супервизор есть даже на голом компе, якобы, не содержащем установленной операционки. Потому что операционка установлена на заводе-изготовителе. Называется загрузчик. Да притом не одна, потому что каждая железка в компе представляет из себя мини-комп со своим загрузчиком
Поэтому на некоторых наборах входных данных на выходе будут нежданчики, называются уязвимостями и поиск их крайне сложен
Грубо говоря,
f(1)=1; f(2)=2, ноf(2)=2; f(1)=17Одна и та же функция на один и тот же аргумент выдаёт разные результаты. Конкретные примеры сбоев вычислений можно увидеть, скажем, на SecurityLab
Итак, в тестах надо проверять не только все элементы доменов, но и все возможные последовательности и сочетания, то есть, ни о каком полном покрытии не может быть и речи
Всё это, заметьте, даже при допущении, что аппаратные сбои исключены, и байтики при пересылке не искажаются
Если язык поддерживает передачу и порядковых, и именованных параметров, имеет большой смысл всегда использовать именованные, например, эти две записи в таком языке будут равнозначны:
myfunc(Speed=speed, Height=height)myfunc(Height=height, Speed=speed)Размер кода немножко возрастает, но за это получаем аж три бонуса:
можно передавать переменные в любом порядке, в каком они вспомнились;
труднее ошибиться и передать не те параметры;
при чтении кода понятнее, что делает вызов, даже если переменные названы не особо интуитивно
Вы пытаетесь игнорировать природные закономерности, а они мстительные, не любят, когда их игнорируют. Закономерности вот какие:
ненадёжность памяти обусловлена Природой, поэтому "мне помнится, что..." и "на самом деле" - разные вещи;
полное соответствие кода и рукописной документации недостижимо даже теоретически в то время, как код, по-видимому, соответствует сам себе;
комментарии - тоже документация;
с учётом вышесказанного, изучая код, можно быть твёрдо уверенным, что изучаешь действующую логику работы программы, а изучая доки и комменты, в этом уверенным быть нельзя:
нет никаких способов получить программу, "работающую правильно", поскольку для того, чтобы убедиться, что ошибки никогда не возникают, надо провести бесконечное число тестов в бесконечном количестве ситуаций;
раз нельзя быть уверенным в полной надёжности программы, то следует быть готовым к тому, что любая программа со временем будет нуждаться в доработках;
"читабельность", "выразительность", "красота" - не самоцель, но средство получать меньше ошибок в ходе разработки и сопровождения.
Значение оно имеет вот какое: в своём коде по прошествии весьма незначительного времени разбираться приходится примерно так же с нуля, как и в чужом
Вообще, любой код полезно писать с учётом того, что он, скорее всего, будет нуждаться в доработках посторонних людей. Себя также следует включать в число этих посторонних, исходя из того, что память не просто ненадёжна, она крайне ненадёжна
С браузерной-то инфой как раз всё понятно
Но в чём тогда суть постоянного "улучшения защиты" мобильных OS, если несистемные процессы без рута могут собирать "сведения о сторонних приложениях"? Я-то по простоте своей полагал, что защита - это, как минимум (если не в первую очередь), изоляция, чтобы процессы не видели ничего за пределами своей "песочницы"
Оно, конечно, и в настольных виндах/линухах кто ни попадя может смотреть списки процессов, что мне всегда представлялось маразменным пережитком досовских времён
Линтеры и всякие там чекеры (flake8, pylint, mypy и т.д.) при написании на питоне должны быть вашими лучшими друганами, а вы их игнорите. Нехорошо-с.
Переменные и функции пишутся в нижнем регистре с подчёркиваниями, а у вас они в верблюжьем (CamelCase), в котором пишутся классы.
Вместо такого вот ужоса лучше бы написать — будет и короче, и понятнее, и «питоничнее», и исполняться будет быстрее.
Скобки срочно убрать, это вам не C и не Java!!!
Ну и так далее.
В общем, линтеры-чекеры в помощь, а то ж глазам больно на такой код смотреть. А ещё лучше — нормальный редактор, который будет в реальном времени текст проверять
А толку указывать вес без указания координат точки, где стояли весы (в том числе и координаты
t, потому со временем изменяется как масса Земли, так и положение полюсов), и ускорения в момент измеренийЗачем мне вечная игла для примуса? Я не собираюсь жить вечно
Уверенным я был бы, кабы присутствовал на заседании правления, где бы решали этот вопрос. Но не присутствовал, поэтому, конечно, могу только делать предположения. Но сильно склоняюсь к тому, чтобы считать, что это сделано преднамеренно
Хотя бы потому, что в моём дивайсе есть достаточно массивные фрезерованные металлические части, которые там нафиг не сдались, можно было бы обойтись пластиковым литьём. Именно так и сделано на некоторых других дивайсах, пластик в этом месте служит надёжно, не ломается
Вообще, пластиковые шестерни взамен металлических - это не само по себе плохое техническое решение. Где-то они десятилетиями работают себе и работают, даже и не думают ломаться. Но тут они сделаны на редкость ущербно
Под срок жизни пользователя. Срок службы >= средняя продолжительность жизни в данной местности минус возраст при покупке
Ещё можно учитывать, собирается ли чел передавать товар по наследству и скольким поколениям потомков
Бывает как раз, что купить новую запчасть проблемы вообще нет и даже цена низкая, но конечному юзеру от этого не особо легче
У меня есть некое дохлое устройство. Поломка типовая для целого класса подобных устройств (потому что в них используются типовые узлы) - треснула пополам совершенно конкретная шестерня. Она есть в свободной продаже, цена копеешная. Только вот для замены надо не только раскидать весь дивайс на мельчайшие составные части, но и суметь потом собрать назад. А частей - ой, много... А мелкие-то какие... Плюс восстановить проклейку, смазку и не насажать пыли и жЫрных отпечатков
Чинить за деньги нецелесообразно, потому как в сервисе возьмут немало, а она снова сдохнет, пожалуй и побыстрее, чем новая. Так что вариант один - запастить мешком шестерёнок по оптовой цене и чинить самому. Но понятно ведь, что этот вариант - не так, чтобы вариант
Интересно, если кто-то взялся бы доказывать, что это не "запланированное устаревание", то какие аргументы он сумел бы привести
Индексирование бумажных записей - да, поиск - нет. В том смысле нет, что для поиска надо сначала (вручную) "проиндексировать" и сделать "картотеку для картотеки". И не забывать делать это каждый раз при изменении заметок
И во ещё вспомнил из недостатков бумаги: немного сложноватые бэкапы и история/откат изменений
Мечта 7-скоростного запоминальщика, короче говоря. Дайте две. А лучше три. Или лучше дайте все, что есть на складе
Обсидиан, конечно, рулит. В августе для себя его открыл и уже где-то недельки через две не понимал, как жил без него раньше. А вот к цеттелькастену имею бааааальшие претензии. Очень уж откровенно веет от него душком MLM-презентаций (покупайте наших слонов, и ваши волосы будут мягкими и шелковистыми)
Как будто бы до цеттелькастена люди не писали коротких законченных заметок или не пытались их систематизировать. Да, блин, всё библиотечное дело основано на таких карточках, при этом никто и никогда их не считал чем-то волшебным и решающим все проблемы
Записывать полезно, кто бы сомневался
Но у заметок от руки есть минимум четыре существенных недостатка, которых нет у компьютерных заметок:
низкая скорость записи (в принципе, лечится при помощи стенографии)
никудышние возможности редактирования, по сути, можно только выкинуть и написать заново (теоретически лечится при помощи рукописной записи на электронном экране, но попробуйте-ка выполнить это на практике)
плохая читабельность заметок (в теории лечится занятиями каллиграфией, на практике, очевидно, не лечится)
никакущие возможности поиска (в теории лечится при помощи картотеки, но, похоже, этот способ мог успешно применять только сам аффтар хвалёного Zettelkasten-а)
В то же время, никто из советующих записывать не проверял, насколько способствует запоминанию интенсивная работа с текстом на компьютере. То есть, не просто записать своими словами (что самоочевидно полезно для запоминания), так ещё оформить текст всякими там красивостями (абзацы, заголовки, списки, отступы, стили, сноски) и перекрёстными ссылками. Особенно ссылками. Потому что надо ведь вспомнить, что уже было, а регулярное вспоминание как раз и способствует переходу инфы в долговременную память
Просто есть у меня подозрение, переходящее в уверенность, что запоминание при записи происходит не автомаГическим образом, а банально из-за выполнения мозгом ассоциативных действий в контексте текущей задачи. Чем больше таких действий на одну замоминаемую единицу, тем лучше запоминание
То есть, можно хоть и вовсе не записывать, а просто крутить мысль так и сяк. И этот способ абсолютно рабочий, каждый из нас его применял, пусть и не специально
Не даёт она ключ
У 99,9% инструкций (руководств пользователя), включая вашу, есть один общий недостаток: они рассказывают, КАК, но не рассказывают, ЗАЧЕМ
Какие проблемы читателя инструкции должны решать и решают (или должны, но не решают) эти бинарные системы и двусторонние связи?
А ведь это должно быть намечено не ниже, чем в первых трёх абзацах, и раскрыто в нижеследующем тексте
удалено
Да это пусть себе даёт. Я имел в виду, что авторы убунтовских дистрибутивов, скорее всего, не вполне руководствовались идеей экономии ресурсов. Может, даже и вовсе не руководствовались
Это можно рассказывать как анекдот: перешёл на убунту ради экономии ресурсов компа