Как стать автором
Обновить
1
0
Владимир @fRoStBiT

Разработчик

Отправить сообщение

И с Java 8 только один из них правильный

Если же Сomparable не присутствует, то Java использует identity hash
code объектов для того, чтобы разрулить неоднозначность, чтобы
определить, какой из объектов меньше какого.

Не очень понимаю, как потом что-то искать в таком дереве, если ключ - identity hash code. Всё равно придётся перебирать его полностью, чтобы найти элемент, равный по equals().

Только сверив отпечаток общего ключа. Телеграм это позволяет, но сам этот процесс требует общения Васи и Коли по какому-то каналу, до которого не доберётся Петя. Например, при личной встрече.

Интересная мысль, но в Java перестали пытаться сделать "безопасность" внутри процесса JVM, ибо всё равно получается дыряво. В Java 17 уже сделали то же самое с SecurityManager, а до этого - с апплетами, JWS и прочим подобным.

Не очень понятно, от кого защищается такая "безопасная библиотека".

А что, специализация на фронтенде или бэкенде ставит на человеке как "софтверном инженере" крест?

Странное противопоставление, как по мне. Описанное в статье больше похоже на фуллстека.

Я думаю, что всё-таки задумка этого репозитория — письмо против RMS, а не обсуждение, с чего бы это вообще делать.
И лично я, даже не общаясь с автором, почему-то изначально был уверен, что его цель — совсем не борьба с дискриминацией.

Issue в чьём-то репозитории вполне могут закрываться по желанию левой пятки его владельца. В сообществе не принято так себя вести, но никаких формальных препятствий так делать нет.
Я вам больше скажу: в данном случае это даже не оттолкнёт потенциальных контрибьюторов. Тех из них, которые пришли ставить свою подпись рядом.
Моя мысль проста: надо воевать по-другому, не на их территории. Например, созданием рядом на том же гитхабе письма в поддержку противоположной стороны, что уже и сделано.

В блок лист, конечно же, мы же не расисты

Ну как бы ожидаемо, что людям, собирающим подписи за свою позицию, нет никакого дела до противоположной стороны. Не согласны — пишите своё письмо :)

А есть ли смысл использовать AES-256? 128 уже не считается устойчивым?

А ещё в том, когда и как это делать правильно.

Не нашёл ответа на вопрос в статье. А вот ожидаемый холивар в комментах нашёл.

О, точно, можно же так делать. Да, получилось бы плохо.
Ох уж эти промахи прошлого.

в сигнатуре write() есть throws IOException

Интересно, что мешало в BAOS переопределить write(byte[]) так, чтобы он не мог кидать исключение.

VM не вставляет в код никаких проверок

И интерпретатор, и JIT — это часть VM.


отдает каждому по несколько сотен/тысяч тиков

Если это не интерпретатор с циклом (а я думаю, JIT там есть), то нельзя взять и отдать коду N тиков, можно только сделать этот код таким, что он будет сам их считать. И насколько я знаю по беглому изучению этой темы, в BEAM "тиком" считается вызов функции.


Угу, половина стандартной библиотеки эрланга — NIFs, и ничего, планируются как миленькие.

Код на C будет считать "тики" только если делать это явно. Наверняка в стандартной библиотеке так и делается. Возьмите любую левую либу и она вам запросто подвесит всё.


заблокировал одно из ядер на пять минут, пока он файл до конца не вычитает

Ну во-первых, в худшем случае блокируется не ядро CPU, а поток ОС, а во-вторых, освобождать его на время IO как раз таки умеет любой нормальный рантайм с green thread'ами.
То, что BEAM при этом ещё и хорошо справляется с тяжёлыми вычислениями на CPU без ущерба для latency — это несомненно очень хорошая фича. Но и без этого можно жить. Про Go не скажу, но например в Kotlin для этого есть средства. Но да, об этом надо подумать разработчику, и да, рано или поздно он подумать об этом забудет. Но везде можно выстрелить себе в ногу, это лишь одна из возможных ошибок, при том не самая фатальная.

Я бы не стал называть подход, когда VM вставляет в код неявные проверки "не пора ли переключиться на планировщик", вытесняющей многозадачностью.
Код, выполняющийся в потоке, сам отдаёт управление планировщику, кооперативно. И если например в этом потоке в данный момент выполняется какой-нибудь код на C, ничего не знающий про BEAM, не будет никакого переключения.


Да, это позволяет снизить latency, но эти проверки не бесплатны. И разработчик не может сказать VM: "вот тут проверяй, а тут и так сойдёт".


думают, что грин-треды — это не болото, которое повиснет намертво при первом удобном случае

Я думаю, что это — инструмент, которым надо уметь пользоваться и знать его ограничения. И кстати то, что сделано в BEAM, тоже можно назвать грин-тредами.

В вытесняющую многозадачность умеет только шедулер ОС, вот только проблема в том, что он медленный. Поэтому и используются "грин-треды", которые так не умеют, зато быстрее.

ложное впечатление, будто он на самом деле проверяет список на наличие только целых чисел в нём

Но ведь это ничем не отличается от явного приведения:


final var intList = (List<Integer>) list;

Тоже создаёт "ложное впечатление, будто он на самом деле проверяет список на наличие только целых чисел в нём", ведь обычно приведение типа это делает (с массивами например).

Note: A.java uses unchecked or unsafe operations.
Похоже, опять придётся полагаться на инспекции в IDE.

Поведение идентично unchecked cast, и реакция компилятора соответствующая, так что никаких проблем нет. Предупреждения компилятора надо всё-таки читать.

Она еще про способы распространения отозванных сертификатов.

Да, но это всё равно не совсем работает (см. https://habr.com/ru/post/332730/).


В условиях, когда Telegram не использует TLS, тащить x509 смысла немного. SSH например тоже работает напрямую с ключами.

Враппер обычно идёт вместе с проектом. На Linux и macOS можно обращаться напрямую. На Windows — вызывать вместо враппера bat-файл.

А чем по-вашему принципиально отличается sh-скрипт gradlew для Unix-подобных ОС и gradlew.bat для Windows?


А долгая сборка обычно вызвана не Gradle, а тем большим объёмом работы, которая делается при сборке типичного Android приложения. При сборке руками в лучшем случае будет то же самое. Сам Gradle уже давно не тормозит.
Если не свызываться с Android, всё работает быстро и стабильно.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность