The key idea for SMS was to use this telephone-optimized system, and to transport messages on the signalling paths needed to control the telephone traffic during periods when no signalling traffic existed.
То есть раньше, а возможно и сейчас SMS передавались в служебных полях пакетов,
которыми и так нужно было обмениваться, то есть практически бесплатно для сотового оператора.
А то, что почти гигабайт ушёл в своп — не показатель качества продукта? Что можно аллоцировать в мессенджере на гигабайт и забыть про этот гигабайт?
Возможно имелись от'mmap'нутые файлы память. Черт знает как их менеджер задач на MacOsX показывает. ОЗУ для этих файлов конечно может использоваться, но по сути это здесь используется тот же механизм, что и в файлом кэше ОС, как только ОС нужно будет,
она может выкинуть страницы и вряд ли такое использование памяти можно зачесть как вину приложению.
Довольно странная статья, насколько я знаю "Software Developer" в авиации пишут все по спецификации проверенной и одобренной авиационными специалистами. См. например https://habr.com/ru/post/144686/. То есть очень сомнительно, что разработчики ПО могли принять решение о том со скольких и каких датчиков получать данные, и как вообще эта вся система должна работать.
Наверное с точки зрения JS разработчика весь остальной мир стагнирует.
Как можно завтракая не создать новый framework, потом начав работу и заварив чашку кофе не сделать +1 framework, потом пообедать и сделать +2 framework и т.д.,
очевидно что весь остальной мир падает в пучину стагнации и упадка.
Фейсбук, конечно, собирает информацию на пользователей и все об этом знают
но наезжать на него в ситуации, когда он вашу же жопу пытается прикрыть
Да ничего он не прикрывает. Его бизнес основан на сборе и продаже информации,
ну не будет он ее передавать/продавать правительству какой-то страны, ну и что?
Будет информацию покупать какая-нибудь французская фирма, которая принадлежит
тайваньской, которая принадлежит кипрской и т.д., а в конечном итоге на балансе спецслужб. Ну будет дороже, но деньги-то государственные, вряд ли конкретному сотруднику при составлении запроса на информацию будет дело до того, сколько это стоит.
И эти жесткие технари ( может быть человек 6 — 8 из разных отделов), начинают тебя выносить по разным техническим вопросам так,
В лучшем случае ты, представляющий себя стронг мидлом на деле оказался джуном+,
6-8 человек против одного? Больше похоже на поставленный на конвейер
метод по снижению планки зарплаты претендентов.
При этом насколько удобный планшет не совсем понятно, а таскать смартфон толщиной в
11мм — сомнительное удовольствие
На мой взгляд то что есть сейчас — передвижение от зарядки к зарядке не стоит маленького неудобства в виде толщины в 1см, и если в складном режиме такой телефон потребляет как телефон, а не планшет, но при этом имеет аккумулятор как у планшета, то это стоит доп. толщины.
Еще бы цену адекватную телефону, а не телефону+планшет...
Ну встраиваемая разработка, где еще и памяти мало, это не то на что стоит ориентироваться автору, а то попытка усидеть на двух стульях может печально закончится.
Из личного опыта. Для запуска юнит тестов (для С кода правда, но в данном случае это не принципиально) разработали собственный "framework". Каждый "testcase" компилировался в отдельный бинарник, линковщик выкидывал не нужное и поэтому (а также благодаря хорошей модульности) бинарники были достаточно маленькие чтобы не прошивать их на флешку, а загружать прямо в SRAM. А потом специальный скрипт по JTAG грузил сначала инициализатор периферии, а потом последовательно каждый testcase.
Очень сомнительно, что "test framework" общего назначения даже без использования кучи нам бы подошел.
Хотя это конечно субъективно, но я бы не стал заморачиваться пытаясь решить такие случаи. Нужно ведь и интерфейс как надергать "test case" в отдельные бинарники и и возможно в некоторых случаях вызывать в assert не std::abort/std::terminate, а бесконечный цикл с миганием лампочками и прочие странные и специфичные вещи.
Без подробного сравнения с google test/boost test выглядит не очень интересно.
Потому что "на вскидку", без подробного анализа сложно понять насколько это нужные изменения, а вот насколько все ухудшилось видно сразу.
Поясню:
без макросов
Ошибки которые потенциально могут внести макросы, это "TestCase" не зарегистрируется и таким образом не запуститься или "assert" реализованный с помощью макросов не заметит ошибки. Честно говоря за > 10 лет опыта я такого ни разу не видел, но это конечно не аргумент, аргументом был бы анализ используемых макросов с описанием как можно было ошибиться в их использовании.
и динамической памяти
А какое количество TestCase нужно написать чтобы это стало заметно,
чтобы скажем запуск тестов замедлился бы время большее 1 секунды на современной машине?
Миллион, два? Существует ли в мире хотя бы один проект с таким количеством "TestCase".
Плюс на мой взгляд по приоритету важнее:
Сколько нужно кода чтобы описать testcase и написать assert. В вашем варианте я как понимаю нужно в два раза больше строчек кода на каждый testcase по сравнению со "стандартными"?
Сколько занимает запуск измененного testcase? То есть время компиляции+линковки+собственно время выполнения программы с юнит-тестами.
На первый взгляд время выполнения должно измениться в пределах погрешности,
а вот компиляция+линковка?
Возможно фильтрации testcase, запуск всех тестов название которых удовлетворяет регулярному выражению.
То есть если 1-3 у "test framework" одинаковы или лучше, то можно рассматривать "макросы" и "динамическую память", хотя если "лучше", то я бы и не стал смотреть на "макросы" и "динамическую память", а сразу бы стал использовать ваш "test framework".
Ну насколько я мало работал с Astra Linux, но хотелось бы заметить что
с ней поставляется DM — fly, с кучей приложений и все они собственная разработка авторов Astra Linux, см. например https://habr.com/post/250707/
Безликий опен-спейс на N-cотен людей. Впрочем как и у многих сейчас.
Чем тут хвастаться мне не понятно.
Гордится тут конечно нечем, но хотя бы не скрывают что условия у них откровенно паршивые для программистов. Можно просмотреть статью и сразу добавить их в черный список работодателей.
Ага, особенно забавно в свете:
То есть раньше, а возможно и сейчас SMS передавались в служебных полях пакетов,
которыми и так нужно было обмениваться, то есть практически бесплатно для сотового оператора.
Почему конечно? Просто вводите такую улицу yotCybKisvisgesyudd4
Возможно имелись от'mmap'нутые файлы память. Черт знает как их менеджер задач на MacOsX показывает. ОЗУ для этих файлов конечно может использоваться, но по сути это здесь используется тот же механизм, что и в файлом кэше ОС, как только ОС нужно будет,
она может выкинуть страницы и вряд ли такое использование памяти можно зачесть как вину приложению.
Исторически так сложилось или из-за проблем со Qt + Android,
решили под iOS писать на Swift?
А вы разве не используете Qt/QML на мобильных устройствах?
Довольно странная статья, насколько я знаю "Software Developer" в авиации пишут все по спецификации проверенной и одобренной авиационными специалистами. См. например https://habr.com/ru/post/144686/. То есть очень сомнительно, что разработчики ПО могли принять решение о том со скольких и каких датчиков получать данные, и как вообще эта вся система должна работать.
Зачем d-link, у asus тоже есть wifi роутеры.
Наверное с точки зрения JS разработчика весь остальной мир стагнирует.
Как можно завтракая не создать новый framework, потом начав работу и заварив чашку кофе не сделать +1 framework, потом пообедать и сделать +2 framework и т.д.,
очевидно что весь остальной мир падает в пучину стагнации и упадка.
Да ничего он не прикрывает. Его бизнес основан на сборе и продаже информации,
ну не будет он ее передавать/продавать правительству какой-то страны, ну и что?
Будет информацию покупать какая-нибудь французская фирма, которая принадлежит
тайваньской, которая принадлежит кипрской и т.д., а в конечном итоге на балансе спецслужб. Ну будет дороже, но деньги-то государственные, вряд ли конкретному сотруднику при составлении запроса на информацию будет дело до того, сколько это стоит.
Самая первая это ipchains, ее уже нигде нет.
6-8 человек против одного? Больше похоже на поставленный на конвейер
метод по снижению планки зарплаты претендентов.
А чем принципиально разработка под Android/NDK и iOS отличается от серверной?
Почему куча разработчиков под вышеперечисленные платформы пользуются кросс компиляцией, а те кто пишут серверное ПО не смогут этого делать?
На мой взгляд то что есть сейчас — передвижение от зарядки к зарядке не стоит маленького неудобства в виде толщины в 1см, и если в складном режиме такой телефон потребляет как телефон, а не планшет, но при этом имеет аккумулятор как у планшета, то это стоит доп. толщины.
Еще бы цену адекватную телефону, а не телефону+планшет...
mupdf вроде самая быстрая из opensource библиотек, смотрели в ее сторону?
Разве? Техас как бы намекает на то, кого они видят в качестве рабочих. И иммигранты из Мексики я думаю не откажутся сверхурочно поработать.
Ну встраиваемая разработка, где еще и памяти мало, это не то на что стоит ориентироваться автору, а то попытка усидеть на двух стульях может печально закончится.
Из личного опыта. Для запуска юнит тестов (для С кода правда, но в данном случае это не принципиально) разработали собственный "framework". Каждый "testcase" компилировался в отдельный бинарник, линковщик выкидывал не нужное и поэтому (а также благодаря хорошей модульности) бинарники были достаточно маленькие чтобы не прошивать их на флешку, а загружать прямо в SRAM. А потом специальный скрипт по JTAG грузил сначала инициализатор периферии, а потом последовательно каждый testcase.
Очень сомнительно, что "test framework" общего назначения даже без использования кучи нам бы подошел.
Хотя это конечно субъективно, но я бы не стал заморачиваться пытаясь решить такие случаи. Нужно ведь и интерфейс как надергать "test case" в отдельные бинарники и и возможно в некоторых случаях вызывать в assert не std::abort/std::terminate, а бесконечный цикл с миганием лампочками и прочие странные и специфичные вещи.
Без подробного сравнения с google test/boost test выглядит не очень интересно.
Потому что "на вскидку", без подробного анализа сложно понять насколько это нужные изменения, а вот насколько все ухудшилось видно сразу.
Поясню:
Ошибки которые потенциально могут внести макросы, это "TestCase" не зарегистрируется и таким образом не запуститься или "assert" реализованный с помощью макросов не заметит ошибки. Честно говоря за > 10 лет опыта я такого ни разу не видел, но это конечно не аргумент, аргументом был бы анализ используемых макросов с описанием как можно было ошибиться в их использовании.
А какое количество TestCase нужно написать чтобы это стало заметно,
чтобы скажем запуск тестов замедлился бы время большее 1 секунды на современной машине?
Миллион, два? Существует ли в мире хотя бы один проект с таким количеством "TestCase".
Плюс на мой взгляд по приоритету важнее:
На первый взгляд время выполнения должно измениться в пределах погрешности,
а вот компиляция+линковка?
То есть если 1-3 у "test framework" одинаковы или лучше, то можно рассматривать "макросы" и "динамическую память", хотя если "лучше", то я бы и не стал смотреть на "макросы" и "динамическую память", а сразу бы стал использовать ваш "test framework".
Ну насколько я мало работал с Astra Linux, но хотелось бы заметить что
с ней поставляется DM — fly, с кучей приложений и все они собственная разработка авторов Astra Linux, см. например https://habr.com/post/250707/
Потому что опен-спейс. Может я конечно и зажрался, но не представляю
как в таких условиях можно работать на 100% возможностей.
Гордится тут конечно нечем, но хотя бы не скрывают что условия у них откровенно паршивые для программистов. Можно просмотреть статью и сразу добавить их в черный список работодателей.