Теоретически можно. Фактически же только недавно появилась реализация поиска макбуков с использованием постоянно рассылаемых им bluetooth сообщений, которые ловят оказавшиеся рядом устройства от Apple и пересылают токен устройства + свои координаты на сервер компании, где владелец может эти координаты отслеживать. И, насколько я понимаю, блокировка устройства всё равно требует того, чтобы его подключили к интернету. Для чего, как правило, злоумышленнику нужно ноутбук сначала сбросить — он же пароль от учётки владельца не знает всё равно.
И даже если ноут каким-то чудом получится заблокировать, он быстро раскирпичивается буквально на коленке при помощи ардуинки, переходника на разъём для внутрисхемной прошивки bios и гугла.
А также зарабатывая на платном внесении в реестр тех, кто купил себе телефон за рубежом, ага. Или GSM модуль для ардуинки. Или GPS трекер с отправкой координат через мобильные сети. Или любую другую фигню, куда можно воткнуть симку и при этом не имеющуюся в продаже в местных магазинах.
Моё личное мнение: чёрный список для украденных устройств нужен (хотя и он не панацея), а белый список, который у нас мечтают создать — очевидное вредительство.
Вообще да, вот чего-чего, а уверенности и целеустремленности Поттерингу не занимать. Довести до нынешнего состояния такой проект при всех потоках хейта и бурлениях говн в сторону лично Поттеринга. Я снимаю шляпу.
У меня стойкое впечатление, что об удобстве и разумности rc скриптов пишут в основном те, кому не приходилось в вопрос запуска сервисов дальше выставления автозапуска у установленного из репозитория софта лезть. rc скрипты по запуску типичного сервиса типа nginx или mysql, выполняющие всё то, что реально хотелось бы от них, — это чудовищного размера абоминации, причём каждый второй со своей логикой.
Те полотнища, которые в принципе занимались подготовкой всего юзерспейса после старта ядра, я даже не стану упоминать.
Если вы не желаете чтобы ВСЁ писалось на диск/флешку — можно легко отключить запись бинарных логов journald на non-volatile storage и хранить логи только в оперативной памяти. Мне мнится, что на типичном десктопе с или raspberry pi почти всегда логами с прошлых запусков системы можно пренебречь. Опционально можно копировать логи из journald в какой-нибудь классический syslog демон, его силами фильтровать ненужное, а потом писать что хочется, куда хочется и как хочется. Я лично, к примеру, на серверах локально пишу таким образом нужные кусочки логов. И доволен аки слон.
Кстати, у journald эта опция по дефолту выставлена в "Auto", при этом значении на диск логи пишутся в случае существования пути /var/log/journal/. Если пути нет — пишутся только в память. Поэтому на всяческих rpi можно просто сразу сделать rm -rf /var/log/journal и забыть о проблеме.
Ну и напоследок хочу заметить: мне кажется крайне неправильно считать journald этакой плохо спроектированной и недостаточно фичастой заменой классическим syslog демонам или специализированным решениям для сборки и консолидации логов на отдельной хранилке. Воспринимайте journald как нечто, что собирает в одном месте выхлоп от всего, что его в принципе производит, заодно авторитетно добавляя поля типа pid/name источника. А дальше это нечто позволяет делать с собранным то, что вам нужно + даёт возможность посмотреть все логи единым полотном, что нередко очень и очень удобно.
Этот набор, увы, оказывается не всегда достаточным в случае разношерстного оборудования(
На практике лично мне пришлось делать модули, которые собирают lldp, всякие проприетарные протоколы (cdp, edp итд), fdb таблицу в влане управления и даже stp. Причём не только по snmp, что-то приходится забирать по ssh и даже по telnet. Каждый модуль пишет собранные данные в отдельную для каждого способа/протокола табличку в постгресе. Таблички регулярно (несколько раз в минуту) обрабатывает сервис на Go, формирует топологию, определяет её разницу с текущей и апдейтит итоговую таблицу связности.
И вот только в таком виде топология для мультивендорной сети становится практически полностью известной. Ну и можно исторические данные сохранять бонусом — иногда полезно в прошлое посмотреть.
А насколько утилизируется процессор при ваших 30 гигабитах и сколько при этом сессий? Если не секрет конечно же.
Спрашиваю, а не экстраполирую данные из графика в статье потому что оно может очень нелинейно расти при увеличении pps и числа сессий.
SSTP работает поверх TCP. VPN, использующий транспорт с какими-либо состояниями и гарантиями доставки (в данном случае читать как "TCP") — это крайне некрасивое решение технически и просто плохо работает в случае банального соединения с потерями. Единственное, что можно отнести к плюсам SSTP — мимикрия под HTTPS.
Ну, учитывая, что время от времени что-то подобное вроде как пытаются сделать, но ничего реально живого и распространённого так до сих пор и не появилось, то должен быть весьма немалый. Я, честно скажу, ещё не успел повникать в сабж, но мне одна только синхронизация общих ресурсов потоков по сети кажется адски узким местом
Теряют. Конкретно у меня валялось пара MLC интелов год с лишним на полке, ожидаемо оба в итоге с побитыми в хлам данными. Благо я знал заранее и там ничего нужного в единственном экземпляре не держал.
Ну и, к слову, microsd в старом телефоне со временем стала выдавать всё больше и больше артефактов в хранящихся на ней аудиотреках, даром что из телефона не вынималась и питание на ней всегда было. Вот просто так, на работающей карточке потихоньку на ровном месте умирали давно записанные данные.
Я про то порно, которое не "картинка и воображение", а про то, что сейчас в первую очередь с данным термином ассоциируется. Ну, и к слову, ваши слова только подтверждают мой тезис. Смотрели что было, высокой советской моралью тут и не пахнет.
Не помогало. Люди в Советском Союзе не смотрели порно потому что не было на чем смотреть и не было что смотреть. Появились видеомагнитофоны и VHS кассеты и эти же самые люди стали смотреть. "Высокоморальность" тут вообще не при делах.
Я вот оба раза не зря специально писал про развитые страны.
Узбекистан, мсье, страна развивающаяся. И в данный момент там как раз резко падает рождаемость параллельно с развитием медицины и экономики.
Что именно в вашей реальности наоборот? Среднестатистический представитель цивилизованной страны резко стремится клепать детей, почуяв что их как раз скоро будет нечем кормить и не на что учить? Здравомыслящие люди не предохраняются, рожают, а дальше следуют принципу «Подумаешь, это всего-навсего новый человек, сам как-нибудь во всём разберётся»? Люди, всегда мечтающие завести детей, прилагают все усилия чтобы никогда не стать родителями?
Тут такое дело. Деторождаемость и доступность порнографии связаны чуть более чем никак. В развитых странах детей значительно чаще и охотнее заводят люди, которые немножечко уверены в своём будущем, в росте (или хотя бы не падении) своего благосостояния, имеют подходящие жилищные условия (или хотя бы ожидают их скорого улучшения) etc. Ну или люди, хронически и упорно не умеющие ни предохраняться, ни думать о том, что родить человека — это только начало. Есть, конечно, ещё те, кто просто очень любит и хочет детей, посему заводит их вопреки всем трудностям, но будем честны, их исчезающе мало.
По статистике, каждая сотня людей владеет примерно 114 устройствами. С 5G эта цифра может вырасти до 10 тыс.
Складывается впечатление, что автор всерьёз рассчитывает показывать рекламу в формате коротких HD видеороликов на всех этих новых устройствах: чайниках, умных лампочках, холодильниках, робопылесосах и далее по списку.
Бизнес может банально упереться рогом и не дать достаточно времени на нормальную реализацию очередной фичи, которая резко стала нужна ещё вчера. Бизнес может со временем изменить или добавить хотелки так, что некоторые вещи имеет смысл отрефакторить прямо сейчас дабы потом не наращивать тонны плохого и/или однотипного кода.
Вот честное слово, иногда читаешь и ловишь себя на мысли, что все вокруг знают хотелки раньше самого бизнеса, отчего сразу проектируют и пишут код идеально и на годы вперёд. Не имеют никакого технического долга, не делают никакого рефакторинга или адаптации узких мест под возросшие нагрузки. Как-то это всё, к сожалению, расходится с наблюдаемой мной реальностью чуть менее чем всегда.
Я чуть выше писал про замер типичного синего светодиода, буквально первого попавшегося под руку. Номинальный ток 20mA. Слепить перестаёт при токе <= 50uA. И это ещё днём. Разница с номинальным током почти три порядка.
И даже если ноут каким-то чудом получится заблокировать, он быстро раскирпичивается буквально на коленке при помощи ардуинки, переходника на разъём для внутрисхемной прошивки bios и гугла.
Моё личное мнение: чёрный список для украденных устройств нужен (хотя и он не панацея), а белый список, который у нас мечтают создать — очевидное вредительство.
Вообще да, вот чего-чего, а уверенности и целеустремленности Поттерингу не занимать. Довести до нынешнего состояния такой проект при всех потоках хейта и бурлениях говн в сторону лично Поттеринга. Я снимаю шляпу.
Позвольте поинтересоваться: зачем "кроме cron-а", когда можно (и нужно) "вместо cron-а"?
У меня стойкое впечатление, что об удобстве и разумности rc скриптов пишут в основном те, кому не приходилось в вопрос запуска сервисов дальше выставления автозапуска у установленного из репозитория софта лезть. rc скрипты по запуску типичного сервиса типа nginx или mysql, выполняющие всё то, что реально хотелось бы от них, — это чудовищного размера абоминации, причём каждый второй со своей логикой.
Те полотнища, которые в принципе занимались подготовкой всего юзерспейса после старта ядра, я даже не стану упоминать.
Если вы не желаете чтобы ВСЁ писалось на диск/флешку — можно легко отключить запись бинарных логов journald на non-volatile storage и хранить логи только в оперативной памяти. Мне мнится, что на типичном десктопе с или raspberry pi почти всегда логами с прошлых запусков системы можно пренебречь. Опционально можно копировать логи из journald в какой-нибудь классический syslog демон, его силами фильтровать ненужное, а потом писать что хочется, куда хочется и как хочется. Я лично, к примеру, на серверах локально пишу таким образом нужные кусочки логов. И доволен аки слон.
Кстати, у journald эта опция по дефолту выставлена в "Auto", при этом значении на диск логи пишутся в случае существования пути /var/log/journal/. Если пути нет — пишутся только в память. Поэтому на всяческих rpi можно просто сразу сделать rm -rf /var/log/journal и забыть о проблеме.
Ну и напоследок хочу заметить: мне кажется крайне неправильно считать journald этакой плохо спроектированной и недостаточно фичастой заменой классическим syslog демонам или специализированным решениям для сборки и консолидации логов на отдельной хранилке. Воспринимайте journald как нечто, что собирает в одном месте выхлоп от всего, что его в принципе производит, заодно авторитетно добавляя поля типа pid/name источника. А дальше это нечто позволяет делать с собранным то, что вам нужно + даёт возможность посмотреть все логи единым полотном, что нередко очень и очень удобно.
На практике лично мне пришлось делать модули, которые собирают lldp, всякие проприетарные протоколы (cdp, edp итд), fdb таблицу в влане управления и даже stp. Причём не только по snmp, что-то приходится забирать по ssh и даже по telnet. Каждый модуль пишет собранные данные в отдельную для каждого способа/протокола табличку в постгресе. Таблички регулярно (несколько раз в минуту) обрабатывает сервис на Go, формирует топологию, определяет её разницу с текущей и апдейтит итоговую таблицу связности.
И вот только в таком виде топология для мультивендорной сети становится практически полностью известной. Ну и можно исторические данные сохранять бонусом — иногда полезно в прошлое посмотреть.
А насколько утилизируется процессор при ваших 30 гигабитах и сколько при этом сессий? Если не секрет конечно же.
Спрашиваю, а не экстраполирую данные из графика в статье потому что оно может очень нелинейно расти при увеличении pps и числа сессий.
SSTP работает поверх TCP. VPN, использующий транспорт с какими-либо состояниями и гарантиями доставки (в данном случае читать как "TCP") — это крайне некрасивое решение технически и просто плохо работает в случае банального соединения с потерями. Единственное, что можно отнести к плюсам SSTP — мимикрия под HTTPS.
Ну, учитывая, что время от времени что-то подобное вроде как пытаются сделать, но ничего реально живого и распространённого так до сих пор и не появилось, то должен быть весьма немалый. Я, честно скажу, ещё не успел повникать в сабж, но мне одна только синхронизация общих ресурсов потоков по сети кажется адски узким местом
Теряют. Конкретно у меня валялось пара MLC интелов год с лишним на полке, ожидаемо оба в итоге с побитыми в хлам данными. Благо я знал заранее и там ничего нужного в единственном экземпляре не держал.
Ну и, к слову, microsd в старом телефоне со временем стала выдавать всё больше и больше артефактов в хранящихся на ней аудиотреках, даром что из телефона не вынималась и питание на ней всегда было. Вот просто так, на работающей карточке потихоньку на ровном месте умирали давно записанные данные.
Я про то порно, которое не "картинка и воображение", а про то, что сейчас в первую очередь с данным термином ассоциируется. Ну, и к слову, ваши слова только подтверждают мой тезис. Смотрели что было, высокой советской моралью тут и не пахнет.
Не помогало. Люди в Советском Союзе не смотрели порно потому что не было на чем смотреть и не было что смотреть. Появились видеомагнитофоны и VHS кассеты и эти же самые люди стали смотреть. "Высокоморальность" тут вообще не при делах.
Я вот оба раза не зря специально писал про развитые страны.
Узбекистан, мсье, страна развивающаяся. И в данный момент там как раз резко падает рождаемость параллельно с развитием медицины и экономики.
Складывается впечатление, что автор всерьёз рассчитывает показывать рекламу в формате коротких HD видеороликов на всех этих новых устройствах: чайниках, умных лампочках, холодильниках, робопылесосах и далее по списку.
Бизнес может банально упереться рогом и не дать достаточно времени на нормальную реализацию очередной фичи, которая резко стала нужна ещё вчера. Бизнес может со временем изменить или добавить хотелки так, что некоторые вещи имеет смысл отрефакторить прямо сейчас дабы потом не наращивать тонны плохого и/или однотипного кода.
Вот честное слово, иногда читаешь и ловишь себя на мысли, что все вокруг знают хотелки раньше самого бизнеса, отчего сразу проектируют и пишут код идеально и на годы вперёд. Не имеют никакого технического долга, не делают никакого рефакторинга или адаптации узких мест под возросшие нагрузки. Как-то это всё, к сожалению, расходится с наблюдаемой мной реальностью чуть менее чем всегда.
Поспрашивал коллег в нескольких весьма крупных и полудюжине мелких операторов.
Первый раз там слышат, опять учёный изнасиловал журналиста.
Я чуть выше писал про замер типичного синего светодиода, буквально первого попавшегося под руку. Номинальный ток 20mA. Слепить перестаёт при токе <= 50uA. И это ещё днём. Разница с номинальным током почти три порядка.