Сделал попытку переехать на мозилу буквально два месяца назад. Через месяц вернулся на хром. Нереально пользоваться после хрома.
Во-первых саму многолетнюю привычку трудно ломать, а тут ещё высыпаются косяки, о которых ты раньше даже не думал.
Например из последеног - бывает что кликаешь по веб элементам (конкретно запомнившийся пример - селф-хостед ютрак) и ничего не происходит и не понятно почему. Перезагружаешь страницу, вроде получается попользоваться какое-то время, потом что-то происходит и страница "отмирает". В хроме без нареканий работает.
Или PIA расширение. Иногда бывало что при включенном PIA и VPN (PIA или само развернутом), интернет страницы по какой-то причине переставали открываться. Опять же, открывая хром с соседнем окне и с теми же настройками всё работает.
Ну и хром побыстрее будет.
Приватность это конечно хорошо, но через день искать почему у тебя что-то отказывает в такой элементарной вещи (с точки зрения пользователя) как открытие страниц, для меня не приемлемо.
Несовсем понимаю вашу аргументы в пользу монорепы. Как разделение проектов по репозиториям влияет на врямя соборки?
Допустим есть продукт A и продукт B. A зависит от библиотеки CC, B также зависит от CC. И при этом A имеет еще одну библиотечную зависимость - DD.
Какой смысл держать A и B в одном репозитории если это разные продукты? Также зачем это делать для библиотеки вместе если они являются разными "сущностями" и подключаются под разные цели?
Когда библиотеки и продукты разделены по репозиториям, это грубо говоря добавляет "предохранитель" не сделать из кода трудно-интегриуемую мешанину.
Также, если у одного из продуктов есть зависимоть от конкретной версии библиотеки, то это можно легко сделать через пакетный менеджер, чтобы не билдить её каждый раз, что уменьшит время сборки.
Ещё, на мой взгляд странно, что когда сотрудник приходит условно в отдел по разработке антивируса, а ему надо тянуть гигабайты кода из репы и он сразу получает доступ ко всем остальным проектам.
На мой взгляд, монорепа в большом количестве масштабных проектов, это во-первых архитектурно неправильно, а во-вторых, это отложенное лечение мигрени в будущем.
В умение писать код я бы добавил навык написания юнит тестов. Во-первых, этот навык позволяет писать "unitable" код, что делает его более масшатабируемым и надежным. А во-вторых, написанные тесты, являются отражением того, на сколько разработчик "осознаёт" написанный код - проверка базовых сценариев, сложных сценариев, сценариев с пограничными условиями, итд.
Также в статье ничего не указано о работе с CMake и пакетных менеджерах. Считаю что эти навыки необходимы для того, чтобы создавать библиотеки, которые могут быть легко интегрированы в другие проекты.
У меня есть сомнения что крупные сети сделают замену поврежденного устройства. Особенно в текущих реалиях, когда за возврат дают по шапке персоналу. А тут еще возврат поврежденного устройства, не просто по причине "не подошло".
У Тинька по прежнему есть виртуальная карта. Правда она несколько отличается от той что была раньше. Теперь она всегда привязана к основному счету и есть какой-то лимит (кажется) по оплате с неё.
Спасибо за статью!
AFL и libFuzzer имеют один и тот же принцип, но компилируются разными компиляторами. Существуют-ли кейсы когда лучше использовать один вместо другого?
По мне так, основной недостаток это отсутствие дебаггера, скорость анализа. Интерфейс гидры несомненно требует тренировок — отлИчные от ИДЫ хоткеи и новое окошко на каждый открытый пункт меню — это вообще неудобно. В ИДЕ гораздо удобнее это реализовано через tab-control-ы.
Может кто-то упустил — демо версия IDA-ы теперь поставляется с x64 декомпилятором. Если у вас нет непубилчной электронной почты — можно воспользоваться сервисом для генерации email адреса на 10 минут. Хватит чтобы получить письмо по реквесту и скачать демку.
Есть в планах распространять книгу через ЛитРес? Т.к. там очень удобно структуировать свою библиотеку, делать заметки, да и вообще просто использовать сервис как читалку, то стараюсь всю литературу приобретать в этом магазине.
Debain: Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux DE: X11/Gnome/Gnome on Waynalnd. QtCreator: 4.6.1 (Based on 5.10.1; Built on May 2018; 64 bit).
Скачивал с оф. сайта последнюю версию и регулярно обновляюсь через maintenance tool.
Запускать пробовал из под всех DE. Находил на баг трекере таск про HiDPI — рекоммендуют запускать с флагом -platform wayland.
Получаю ошибку что wayland плагин не установлен: This application failed to start because it could not find or load the Qt platform plugin «wayland»
in "".
Пытался поставить, в результате похерил DE и пришлось в рекавери-моде восстанавливать всё что натворил. Подробно проблему описывал на тостере, но не получил рекоммендаций.
Имею модель 9350. Дизайн бука, ход клавиш просто кайф! Испольую Debian. Из минусов могу упомянуть:
0. Беспроводной модуль. Заказал intel-овский, т.к. на бродкомом с трудом настроил wi-fi, а
bluetooth так и не поднялся. Почитал на форумах — почти все меняют на intel.
1. Купил внешний usb-c адаптер (ethernet, usb, hdmi) и при подключении внешнего монитора словил No Signal. При этом в dmesg видны сообщения об ошибках при подключении адаптера. А вот на Kali подключение прошло без проблем. Хотя оба дистра на дебиане.
2. Проблемы некоторых приложений с большим расширением. Ставишь ось — вроде всё чинно. Запускаешь барп-сьют или qt-creator — всё очень мелко. Барп тюнится в настройках приложения. QtCreator только посредством запуска через wayland или передачей параметров масштабирования при запуске IDE.
К слову сказать так и не смог настроить запуск через Wayland. Если кто-то имел опыт, был бы признателен за небольшой ликбез или туториал.
Сделал попытку переехать на мозилу буквально два месяца назад. Через месяц вернулся на хром. Нереально пользоваться после хрома.
Во-первых саму многолетнюю привычку трудно ломать, а тут ещё высыпаются косяки, о которых ты раньше даже не думал.
Например из последеног - бывает что кликаешь по веб элементам (конкретно запомнившийся пример - селф-хостед ютрак) и ничего не происходит и не понятно почему. Перезагружаешь страницу, вроде получается попользоваться какое-то время, потом что-то происходит и страница "отмирает". В хроме без нареканий работает.
Или PIA расширение. Иногда бывало что при включенном PIA и VPN (PIA или само развернутом), интернет страницы по какой-то причине переставали открываться. Опять же, открывая хром с соседнем окне и с теми же настройками всё работает.
Ну и хром побыстрее будет.
Приватность это конечно хорошо, но через день искать почему у тебя что-то отказывает в такой элементарной вещи (с точки зрения пользователя) как открытие страниц, для меня не приемлемо.
Несовсем понимаю вашу аргументы в пользу монорепы. Как разделение проектов по репозиториям влияет на врямя соборки?
Допустим есть продукт A и продукт B. A зависит от библиотеки CC, B также зависит от CC. И при этом A имеет еще одну библиотечную зависимость - DD.
Какой смысл держать A и B в одном репозитории если это разные продукты? Также зачем это делать для библиотеки вместе если они являются разными "сущностями" и подключаются под разные цели?
Когда библиотеки и продукты разделены по репозиториям, это грубо говоря добавляет "предохранитель" не сделать из кода трудно-интегриуемую мешанину.
Также, если у одного из продуктов есть зависимоть от конкретной версии библиотеки, то это можно легко сделать через пакетный менеджер, чтобы не билдить её каждый раз, что уменьшит время сборки.
Ещё, на мой взгляд странно, что когда сотрудник приходит условно в отдел по разработке антивируса, а ему надо тянуть гигабайты кода из репы и он сразу получает доступ ко всем остальным проектам.
Согласен что Я и ЛК это компании, которые являются предметом гордости и проф развития для тех специалистов.
На мой взгляд, монорепа в большом количестве масштабных проектов, это во-первых архитектурно неправильно, а во-вторых, это отложенное лечение мигрени в будущем.
На самом деле хорошо описано.
В умение писать код я бы добавил навык написания юнит тестов. Во-первых, этот навык позволяет писать "unitable" код, что делает его более масшатабируемым и надежным. А во-вторых, написанные тесты, являются отражением того, на сколько разработчик "осознаёт" написанный код - проверка базовых сценариев, сложных сценариев, сценариев с пограничными условиями, итд.
Также в статье ничего не указано о работе с CMake и пакетных менеджерах. Считаю что эти навыки необходимы для того, чтобы создавать библиотеки, которые могут быть легко интегрированы в другие проекты.
У меня есть сомнения что крупные сети сделают замену поврежденного устройства. Особенно в текущих реалиях, когда за возврат дают по шапке персоналу. А тут еще возврат поврежденного устройства, не просто по причине "не подошло".
Ozon, Softline, Mvideo. Конечно не 3.5к, но и далеко не 15-20.
При загрузке входных интерфейсов на 50% каждый, как долго DS Integrity NG будет работать без дропов? Допустим всплеск идет 2 часа.
На сколько я понимаю, DS Integrity NG содержит 8 входных интерфейсов, каждый имеет свой буфер. Какой обычно размер этого буфера?
С вашим подходом в бизнес точно лучше не ходить)
Уже идёте за долгами, а не за прибылью - это раз. Два - сразу начинаете оперировать очень большими суммами.
У Тинька по прежнему есть виртуальная карта. Правда она несколько отличается от той что была раньше. Теперь она всегда привязана к основному счету и есть какой-то лимит (кажется) по оплате с неё.
AFL и libFuzzer имеют один и тот же принцип, но компилируются разными компиляторами. Существуют-ли кейсы когда лучше использовать один вместо другого?
По мне так, основной недостаток это отсутствие дебаггера, скорость анализа. Интерфейс гидры несомненно требует тренировок — отлИчные от ИДЫ хоткеи и новое окошко на каждый открытый пункт меню — это вообще неудобно. В ИДЕ гораздо удобнее это реализовано через tab-control-ы.
DE: X11/Gnome/Gnome on Waynalnd.
QtCreator: 4.6.1 (Based on 5.10.1; Built on May 2018; 64 bit).
Скачивал с оф. сайта последнюю версию и регулярно обновляюсь через maintenance tool.
Запускать пробовал из под всех DE. Находил на баг трекере таск про HiDPI — рекоммендуют запускать с флагом -platform wayland.
Получаю ошибку что wayland плагин не установлен:
This application failed to start because it could not find or load the Qt platform plugin «wayland»
in "".
Пытался поставить, в результате похерил DE и пришлось в рекавери-моде восстанавливать всё что натворил. Подробно проблему описывал на тостере, но не получил рекоммендаций.
0. Беспроводной модуль. Заказал intel-овский, т.к. на бродкомом с трудом настроил wi-fi, а
bluetooth так и не поднялся. Почитал на форумах — почти все меняют на intel.
1. Купил внешний usb-c адаптер (ethernet, usb, hdmi) и при подключении внешнего монитора словил No Signal. При этом в dmesg видны сообщения об ошибках при подключении адаптера. А вот на Kali подключение прошло без проблем. Хотя оба дистра на дебиане.
2. Проблемы некоторых приложений с большим расширением. Ставишь ось — вроде всё чинно. Запускаешь барп-сьют или qt-creator — всё очень мелко. Барп тюнится в настройках приложения. QtCreator только посредством запуска через wayland или передачей параметров масштабирования при запуске IDE.
К слову сказать так и не смог настроить запуск через Wayland. Если кто-то имел опыт, был бы признателен за небольшой ликбез или туториал.