Вроде только с расширениями, например вот https://gcc.godbolt.org/z/8_907h, для msvc будет по-другому.
Кстати, в случае с++ тоже есть нюанс, который иногда стоит иметь ввиду. Обычный static const int foo = 1 — попадет в .rdata секцию, и будет реально защищена на запись, а динамическия = foo() — работает через тот же механизм, что и си с расширением, и попадет в .data без защиты.
Только при установке и весь скандал в том, что галочка выставлена по умолчанию, тоесть можно отослать случайно. Сама репортилка открытая https://github.com/ubuntu/ubuntu-report и генерит json на килобайт. Так что пока с виндой это никак не сравнить, где только адресов отсылки сотни.
Возможно, но задание в шедулере тоже есть, и он проходится по всем файлам судя по procmon/filemon Марка Руссиновича. Что на hdd может быть очень заметно и сильно влияет от кол-ва файлов и фрагментации.
При этом многие процесса реально не замечают, к дисковой активности они привыкли, а на hdd загрузка CPU может быть не заметна. Так же мне показалось, у него есть некая эвристика, когда скан приостанавливать, но работает она не всегда.
Ну одно из вероятного я предположил. Сейчас многие приложения используют либы удаленного управления, для раскатки части фич не на всех пользователей, тюна всяких параметров удаленно тип. Возможно тут что-то подобное. Может он он настраивается так что включается буквально на секунду, например. Но эта логика нам неизвестна.
Тогда у меня нет других идей кроме как он управляется удаленно и вам повезло. Я везде его вижу, и справился только мониторингом и автоудалением. При этом пиршлось изрядно так подломать систему, один раз даже уронил — появлялось окошко что система повреждена и отсчет до перезагрузки и так по кругу.
Тем не менее многие видели и жалуются, и никакие галочки телеметрии на скан не влияют. МС отписывается пространными фразами:
The CompatTelRunner.exe file is a Microsoft Compatibility Telemetry file found in your C:\Windows\System32 folder. In order to keep Windows devices secure and improve the quality of its services, Microsoft uses Telemetry to collect system data and information. The CompatTelRunner.exe file is also used to upgrade your system to the latest OS version and install the latest updates.
About your query in getting rid of the system file completely, we'd like to inform you that this is enabled by default and considered as part of the required Windows services since it gets installed every time your system downloads a new update. This is also the main reason why you can only disable it in your Task Scheduler as it ensures compatibility if you want to update to the latest version of Windows.
А если надавливают — показывают как отключить в таск шедулере… до следующего апдейта. Потом все восстанавливается и это не баг.
На десктопе, где у меня несколько HDD обычных вместе с SSD, процесс и вовсе идет субъективно часы, но и CompatTelRunner ест при этом не так много CPU как на макбуке или Dell XPS. Так что в целом я понимаю обе стороны, и тех кто на буке с SSD его не замечал т.к. процесс идет интенсивно и быстро + может сливаться с загрузкой, и тех кто на это натыкается и вызывает острую реакцию.
Скорее всего человеку тормозило систему не только обновления. Но и всякие .net фоновые компиляции, которые запускаются не регулярно. Его затреггирить может не только обновления, но и например установка игрушки, и штатно отключить нельзя насколько я знаю.
Но на такие штуки надо еще попасть, а вот в топе проблемы имхо — CompatTelRunner.exe. Он периодически сканирует все файлы на всех винтах. Я пробовал отключать, менять права и удалять — но он восстанавливался при апдейтах. МС подтвердило что отключить его нельзя и он само-восстанавливается https://answers.microsoft.com/en-us/windows/forum/all/windows-compatability-telemetry-compattelrunnerexe/bfa4d769-c539-43dc-b816-53d6c5647bbd .
We appreciate your prompt response and feedback regarding this matter. Since Windows Compatability Telemetry (CompatTelRunner.exe) gets enabled during a new download of Windows update and removing it completely is currently not possible, we suggest that you consult this directly to our IT pros from TechNet for an in-depth troubleshooting.
И в интернете полно жалоб на него. А если сойдутся сразу несколько таких процессов — ситуация усугубится, что даже топовый макбук c SSD внезапно тупит пару минут. И чем больше файлов на компе — тем заметнее CompatTelRunner.
Когда я фаззил кодеки, AFL быстрее находил баги (видимо более рандомно распределяет комбинации инпута), а libFuzzer как будто работает дольше (видимо больше комбинаций проверяет). Может это потому, что AFL смотрит что внутри экзешника что-то стриггерилось (у него там мапа специальная есть) и начинает эти места лучше проверять, делает ли так-же libFuzzer я не вкурсе.
Про бинарник, который попадет в репу и будет тащить все динамически из нее, в репах таких хватает. Просто вы в основном API проблемы описываете, а ABI проблема тут крайне редко возникает (хотя я сталкивался), обычно это бывает если в git выкладывают предкомпиленые либы, вручную собранные.
Все верно, я и сам пакую и тащу все статически, для универсальной сборки, которую можно скачать, и запускать неизвестно где. Для винды тоже так делаю, даже с redist не люблю связываться. Вот для flatpak/snap можно указать core вполне, с проблемами пока не сталкивался. А вот в репе — можно и собрать, тянув все динамически. Если говорить именно про ABI — оно просто не соберется иначе, проблему сразу будет видно. И в репах таких приложений тоже хватает.
Не вы, у разработчиков приложений появится такая возможновть, если либа поддержит динамическую линковку. А если динамическия линковка — почти всегда нужен ABI. Вот представьте: обновился в репе компилер — и хоба, прилетает вместе все 40гиг установки, потому что все надо собирать именно с этой версией. Ставите компилер из тестинг репы потому что вам надо? Ваши проблемы. А так, ментейнер возьмет либу, возьмет приложения, скомпилит в пакадж, проверит что все работает. И весь мир в апдейтах прилетать не будет. Вы можете эти приложения локально собрать, подцепив либу из репы, компилер будет другим наверняка, но работать будет и память будет шариться. Это все благодаря ABI и возможности совмещать модули. Все это разношерстная кампания, разные люди, у них разные системы, разные версии и им вот просто очень сильно надо уметь совмещаться внешне без пересборки мира.
К стаитческой линковке это тоже относится — иногда оно тоже надо, пример с Qt я выше приводил (забыл упомянуть что статически собирал). В дистрах статические либы тоже присутствуют. С ними точно так же желательно не ломаться как можно дольше.
Я вам пытаюсь показать кейс, когда ABI нужен, вы пытаетесь показать кейс где не нужен. Как это к rust относится? Я же конкретно про него пишу — не все либы используют и будут использовать совместимость с си, потому проблема ABI останется. Надо или на си ABI перейти для любой внешней комоновки, или свой стабильный сделать, и это реально очень надо.
Просто возьмите кейс где он нужен, а не статическую линковку qt-rs только к совему приложению. Например задейтесь целью зашарить его загрузку между несколькоми независимыми приложениями, контроля над которыми вы не имеете.
Это не редкие кейсы. Механизм совмещения — фича очень серьезная и используется повсемесно. Пирчем разные модули разрабытывают разные люди/команды/кампании. Связать все это очень важно. Например либу делает одини люди, а используют — другие, вы гарантируете что все либы это сделают, как предлагает khim? Получается я беру либу — проблема, еще беру — еще проблема. И что мне делать? А если все реально начнут делать #[repr(C)] и прочее необходимое, и других вариантов не будет — так проблемы тогда нет, тогда это и будет стабильный ABI для раста.
Вот вам еще пример: вот скомпилил я Qt под asan/tasn. Вот они у меня лежат и я их иногда использую. Мне вот очень не понравиться если все минорные обновления компилера начнут его ломать. Или если я не смогу слинковаться с либой из дистриба немного другим компилером, у мнея их вообще 2, clang и gcc, а в репе собиралось одним (причем точно не ими, потмоу что вот они обновились, а все остальное — нет). Понимаете масштаб проблемы?
Вроде только с расширениями, например вот https://gcc.godbolt.org/z/8_907h, для msvc будет по-другому.
Кстати, в случае с++ тоже есть нюанс, который иногда стоит иметь ввиду. Обычный static const int foo = 1 — попадет в .rdata секцию, и будет реально защищена на запись, а динамическия = foo() — работает через тот же механизм, что и си с расширением, и попадет в .data без защиты.
Кстати far2l --tty теперь тоже работает в консоли.
Собственно DWS это тоже делает, но список надо обновлять (утечке достаточно произойти 1 раз) + это ломает почти все MS сервисы.
Это про вот это https://www.bleepingcomputer.com/news/linux/ubuntu-reveals-desktop-telemetry-for-the-first-time/
Только при установке и весь скандал в том, что галочка выставлена по умолчанию, тоесть можно отослать случайно. Сама репортилка открытая https://github.com/ubuntu/ubuntu-report и генерит json на килобайт. Так что пока с виндой это никак не сравнить, где только адресов отсылки сотни.
Ну appimage версия 150мб весит, это не так много по сравнению с тем же фотошопом. А в количестве пакетов какой-нибудь libboost тоже штук 50 пакаджей.
Есть еще Krita, она как аналог нравится куда большему количеству людей насколько я знаю.
Есть еще простая утилита-обертка wondershaper для ограничения полосы.
Возможно, но задание в шедулере тоже есть, и он проходится по всем файлам судя по procmon/filemon Марка Руссиновича. Что на hdd может быть очень заметно и сильно влияет от кол-ва файлов и фрагментации.
При этом MFT встроенным дефрагментатором похоже что не дефрагментируется. Надо или создать новый раздел и на него все скопировать, или другие тулзы использовать https://superuser.com/questions/316003/how-do-you-defragment-the-mft-on-an-ntfs-disk .
При этом многие процесса реально не замечают, к дисковой активности они привыкли, а на hdd загрузка CPU может быть не заметна. Так же мне показалось, у него есть некая эвристика, когда скан приостанавливать, но работает она не всегда.
Ну одно из вероятного я предположил. Сейчас многие приложения используют либы удаленного управления, для раскатки части фич не на всех пользователей, тюна всяких параметров удаленно тип. Возможно тут что-то подобное. Может он он настраивается так что включается буквально на секунду, например. Но эта логика нам неизвестна.
Тогда у меня нет других идей кроме как он управляется удаленно и вам повезло. Я везде его вижу, и справился только мониторингом и автоудалением. При этом пиршлось изрядно так подломать систему, один раз даже уронил — появлялось окошко что система повреждена и отсчет до перезагрузки и так по кругу.
Тем не менее многие видели и жалуются, и никакие галочки телеметрии на скан не влияют. МС отписывается пространными фразами:
А если надавливают — показывают как отключить в таск шедулере… до следующего апдейта. Потом все восстанавливается и это не баг.
На десктопе, где у меня несколько HDD обычных вместе с SSD, процесс и вовсе идет субъективно часы, но и CompatTelRunner ест при этом не так много CPU как на макбуке или Dell XPS. Так что в целом я понимаю обе стороны, и тех кто на буке с SSD его не замечал т.к. процесс идет интенсивно и быстро + может сливаться с загрузкой, и тех кто на это натыкается и вызывает острую реакцию.
Скорее всего человеку тормозило систему не только обновления. Но и всякие .net фоновые компиляции, которые запускаются не регулярно. Его затреггирить может не только обновления, но и например установка игрушки, и штатно отключить нельзя насколько я знаю.
Но на такие штуки надо еще попасть, а вот в топе проблемы имхо — CompatTelRunner.exe. Он периодически сканирует все файлы на всех винтах. Я пробовал отключать, менять права и удалять — но он восстанавливался при апдейтах. МС подтвердило что отключить его нельзя и он само-восстанавливается https://answers.microsoft.com/en-us/windows/forum/all/windows-compatability-telemetry-compattelrunnerexe/bfa4d769-c539-43dc-b816-53d6c5647bbd .
И в интернете полно жалоб на него. А если сойдутся сразу несколько таких процессов — ситуация усугубится, что даже топовый макбук c SSD внезапно тупит пару минут. И чем больше файлов на компе — тем заметнее CompatTelRunner.
А почему AdoptOpenJDK тестировался только под Windows? Насколько я вижу его сборки есть под все платформы.
Там еще часть раст кода https://github.com/xiph/rav1e/tree/master/src/asm/x86 — unsafe функции из интринзиков.
Когда я фаззил кодеки, AFL быстрее находил баги (видимо более рандомно распределяет комбинации инпута), а libFuzzer как будто работает дольше (видимо больше комбинаций проверяет). Может это потому, что AFL смотрит что внутри экзешника что-то стриггерилось (у него там мапа специальная есть) и начинает эти места лучше проверять, делает ли так-же libFuzzer я не вкурсе.
Про бинарник, который попадет в репу и будет тащить все динамически из нее, в репах таких хватает. Просто вы в основном API проблемы описываете, а ABI проблема тут крайне редко возникает (хотя я сталкивался), обычно это бывает если в git выкладывают предкомпиленые либы, вручную собранные.
Все верно, я и сам пакую и тащу все статически, для универсальной сборки, которую можно скачать, и запускать неизвестно где. Для винды тоже так делаю, даже с redist не люблю связываться. Вот для flatpak/snap можно указать core вполне, с проблемами пока не сталкивался. А вот в репе — можно и собрать, тянув все динамически. Если говорить именно про ABI — оно просто не соберется иначе, проблему сразу будет видно. И в репах таких приложений тоже хватает.
Не вы, у разработчиков приложений появится такая возможновть, если либа поддержит динамическую линковку. А если динамическия линковка — почти всегда нужен ABI. Вот представьте: обновился в репе компилер — и хоба, прилетает вместе все 40гиг установки, потому что все надо собирать именно с этой версией. Ставите компилер из тестинг репы потому что вам надо? Ваши проблемы. А так, ментейнер возьмет либу, возьмет приложения, скомпилит в пакадж, проверит что все работает. И весь мир в апдейтах прилетать не будет. Вы можете эти приложения локально собрать, подцепив либу из репы, компилер будет другим наверняка, но работать будет и память будет шариться. Это все благодаря ABI и возможности совмещать модули. Все это разношерстная кампания, разные люди, у них разные системы, разные версии и им вот просто очень сильно надо уметь совмещаться внешне без пересборки мира.
К стаитческой линковке это тоже относится — иногда оно тоже надо, пример с Qt я выше приводил (забыл упомянуть что статически собирал). В дистрах статические либы тоже присутствуют. С ними точно так же желательно не ломаться как можно дольше.
Я вам пытаюсь показать кейс, когда ABI нужен, вы пытаетесь показать кейс где не нужен. Как это к rust относится? Я же конкретно про него пишу — не все либы используют и будут использовать совместимость с си, потому проблема ABI останется. Надо или на си ABI перейти для любой внешней комоновки, или свой стабильный сделать, и это реально очень надо.
Просто возьмите кейс где он нужен, а не статическую линковку qt-rs только к совему приложению. Например задейтесь целью зашарить его загрузку между несколькоми независимыми приложениями, контроля над которыми вы не имеете.
Это не редкие кейсы. Механизм совмещения — фича очень серьезная и используется повсемесно. Пирчем разные модули разрабытывают разные люди/команды/кампании. Связать все это очень важно. Например либу делает одини люди, а используют — другие, вы гарантируете что все либы это сделают, как предлагает khim? Получается я беру либу — проблема, еще беру — еще проблема. И что мне делать? А если все реально начнут делать
#[repr(C)]и прочее необходимое, и других вариантов не будет — так проблемы тогда нет, тогда это и будет стабильный ABI для раста.Вот вам еще пример: вот скомпилил я Qt под asan/tasn. Вот они у меня лежат и я их иногда использую. Мне вот очень не понравиться если все минорные обновления компилера начнут его ломать. Или если я не смогу слинковаться с либой из дистриба немного другим компилером, у мнея их вообще 2, clang и gcc, а в репе собиралось одним (причем точно не ими, потмоу что вот они обновились, а все остальное — нет). Понимаете масштаб проблемы?