Как стать автором
Обновить
4
0

Архитектор и разработчик ПО

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

Было бы интересно почитать про параметры вашей связи на полюсе: ширина канала, стабильность, пинги, лимиты по трафику и т.д.

По поводу того, что авторы софта массово считают любой канал связи абсолютно надежным и быстрым - согласен. Чтобы почувствовать мучения пользователей не надо ехать на полюс, тут и в области можно такое же поймать на обычной сотовой связи.

Ну хорошо, Аэрофлоту еще может понадобиться brand awareness

Brand awareness работает когда за брендом стоит репутация владеющей компании. А у нас в 99.9% случаев репутацией никто не занимается, на нее активно забивают и пробивают ей очередные донья.

Вопросы все больше у вас "базовые", а в разработке случаются и вопросы чуточку посложнее.

Как посмотреть содержимое и откатить merge-commit?

Как узнать в какие ветки попал коммит (по хэшу)?

Как склеить не два рядом стоящих коммита, а скажем отстоящие друг от друга на 10 коммитов?

Как проверить наложится ли ваша ветка с изменениями в другую без конфликтов не сливая ее фактически (ну или откатив слияние)?

Как отредактировать измененные в коммите файлы (добавить, удалить, переименовать)?

Вообще, конечно все эти адреса и порты в логах в конце концов просто заменят номером паспорта и обязательно графой кем выдан (причем строго как написано в паспорте!), так что к чему эти полумеры с портами?...

Так и вижу формат протокола ГосTCP: паспорт откуда, паспорт куда (если иностранный ресурс - паспорт представителя в РФ), ну и т. д. Жалко в 4 байта номер паспорта не влезает, ну так тем быстрее на v6 перейдут.

Вы не влияете на то, как будут храниться ваши пароли, может с PKDF, а может открытым текстом и тогда вас не спасет даже 140 символов. Ну и про всякие искусственные ограничения на пароли (видимо для облегчения их взлома) - это тоже прямо беда. Решение пока только в том, чтобы жестко действовать по правилу: один сервис - один пароль. Минус в том, что надо заводить кучу паролей, и хранение их в менеджере паролей не всегда надежный выход - это становится единой точкой отказа с точки зрения безопасности.

Второе - ну хорошо, на нормальной клавиатуре можно вводить многосимвольные пароли со спецсимволами, а что делать на смартфонах? Вводить тамошней клавиатурой даже 16 символьный пароль - одно мучение. Речь именно про ввод, т. е. там где вставка из кармана не работает, например пароль на разблокировку телефона. Причем нормального решения нет, замена на биометрию - это не решение (да и не замена). Разве что носимые ключи безопасности на bluetooth/nfc могут что-то предложить, но их поддержка в телефонах на зачаточном уровне.

Я понимаю уникальные, знаменитые, отдельно стоящие, являющиеся достопримечательностями или местами встреч деревья на картах - это помогает ориентированию, но просто насыпать абстрактных моделей с условным расположением - зачем? Да даже этажность и тип (цвет) домов в городе помог бы в ориентировании больше. Или я чего-то не понимаю?

Переход в защищённый или x64 режим, убьёт возможность вызывать прерывания BIOS

Не убьет, просто это будет немного сложнее. Посмотрите исходники почти любого dos-extender'а, или dpmi-сервера, там именно это и реализовано: вызов прерываний из защищенного режима.

работать с периферией или ATA интерфейсом в теории

Работать с диском на низком уровне не так и сложно, но по сути это ведь не задача самой ОС - иметь драйвера для всего оборудования в мире. Задача ОС - иметь грамотные интерфейсы для поддержки разных классов оборудования и грамотно распределять ресурсы между пользователями (процессами). Тем более что процедуры работы с дисками условно говоря зависят от протокола диска и там мало где можно разгуляться, а вот в аллокаторе или в планировщике все еще можно придумать что-то оригинальное.

Сколько уже таких систем (по факту загрузчиков) было сделано? Понятно, что написать загрузчик прикольно, но до ОС еще очень далеко. Почему кстати выбрана именно 16-битная система и именно для x86 (а не 64-битная для ARM, например - всяко ж современнее и интереснее, разве нет)? И зачем всю систему писать на ассемблере?

Ждем следующих статей про основы собственно ОС, например про распределение ресурсов (процессора, памяти, времени и т.д.): как сделать скоростной планировщик, аллокатор памяти, как работать со временем или просто сделать банальное DPC/APC. Или вам больше интересна работа с железом на низком уровне?

Мне трудно сказать достоверно где останавливается загрузка при r/o emmc, гипервизор (как и scp и tinysys) как минимум пишут логи и ставят отметки в раздел emmc, но там понятное дело ничего нет. При обычной загрузке - отметки и логи есть, разумеется.

А как там это делать? В современных телефонах ядро грузится гипервизором, которому требуется запись в служебные разделы emmc, а пропатчить гипервизор нельзя, потому что проверяется его подпись (через tee). Так что до ядра с microsd дело даже не доходит.

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

В список недоступных телефонов надо добавить те модели, где вообще нет поддержки microsd карт, а таких приличное кол-во.

p.s. есть ли опыт загрузки с microsd на современных телефонах с андроидом >10, там где до загрузки собственно ядра происходит много чего интересного и уже требуется emmc на запись?

Все-таки os/2 была слишком завязана на архитектуру i386 - ее ведь так и не портировали никуда еще. Она использовала 3 кольца из 4-х (из того что я сам видел), TSS, вовсю переключала LDT для процессов, и имела даже в ядре (не говоря про драйвера) жуткую смесь 16 и 32-битного кода. Тем не менее это было прикольно, ни одна другая система не использовала именно так все возможности 386/486 на тот момент. Про потроха этой системы можно было бы целую статью написать, но сейчас это уже вряд ли кому-то будет интересно.

Вот просто интересно, а хоть один из подобных "исследователей" дожил до своих 80? А то чаще получается, что они всю жизнь проповедуют что-то, а потом хлоп - и все. И вера в подобные вещи уже сильно пошатнулась, потому что подтверждений от них мало, а прожившие реальную долгую жизнь зачастую и не знают ничего про "биохакинг" и прочие навороты.

Так ведь в приложение банка из-за границы без российского vpn и зайти нельзя зачастую.

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

В x86 запись IDT имеет 8 байт и называется воротами.

Дескриптором прерывания же. Даже по названию - Interrupt Descriptor Table (IDT).

Насколько я помню, нахождение самого оптимального (по числу умножений) алгоритма возведения в степень - это NP задача. Собственно, отсюда и так много способов, которые пытаются приблизиться к оптимуму для разных видов входных значений.

Да на любой простой задачке можно на собеседовании развернуть такую кучу вопросов, уточнений и даже придирок, что это ничем не будет отличаться от описанной. Так что задача может быть в принципе любой, главное это разговоры вокруг про условия, про способы решения, про ревью и тесты, про производительность и другие особенности ну и т. д.

Бесит не только сам бесконечный скролл, но и когда страница перегружается (не всегда самим пользователем) - непонятно как вернуться на место, где ты был? Сразу прыгнуть нельзя, и опять надо мотать непонятно сколько времени.

Есть же способ несколько повысить стойкость за счет скорости - применить несколько шифров "конкурирующих стран" условно подряд. Разумеется тут есть свои тонкости (разбиение ключа, не все режимы годятся и т.д.), но принцип вполне рабочий. Подробности есть у Шнайера.

1
23 ...

Информация

В рейтинге
4 713-й
Зарегистрирован
Активность

Специализация

Software Architect, Low level system programming
Lead
От 5 000 $
Git
English
Research work
Software development
Programming microcontrollers
Assembler
C
C++
Specialists recruitment
Interview