Справедливости ради устройства с максимум 21/22 уже тоже в основном хлам.
В исключения можно записать наверное только китайцев с большими батарейками, которые и имели шансы дожить, и не получили ничего более нового из-за Mediatek.
Тот же Firefox с официальным (от Mozilla) расширением Container Tabs. Поддержка контейнеров, к слову, пророщена еще в ряд популярных расширений, так что пользоваться ими довольно приятно. Жаль только на Android их нет и вряд ли будут.
Но про одновременный запуск firefox, я у себя держу несколько инстансов, первый запускается обычным образом, второй напрямую через путь в `--profile`и с указанием кастомного WM_CLASS (чтобы в этих моих линуксах окна не группировались и иконка была другая).
С browser fingerprinting сложнее, что-то можно решить с resistFingerprinting в about:config (осторожно, штука очень злая и ломает ряд сайтов), что-то аргессивными конфигами CanvasBlocker и подобным, но чтобы достаточно уверенно закрыть, (пока) хороший вариант это несколько разных железок (и желательно несколько аплинков)
Я бы не сказал, что чаще, примерно 50/50. А те, кто раньше клал 5V/1-2A, сейчас могут и вовсе никакой не положить.
Хотя конечно в комплектной зарядке телефона не будет 45/65Вт, но и сам телефон вряд ли столько примет.
На мой взгляд для телефона с PD оптимальны такие, у которых есть и нормальные PD (в т.ч. с ноутбучными 65Вт), и какие-нибудь (неподдерживаемые телефоном) QC, так чтобы в них можно было "медленно" заряжаться если некуда спешить
В мире Android (пока) нет принудительной подписи кода у платформодержателя. Подписывает сам разработчик. Ну или гугл при добавлении в стор, но это пока opt-in (или может уже opt-out стало...)
В смысле аутентичности подписавшего можно, конечно, доверять владельцу стора (как раньше бы доверяли гуглу).
Но можно пойти дальше, раздобыть .apk с официального сайта разработчика или старый рализ с Google Play (например, в бэкапах или на 4pda) и убедиться, что подписано тем же ключом
Гектор предположил, что это связано с поведением прошивки контроллера и тем, что она специально затачивалась под такое читерство с FLUSH
Судя по этому, скорее дело в дисках, чем в методологии. А если точнее, видимо даже в прошивках
А выводы примерно такие:
На макбуках всё скорее всего ОК, т.к. есть батарея, но потерю можно получить специальной командой USB-PD (теперь вредоносные зарядники угрожают ещё и ноутбукам)
На Mac Mini и iMac стоит использовать бесперебойник и беречь кабель питания. Это в принципе применимо и ко всем остальным компьютерам.
Если вам на macOS действительно нужно удостовериться в записи на диск, есть fcntl F_FULLSYNC.
Не стоит держать СУБД и прочий чувствительный к гарантиям и порядку записи на диск софт на маках и сомнительных SSD, если целостность данных критична.
Что касается маллока, то размер есть у системы. Вы уверены, что рантайм Си хранит этот размер?
Да, размер есть именно у аллокатора, который является частью рантайма. На каждую аллокацию маппить страницу памяти в здравом уме никто не будет. И ровно поэтому же система ничего не будет знать.
Ну вообще, теоретически, компилятор мог бы сам определять, а используется размер или нет и как оптимизацию не передавать туда, где не надо. Но во времена дизайна Си это было наверно не реализуемо. Да и философия не в том, что оптимизатор потом все лишнее уберет, а не вводить ничего лишнего, если не надо.
И именно это в современных реалиях осложняет как написание на Си безопасного и эффективного кода, так и его хорошую оптимизацию.
А что до "философии", то уже много лет оптимизирующие компиляторы с ней упорно борются, удаляя или эквивалентно заменяя то самое "лишнее". И судя по бенчмаркам и то и дело всплывающим историям с "оптимизациями UB", делают это они довольно успешно
Внезапно это намного более правда, чем вы предполагали. WebKit-like уже давно разделились на собственно WebKit (Safsri и несколько опенсорснцх браузеров) и Blink. Оптимизируют обычно под вторые. Firefox старается поддерживать стандарты и поведение вторых. А первые требуют дополнительных усилий по поддержке в плоть до того, что некоторые уже пару лет называют Safari "современным IE6"
Очень хорошее исследование. Прежде всего как показатель того, что на первый взгляд приемлемое исследование (с правдоподобной методологией, источниками, переиспользованием чужих данных и т.д.) на самом деле не имеет смысла, а уж когда до него доберутся журналисты...
Авторы даже не замеряли потребление хотя бы десятка репрезентативных устройств, не оценивали доступную информацию о серверной инфрастурктуре компаний.
Они взяли несколько способов оценки потребления энергии на проигрыаание видео, сеть и "работу датацентра", причем сами же пишут, что для одного авторы не указали, как именно они считали.
Хотелось бы знать, им не хватило квалификации понять, что без реальных данных (включая NDA компаний по отношению энергозатрат к просмотрам), результат получится ±мегаватт*час, или по старой научной традиции поняли, но решили, что и так сойдет, да кто ж признается.
Возможно, лучше в лицензию?
Такое, конечно, уже не будет Open Source (по крайней мере пока авторов Code of Conduct не пускают переписывать определения по OSI/FSF), но лицензия, если она у вас была свободная, хотя бы не будет противоречить readme.
Это гипотетрически может решить проблему поисковика, который выдает на первой странице мусор или бред по популярным запросам.
Это не решит проблему поиска, который ищет что-то не то, и тем более не решит проблему поиска, который отказывается искать по запросу вообще.
Пока у ISP есть SNI, их возможностям отслеживания ничего не грозит, а шифровать его повсеместно не дадут поборники прав детей и прочие борцы с "экстремизмами".
Но с другой стороны после прихода TLS у Google уже неоспоримо больше релевантной информации, пригодноц для таргетирования, чем у ISP:
Аналитика и ReCaptcha
Android и Firebase
YouTube и само собой поиск
Chrome
Возможность фингерпринтить пользователей по большему чем ОС и параметры TLS набору признаков
В конце концов возможность различать с большей достоверностью разных людей за одном пользовательским NAT
Валидный аргумент в ряде других случаев, но не здесь.
Youtube на Android требует Android 6 2015 года. Youtube на iOS требует минимум iOS 12 2019 года. Но возраст сравнимых устройств, на прошивках которых он бы запустился, сравнимый: iPhone 5S, LG/Google Nexus 5 (2013) и Galaxy S5 (начало 2014).
Так что если не брать бюджетные устройства и тем более китайские поделки с заведомо устаревшей на пару лет ОС, в смысле поддержки разработчиками все не так и плохо, а жалобы, что где-нибудь не поддерживается десятилетний 2.3, ну они будут
Так там ей и написано, "разыменуй NULL" "делай что угодно".
Вот только в понимании плюсов "делай что угодно" т.е. UB может записываться кучей подозрительно безобидных путей, образно, "адин плюс два" или "0дин плюс два" (с нулем вместо О).
Это ужасно, но это данность, пока мы не похороним Си и не выкинем легаси (вместе с половиной комитета) из плюсов
В исключения можно записать наверное только китайцев с большими батарейками, которые и имели шансы дожить, и не получили ничего более нового из-за Mediatek.
Но про одновременный запуск firefox, я у себя держу несколько инстансов, первый запускается обычным образом, второй напрямую через путь в `--profile`и с указанием кастомного WM_CLASS (чтобы в этих моих линуксах окна не группировались и иконка была другая).
С browser fingerprinting сложнее, что-то можно решить с resistFingerprinting в about:config (осторожно, штука очень злая и ломает ряд сайтов), что-то аргессивными конфигами CanvasBlocker и подобным, но чтобы достаточно уверенно закрыть, (пока) хороший вариант это несколько разных железок (и желательно несколько аплинков)
Я бы не сказал, что чаще, примерно 50/50. А те, кто раньше клал 5V/1-2A, сейчас могут и вовсе никакой не положить.
Хотя конечно в комплектной зарядке телефона не будет 45/65Вт, но и сам телефон вряд ли столько примет.
На мой взгляд для телефона с PD оптимальны такие, у которых есть и нормальные PD (в т.ч. с ноутбучными 65Вт), и какие-нибудь (неподдерживаемые телефоном) QC, так чтобы в них можно было "медленно" заряжаться если некуда спешить
В мире Android (пока) нет принудительной подписи кода у платформодержателя. Подписывает сам разработчик. Ну или гугл при добавлении в стор, но это пока opt-in (или может уже opt-out стало...)
В смысле аутентичности подписавшего можно, конечно, доверять владельцу стора (как раньше бы доверяли гуглу).
Но можно пойти дальше, раздобыть .apk с официального сайта разработчика или старый рализ с Google Play (например, в бэкапах или на 4pda) и убедиться, что подписано тем же ключом
Кому как, кто-то не понимает, кто-то пользуется почти всегда и двже покупает внешние клавиатуры с трекпоинтами.
На мой вкус очень удобно, но по умолчанию во всех ОС настроены безобразно и требуют настройки чувствительности под себя
Судя по мануалу для этого довольно давно используется pivot_root (2)
И эта зарядка может быть сделана через тот же порт Type-C. И он может как раз и быть единственным, если это был Macbook 12
А выводы примерно такие:
F_FULLSYNC.Да, размер есть именно у аллокатора, который является частью рантайма. На каждую аллокацию маппить страницу памяти в здравом уме никто не будет. И ровно поэтому же система ничего не будет знать.
И именно это в современных реалиях осложняет как написание на Си безопасного и эффективного кода, так и его хорошую оптимизацию.
А что до "философии", то уже много лет оптимизирующие компиляторы с ней упорно борются, удаляя или эквивалентно заменяя то самое "лишнее". И судя по бенчмаркам и то и дело всплывающим историям с "оптимизациями UB", делают это они довольно успешно
Внезапно это намного более правда, чем вы предполагали. WebKit-like уже давно разделились на собственно WebKit (Safsri и несколько опенсорснцх браузеров) и Blink. Оптимизируют обычно под вторые. Firefox старается поддерживать стандарты и поведение вторых. А первые требуют дополнительных усилий по поддержке в плоть до того, что некоторые уже пару лет называют Safari "современным IE6"
Очень хорошее исследование. Прежде всего как показатель того, что на первый взгляд приемлемое исследование (с правдоподобной методологией, источниками, переиспользованием чужих данных и т.д.) на самом деле не имеет смысла, а уж когда до него доберутся журналисты...
Авторы даже не замеряли потребление хотя бы десятка репрезентативных устройств, не оценивали доступную информацию о серверной инфрастурктуре компаний.
Они взяли несколько способов оценки потребления энергии на проигрыаание видео, сеть и "работу датацентра", причем сами же пишут, что для одного авторы не указали, как именно они считали.
Хотелось бы знать, им не хватило квалификации понять, что без реальных данных (включая NDA компаний по отношению энергозатрат к просмотрам), результат получится ±мегаватт*час, или по старой научной традиции поняли, но решили, что и так сойдет, да кто ж признается.
Возможно, лучше в лицензию?
Такое, конечно, уже не будет Open Source (по крайней мере пока авторов Code of Conduct не пускают переписывать определения по OSI/FSF), но лицензия, если она у вас была свободная, хотя бы не будет противоречить readme.
Это гипотетрически может решить проблему поисковика, который выдает на первой странице мусор или бред по популярным запросам.
Это не решит проблему поиска, который ищет что-то не то, и тем более не решит проблему поиска, который отказывается искать по запросу вообще.
Пока у ISP есть SNI, их возможностям отслеживания ничего не грозит, а шифровать его повсеместно не дадут поборники прав детей и прочие борцы с "экстремизмами".
Но с другой стороны после прихода TLS у Google уже неоспоримо больше релевантной информации, пригодноц для таргетирования, чем у ISP:
Валидный аргумент в ряде других случаев, но не здесь.
Youtube на Android требует Android 6 2015 года. Youtube на iOS требует минимум iOS 12 2019 года. Но возраст сравнимых устройств, на прошивках которых он бы запустился, сравнимый: iPhone 5S, LG/Google Nexus 5 (2013) и Galaxy S5 (начало 2014).
Так что если не брать бюджетные устройства и тем более китайские поделки с заведомо устаревшей на пару лет ОС, в смысле поддержки разработчиками все не так и плохо, а жалобы, что где-нибудь не поддерживается десятилетний 2.3, ну они будут
Settings -> Tabs -> Ctrl+Tab cycles through tabs in recently used order
За них Tom Scott уже сделал шедевр. Немного подправить устаревшие за годы формулировки, и можно выпускать
Так там ей и написано,
"разыменуй NULL""делай что угодно".Вот только в понимании плюсов "делай что угодно" т.е. UB может записываться кучей подозрительно безобидных путей, образно, "адин плюс два" или "0дин плюс два" (с нулем вместо О).
Это ужасно, но это данность, пока мы не похороним Си и не выкинем легаси (вместе с половиной комитета) из плюсов
Похоже, но не совсем
В таком случае они потеряют reproducible builds, которые они добавили в ответ на подозрения возможных бэкдорах в билдах из магазинов приложений