В том то и дело, что он systemless (ставится в boot, само приложение может перепаковываться под непонятную белиберду). system раздел не трогается, dm-verify проходит, safetynet проходит — его *мягко говоря* трудно задетектить, если не сказать, что невозможно.
Как вам уже сказали — сканируют вообще всё и вся.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
Пусть тестируют, и сколько угодно могут перебирать rsa4096 тоже, мне не жалко :)
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
Экспериментальное с точки зрения именования классов, функций и прочего в библиотеке kotlinx.coroutines. Сами корутины протестированы достаточно (как с точки зрения юнит-тестов, так и проверены временем и продакшеном). И да, пользоваться kotlinx.coroutines гораздо удобнее в котлине, чем RxJava/RxKotlin. Ну, как минимум для меня. Хотя никто не запрещает, это да.
А есть серьёзные языки, которые создаются как неудобные, что ли?
Rust и C++ считаются? :)
Дело не в том, что создаются как "неудобные", а в том, что "удобство" это одна из первоочерёдных задач.
А если пакетов больше, то тогда уже не «чуть».
По сравнению с public частью — всё-таки "чуть".
язык не позволяет мне понять, где нештатные ситуации могут возникнуть, а где нет.
Да OOM может вылететь от каждого оператора new, SOE может вылететь от каждого вызова функции — теперь что, оборачивать всю программу в try-catch? Kotlin не отбирает возможность определения throws, как и отлова исключений.
А вообще скатываться на личные аргументы некрасиво.
Вы меня не поняли. Я не скатывался в стиле "ниасилил", я сам через это проходил. После нескольких лет Java Kotlin (особенно до версии 1.0 и в некоторых моментах до 1.1) выглядел… мягко говоря непривычно. Я плевался чуть ли не от каждой фичи, которая была сделана не так, как в Java просто потому, что всё не Java, кроме Java. Я не понимал, почему авторы сделали то-то и то-то, от того отказались, заменили на то-то. Мне понадобилось некоторое время для изучения stdlib и других библиотек чтобы осознать, как стоит писать на Kotlin и почему не надо бездумно копировать практики с Java просто потому, что это тоже JVM язык.
философия Kotlin заключается в доверии большего количества инструментов программисту (по крайней мере, нам так показалось)
Вам показалось. Kotlin создавался как удобный, прагматичный язык, и описанные вами возможности авторы языка посчитали ненужными и отвлекающими от разработки.
Собственно, почему вам не хватает internal? Да, это область видимости чуть больше, чем package-private, но и проблем с ним меньше.
А о исключениях можно спорить вечно… Кто-то считает, что обязательно должны быть проверяемые исключения и компилятор должен насиловать мозг на каждый чих, кто-то считает, что исключения — это зло (как минимум, в том виде, какие они в Java). Правда как всегда где-то посередине.
Как мне показалось из статьи, у Вас мозг "отформатирован" под Java и ещё не до конца осознал Kotlin, это всё-таки не просто Java-с-плюшками, это другой язык, хоть у него и хороший интероп с экосистемой Java.
Да там не только ThreadLocal перестаёт работать, но и RW-локи (точнее extension-методы read и write, т.к. последний снимает read локи текущего потока и ставит их обратно после завершения блока). Но корутины вообще не поощряют какое-либо состояние, в том числе и общее — они заточены на коммуникацию между друг-другом.
Если дело в logback, то тогда почему не slf4j over log4j2? Просто подход slf4j очень классный — мы даём вам api для логирования, а движок это вообще не наше дело. И slf4j стал уже негласным стандартом для множества проектов...
Конечно нет, все разделы — сплошное 0600 и доступны исключительно руту.
Винды под рукой нет, но что-то такое должно сработать:
btw с
+shortиграть удобнее:И всё это обходится банальным Magisk (ну ладно, отладку и usb он не спрячет, но рут приложение не найдёт, зато пройдёт SafetyNet).
А вообще это дико раздражает, когда кто-то за меня решает, что и как я должен делать на моём устройстве.
Кажется Вас сильно обманули.
От «китайцев» надо защищаться не банальным прятаньем порта, а по-взрослому.
На почтовый сервер (на котором я не могу сменить порт по очевидным причинам) мне сыпется несколько десятков разных «китайцев» и прочих в минуту — приходится жить и обучать сервер отправлять отлупы таким товарищам.
Менять не всегда получается — иногда нужен именно 22 порт (банально для «красивых» url, без указания порта).
Экспериментальное с точки зрения именования классов, функций и прочего в библиотеке kotlinx.coroutines. Сами корутины протестированы достаточно (как с точки зрения юнит-тестов, так и проверены временем и продакшеном). И да, пользоваться kotlinx.coroutines гораздо удобнее в котлине, чем RxJava/RxKotlin. Ну, как минимум для меня. Хотя никто не запрещает, это да.
Rust и C++ считаются? :)
Дело не в том, что создаются как "неудобные", а в том, что "удобство" это одна из первоочерёдных задач.
По сравнению с public частью — всё-таки "чуть".
Да OOM может вылететь от каждого оператора new, SOE может вылететь от каждого вызова функции — теперь что, оборачивать всю программу в try-catch? Kotlin не отбирает возможность определения throws, как и отлова исключений.
Вы меня не поняли. Я не скатывался в стиле "ниасилил", я сам через это проходил. После нескольких лет Java Kotlin (особенно до версии 1.0 и в некоторых моментах до 1.1) выглядел… мягко говоря непривычно. Я плевался чуть ли не от каждой фичи, которая была сделана не так, как в Java просто потому, что всё не Java, кроме Java. Я не понимал, почему авторы сделали то-то и то-то, от того отказались, заменили на то-то. Мне понадобилось некоторое время для изучения stdlib и других библиотек чтобы осознать, как стоит писать на Kotlin и почему не надо бездумно копировать практики с Java просто потому, что это тоже JVM язык.
Вам показалось. Kotlin создавался как удобный, прагматичный язык, и описанные вами возможности авторы языка посчитали ненужными и отвлекающими от разработки.
Собственно, почему вам не хватает
internal? Да, это область видимости чуть больше, чемpackage-private, но и проблем с ним меньше.А о исключениях можно спорить вечно… Кто-то считает, что обязательно должны быть проверяемые исключения и компилятор должен насиловать мозг на каждый чих, кто-то считает, что исключения — это зло (как минимум, в том виде, какие они в Java). Правда как всегда где-то посередине.
Как мне показалось из статьи, у Вас мозг "отформатирован" под Java и ещё не до конца осознал Kotlin, это всё-таки не просто Java-с-плюшками, это другой язык, хоть у него и хороший интероп с экосистемой Java.
Вы знаете, так сказать можно про что угодно.
Он гей? Вот же ёбнутый.
Он гречку не ест? Вот же ёбнутый.
Он не любит Spring? Вот же ёбнутый.
Попрошу воздержаться от брани и если отвечать, то по делу.
Если дело в logback, то тогда почему не slf4j over log4j2? Просто подход slf4j очень классный — мы даём вам api для логирования, а движок это вообще не наше дело. И slf4j стал уже негласным стандартом для множества проектов...
Как сказал Андрей Бреслав, это не "разреши", а "отвали" :)