На гифке - модуль ядра. Так что да, без суперпользователя, и доступа уровня ядра скорее всего не прокатит. Потому наверно это и не столько уязвимость и конец всему, а увлекательная разминка для мозгов.
Приёмщик формулирует задачу с измеримыми критериями.
Вот на этом пункте погорели гибкие методологии. Источник бабла по умолчанию предпочитает считать, что он платит за решение проблемы. А формулирование проблемы - задача исполнителя. А исполнитель - ждет вменяемого описания требований приемки до выполнения задач. В результате, все погрязли в бесконечных согласованиях еще на этапе начала работ.
Никто и никогда не досидит на своем месте до момента ухода платных клиентов из экспериментальной системы, чтобы дождаться стабильной. Стабильная система не нужна, потому что собрать сливки с инвесторов, первой волны пользователей или заключить контракты B2B на обслуживание достаточно для продвижения и спихивания проблем на следующих по кормовой цепочке.
Ценность наносекундной точности, сэкономленных байтов и 24\7\365(+1) работающего софта стремится к нулю, потому что на при фокусе на проинвестированного рост это не оказывает влияния на критичные бизнес-показатели.
Рабочий софт и статистически рабочий софт сравнялись по своей ценности для компании и инвесторов, которые есть единственные перед кем отчитывается компания и ради которых принимаются решения.
Именно так. Ну и не смущаясь утащу из вики "Microsoft announced in November 2005 that it would co-sponsor standardization of the new version of their XML-based formats through Ecma International as "Office Open XML".
Стандарты принимаются выходцами и сотрудниками коммерческих компаний, лоббируя интересы последних, или по умыслу, или по недомыслию.
Когда принимали OOXML все радовались, что избавятся от бинарных форматов MS Office, а по факту выяснилось, что внутри XML - бинарные блобы. Ну так стандарт то надо не только на презентациях оценивать, а например по референсной реализации, пусть медленной и неоптимальной, но полной. Тут конечно еще играет роль размер стандарта - 5к страниц не каждый осилит. Но что мешало декомпозировать до управляемого размера и принимать частями.
Аналогичная история случилась с видеостримингом. Приняли MPEG-DASH стандарт, а в нем явным образом 3 варианта одного и того же разрешено. Потому что 3 разных вендора законтрибутили свои хотелки. Хочешь реализовать стандарт - делай три раза одно и тоже по разному, иначе с кем-то да не заработает.
К слову - я сторонник ребейзов. И полезность мерджей в повседневной работе для меня сомнительна. Есть там специальные случаи, но в дев ветку - ребейз ван лав.
Получается, что описание диффа старое, а код в нем новый, но это является нормой в классическом подходе.
Нормой, но мне от такого очень больно. это иногда приводит к адскому аду впоследствии. Работая в своей ветке, автор уверен в правильности. При ребейзе с конфликтами не всегда конфликт решается с сохранением функционала и появляется сломанный коммит. Узнать об этом естественным способом очень затруднительно.
Смысл данного метода в моментальной оценке работы по исправлению конфликтов и максимальная экономия времени на исправление, это достигается за счет merge-а. При этом сохраняется вся оригинальная история коммитов и оригинальный код, даже если он уже устарел. Это подходит не всем, и тогда нужен обычный rebase.
Вот тут я не понимаю. В чем разница в целях разных ребейзов?
Для меня ребейз сам по себе - это стремление автора добавить свои новые доверенные изменения в самое актуальное состояние проекта, которое считается тоже доверенным. Как автор ветки я беру на себя ответственность не сломать апстрим. Что и кто в апстрим навливал - не так важно, я этому верю, и решаю конфликты как часть своей задачи, гарантируя, что моя история будет валидной. Оставить длинной или нет - дело частных предпочтений.
А в при необычном ребейзе предложенным способом - что именно содержит моя история до искусственного коммита после ребейза? Оригинальные коммиты нахлобученные на апстрим как есть - тогда это в моменте ломает апстрим. И сохранив историю, мы оставим непредсказуемо поломанные состояния. Другой участник проекта не будет ожидать что коммиты в апстриме могут в какой-то момент нарушить гарантию качества апстрима с восстановлением гарантии где-то позже по истории отдельным коммитом.
Я могу допустить, где ваш инструмент потенциально можно использовать - сквош мерж в апстрим с сохранением мерж коммита пустым. При мержах решение конфликтов остается в мерж коммите и создает сложности при поиске поломки, потому что создается как бы третье состояние неучтенное видимой историей. Если сделать вашим способом, то последние изменения окажутся в личном бранче в конце истории, и при сквош-мерже не вытекут в апстрим, сам бранч мог оказаться сломанным, но кого это волнует после сквоша.
Если я правильно понимаю, то скрипт помогает вычислить обратный дифф от безусловного ребейза с разрешением конфликтов в одну сторону, чтобы вернуть изменения, утерянные при выборе стороны.
По моему мнению, это вы предлагается отличный инструмент решения проблемы, возникшей из упущения целей и задач ребейза.
Ребейзы делают с какой-то конкретной целью. Чаще всего аккуратно и воспроизводимо слить атомарные изменения, чтобы сохранить историю. Это очень веская причина не создавать сломанные состояния проекта по дороге, которые починены последним искусственным обратным-дифф коммитом.
Если на каждом коммите конфликт - ну так можно сквошнуть ветку при ребейзе самой себя, или поребейзить несколько раз на свой рут, переставляя и редактируя контент для решения конфликтов правильно, и потом эту новую, но все еще полезную историю и пересадить, разрешив конфликты один раз в начале и оставив осмысленные коммиты.
P.S. Да не оскорбятся хранители чистоты языка за использование заимствований...
А в чем добавленная ценность Json-представления тех же свойств, что CMake штатно предоставляет? На мой взгляд, предложенный подход крайне избыточно решает проблему боязни копипасты, но никак не улучшает поддерживаемость или модульность проекта.
CMake достаточно многословный, и от проекта к проекту, от компонента к компоненты одни и те же функции будут использоваться постоянно. Я не вижу смысла в добавлении анемичной абстракции, и сопутствующего инструментария, если можно просто 100 раз использовать add_target, target_include_directories, etc... Боязнь дублирующихся параграфов - это не DRY. А в больших проектах, рано или поздно появится тот черный лебедь, на который эта абстракция не налезет из-за одного специального флага под Макось. И с этого момента начнется разложение и вонь системы сборки через добавление флагов, опций, аргументов и прочего тюнинга.
Помимо этого использовать CMake как скриптовый язык общего назначения хоть и возможно, но крайне неудобно из-за той же многословности.
Если хочется все-таки загнать себя в рамки предопределенной сборки компонентов, я бы использовал внешний лаунчер как точку входа для системы сборки, например шелл, или даже минимальный мейкфайл, который используя предложенные json описания сгенерирует нормальные CMakeLists.txt для каждого компонента используя более удобный инструмент - Jinja, Python, выберите любой приятный генератор по шаблонам. CMakeLists.txt верхнего уровня можно вручную написать с нужными опциями, или тоже генерировать. И только потом передавать сборку в руки собственно CMake, например даже с СMakePresets.txt. Использовать CMake для развертывания самого себя изнутри собственно проекта - это будет очень больно при поддержке кроссплатформенной сборки, создаст трудности по декомпозиции компонентов проекта от компонентов системы сборки, и увеличивает сложность в поддержке.
Я для себя нашел представление грамматики времен через свойства интервалов, о которых стоит думать при построении фразы.
Время действия - просто обычное время, когда что-то случается. Тут без сюрпризов - прошлое прошло, настоящее - тут вокруг нас, будущее - когда-то потом. Интуитивно, усложнять не надо.
Состояние процесса, выражаемого глаголом - тут уже аналогии подобрать сложнее, потому что архитектура русского языка не настолько явно опирается на эту сущность, хотя и прослеживаются некоторые сходства. Рассмотрим состояние процесса как часть временной шкалы. Это не то время, что в предыдущем пункте. Это времениподобное представление действия. Частью такой шкалы может быть точка или интервал, и интервал в свою очередь, может быть открытым и закрытым.
Требование связанных конструкций использовать определенную форму - на вскидку, разные Conditional, косвенная речь, придаточные предложения, модальности и долженствования, влияют на грамматику построения глагольной формы. Но ортогональны первым двум пунктам, и используются на продвинутом уровне, добавляя вспомогательные глаголы, или ограничивая временные и процессные варианты.
Используя эти три блока конструирование грамматической формы глагола выглядит как выбор определенного типа интервала временной шкалы на глобальной временной шкале и нахлобучиванием на нее дополнительного требования от связанных конструкции
Время -----------Past--------------<----Present---->-----------Future-------
Simple -----o-----------------------------------o------------------------o---
Continious ---------xxxxxxx---------------------xxxxxx---------------xxxx--------
Perfect ------------xxxx]---------------------xxxx]------------------xxx]-----
Perf.Cont. ---------[xxxxxx------------------[xxx-----------------[xxxx----------
Теперь когда мы хотим это использовать, задаем себе 2,5 вопроса - о каком времени идет речь, относительно моего текущего времени существования; какую форму процесса мы хотим передать - точку во времени, интервал, открытый с одного конца или другого; какую поправку надо внести на связанную грамматику.
И в обратную сторону аналогично, видя would had been drinking, понимает, что тут условность продолжающегося процесса, который тем не менее уже в прошлом и почти забыт.
А вот опытные эксперты, подскажите, есть ли какой-то DevOps инструмент для настройки парка техники, но более ориентированный на ментальную модель инженера-программиста, без вот этой вот развесистой малины ямлов, сотни папок с неочевидными функциями и многословностью, обусловленной тотальной и неконтролируемой расширяемостью? Не могу найти современный инструмент, который бы по элегантности превзошел шелл скрипты, мейкфайлы и немного магии .env.
Чтобы не тратить всуе лишнее процессороне время и не писать лишний код на разворот байтов это многобайтовое поле следует передавать в формате little-endian.
А микроконтроллеры чаще little-endian? Контринтуитивно передавать куда-то байты не в сетевом порядке байт.
А это не фазированная ли решетка на минималках? Продолжая пример с трибунами, при массовом фотографировании происходит же перенос общей картины трибуны параллельным способом. Чем-то похоже на фронт волны у фазированной антенны.
Раз 3,5мм джек отсутствует, можно ли авиапереходник использовать вместо него для подключения к обычному выходу гарнитуры\наушников. Что по функционалу в таком подключении - работает в режиме гарнитуры или только как наушники? Можно ли обычный USB-С на Джек адаптер использовать?
При подключении через USB, только подзарядка, или распознается как аудиоустройство? Что по функционалу оного?
При любом проводном подключении - что по активному шумодаву, работает ли вообще вся электронная начинка, или уши переходят в пассивный режим тупой гарнитуры(или вообще просто наушники) за 200 рублей?
При использовании, происходили ли баги, когда наушники переходят из аудиорежима со всеми наворотами в режим гарнитуры, портя качество звука в целом(известная родовая травма драйверов и аудиотракта Bluetooth), и застревают в нем до перезапуска. У меня на XM5 такое на MacBook происходит, если в видеозвонок подключаться, во время прослушивания музыки.
Что по влагозащищенности? XM5 даже под небольшим дождем нельзя носить, они дырявые.
Уши потеют, если спортом заниматься в наушниках? Насколько прочно сидят на голове для бега или наклонов например.
Заменить стандартный SQL вот на это - shared_trip_rate: (_.shared_match_flag == 'Y').mean() ? Онбординг новых сотрудников сразу перестает быть томным....
На гифке - модуль ядра. Так что да, без суперпользователя, и доступа уровня ядра скорее всего не прокатит. Потому наверно это и не столько уязвимость и конец всему, а увлекательная разминка для мозгов.
Вот на этом пункте погорели гибкие методологии. Источник бабла по умолчанию предпочитает считать, что он платит за решение проблемы. А формулирование проблемы - задача исполнителя. А исполнитель - ждет вменяемого описания требований приемки до выполнения задач. В результате, все погрязли в бесконечных согласованиях еще на этапе начала работ.
Никто и никогда не досидит на своем месте до момента ухода платных клиентов из экспериментальной системы, чтобы дождаться стабильной. Стабильная система не нужна, потому что собрать сливки с инвесторов, первой волны пользователей или заключить контракты B2B на обслуживание достаточно для продвижения и спихивания проблем на следующих по кормовой цепочке.
Ценность наносекундной точности, сэкономленных байтов и 24\7\365(+1) работающего софта стремится к нулю, потому что на при фокусе на проинвестированного рост это не оказывает влияния на критичные бизнес-показатели.
Рабочий софт и статистически рабочий софт сравнялись по своей ценности для компании и инвесторов, которые есть единственные перед кем отчитывается компания и ради которых принимаются решения.
О какой жизни речь в статье?
Slackware 15.0 х86 с Xfce. 350 Мб потребления на Aser Aspire One 1 GB DDR2 Ram, оставшееся - контроллер умного дома на Java в Docker.
Windows 11 IoT х64 на Asus M50Vn - Core2Duo+4GB DDR3. 1-5 вкладок в Хроме вполне рабочие для серфинга. Больше - свопает.
Понял, спасибо.
Именно так. Ну и не смущаясь утащу из вики "Microsoft announced in November 2005 that it would co-sponsor standardization of the new version of their XML-based formats through Ecma International as "Office Open XML".
Стандарты принимаются выходцами и сотрудниками коммерческих компаний, лоббируя интересы последних, или по умыслу, или по недомыслию.
Когда принимали OOXML все радовались, что избавятся от бинарных форматов MS Office, а по факту выяснилось, что внутри XML - бинарные блобы. Ну так стандарт то надо не только на презентациях оценивать, а например по референсной реализации, пусть медленной и неоптимальной, но полной. Тут конечно еще играет роль размер стандарта - 5к страниц не каждый осилит. Но что мешало декомпозировать до управляемого размера и принимать частями.
Аналогичная история случилась с видеостримингом. Приняли MPEG-DASH стандарт, а в нем явным образом 3 варианта одного и того же разрешено. Потому что 3 разных вендора законтрибутили свои хотелки. Хочешь реализовать стандарт - делай три раза одно и тоже по разному, иначе с кем-то да не заработает.
К слову - я сторонник ребейзов. И полезность мерджей в повседневной работе для меня сомнительна. Есть там специальные случаи, но в дев ветку - ребейз ван лав.
Нормой, но мне от такого очень больно. это иногда приводит к адскому аду впоследствии. Работая в своей ветке, автор уверен в правильности. При ребейзе с конфликтами не всегда конфликт решается с сохранением функционала и появляется сломанный коммит. Узнать об этом естественным способом очень затруднительно.
Вот тут я не понимаю. В чем разница в целях разных ребейзов?
Для меня ребейз сам по себе - это стремление автора добавить свои новые доверенные изменения в самое актуальное состояние проекта, которое считается тоже доверенным. Как автор ветки я беру на себя ответственность не сломать апстрим. Что и кто в апстрим навливал - не так важно, я этому верю, и решаю конфликты как часть своей задачи, гарантируя, что моя история будет валидной. Оставить длинной или нет - дело частных предпочтений.
А в при необычном ребейзе предложенным способом - что именно содержит моя история до искусственного коммита после ребейза? Оригинальные коммиты нахлобученные на апстрим как есть - тогда это в моменте ломает апстрим. И сохранив историю, мы оставим непредсказуемо поломанные состояния. Другой участник проекта не будет ожидать что коммиты в апстриме могут в какой-то момент нарушить гарантию качества апстрима с восстановлением гарантии где-то позже по истории отдельным коммитом.
Я могу допустить, где ваш инструмент потенциально можно использовать - сквош мерж в апстрим с сохранением мерж коммита пустым. При мержах решение конфликтов остается в мерж коммите и создает сложности при поиске поломки, потому что создается как бы третье состояние неучтенное видимой историей. Если сделать вашим способом, то последние изменения окажутся в личном бранче в конце истории, и при сквош-мерже не вытекут в апстрим, сам бранч мог оказаться сломанным, но кого это волнует после сквоша.
Если я правильно понимаю, то скрипт помогает вычислить обратный дифф от безусловного ребейза с разрешением конфликтов в одну сторону, чтобы вернуть изменения, утерянные при выборе стороны.
По моему мнению, это вы предлагается отличный инструмент решения проблемы, возникшей из упущения целей и задач ребейза.
Ребейзы делают с какой-то конкретной целью. Чаще всего аккуратно и воспроизводимо слить атомарные изменения, чтобы сохранить историю. Это очень веская причина не создавать сломанные состояния проекта по дороге, которые починены последним искусственным обратным-дифф коммитом.
Если на каждом коммите конфликт - ну так можно сквошнуть ветку при ребейзе самой себя, или поребейзить несколько раз на свой рут, переставляя и редактируя контент для решения конфликтов правильно, и потом эту новую, но все еще полезную историю и пересадить, разрешив конфликты один раз в начале и оставив осмысленные коммиты.
P.S. Да не оскорбятся хранители чистоты языка за использование заимствований...
А в чем добавленная ценность Json-представления тех же свойств, что CMake штатно предоставляет? На мой взгляд, предложенный подход крайне избыточно решает проблему боязни копипасты, но никак не улучшает поддерживаемость или модульность проекта.
CMake достаточно многословный, и от проекта к проекту, от компонента к компоненты одни и те же функции будут использоваться постоянно. Я не вижу смысла в добавлении анемичной абстракции, и сопутствующего инструментария, если можно просто 100 раз использовать add_target, target_include_directories, etc... Боязнь дублирующихся параграфов - это не DRY. А в больших проектах, рано или поздно появится тот черный лебедь, на который эта абстракция не налезет из-за одного специального флага под Макось. И с этого момента начнется разложение и вонь системы сборки через добавление флагов, опций, аргументов и прочего тюнинга.
Помимо этого использовать CMake как скриптовый язык общего назначения хоть и возможно, но крайне неудобно из-за той же многословности.
Если хочется все-таки загнать себя в рамки предопределенной сборки компонентов, я бы использовал внешний лаунчер как точку входа для системы сборки, например шелл, или даже минимальный мейкфайл, который используя предложенные json описания сгенерирует нормальные CMakeLists.txt для каждого компонента используя более удобный инструмент - Jinja, Python, выберите любой приятный генератор по шаблонам. CMakeLists.txt верхнего уровня можно вручную написать с нужными опциями, или тоже генерировать. И только потом передавать сборку в руки собственно CMake, например даже с СMakePresets.txt. Использовать CMake для развертывания самого себя изнутри собственно проекта - это будет очень больно при поддержке кроссплатформенной сборки, создаст трудности по декомпозиции компонентов проекта от компонентов системы сборки, и увеличивает сложность в поддержке.
Я для себя нашел представление грамматики времен через свойства интервалов, о которых стоит думать при построении фразы.
Время действия - просто обычное время, когда что-то случается. Тут без сюрпризов - прошлое прошло, настоящее - тут вокруг нас, будущее - когда-то потом. Интуитивно, усложнять не надо.
Состояние процесса, выражаемого глаголом - тут уже аналогии подобрать сложнее, потому что архитектура русского языка не настолько явно опирается на эту сущность, хотя и прослеживаются некоторые сходства. Рассмотрим состояние процесса как часть временной шкалы. Это не то время, что в предыдущем пункте. Это времениподобное представление действия. Частью такой шкалы может быть точка или интервал, и интервал в свою очередь, может быть открытым и закрытым.
Требование связанных конструкций использовать определенную форму - на вскидку, разные Conditional, косвенная речь, придаточные предложения, модальности и долженствования, влияют на грамматику построения глагольной формы. Но ортогональны первым двум пунктам, и используются на продвинутом уровне, добавляя вспомогательные глаголы, или ограничивая временные и процессные варианты.
Используя эти три блока конструирование грамматической формы глагола выглядит как выбор определенного типа интервала временной шкалы на глобальной временной шкале и нахлобучиванием на нее дополнительного требования от связанных конструкции
Теперь когда мы хотим это использовать, задаем себе 2,5 вопроса - о каком времени идет речь, относительно моего текущего времени существования; какую форму процесса мы хотим передать - точку во времени, интервал, открытый с одного конца или другого; какую поправку надо внести на связанную грамматику.
И в обратную сторону аналогично, видя would had been drinking, понимает, что тут условность продолжающегося процесса, который тем не менее уже в прошлом и почти забыт.
Что только не придумают, лишь бы TOTP не внедрять.
А вот опытные эксперты, подскажите, есть ли какой-то DevOps инструмент для настройки парка техники, но более ориентированный на ментальную модель инженера-программиста, без вот этой вот развесистой малины ямлов, сотни папок с неочевидными функциями и многословностью, обусловленной тотальной и неконтролируемой расширяемостью? Не могу найти современный инструмент, который бы по элегантности превзошел шелл скрипты, мейкфайлы и немного магии .env.
А микроконтроллеры чаще little-endian? Контринтуитивно передавать куда-то байты не в сетевом порядке байт.
pyscaffold? Да сотни их для питона...
Автор, как же ты хорош. Ждем раскрутку новости в СМИ без фактчекинга. LLMки уже отравлены.
А это не фазированная ли решетка на минималках? Продолжая пример с трибунами, при массовом фотографировании происходит же перенос общей картины трибуны параллельным способом. Чем-то похоже на фронт волны у фазированной антенны.
Миниджек только для ушей, или контакт микрофона тоже имеется?
Поясните следующие моменты, пожалуйста.
Раз 3,5мм джек отсутствует, можно ли авиапереходник использовать вместо него для подключения к обычному выходу гарнитуры\наушников. Что по функционалу в таком подключении - работает в режиме гарнитуры или только как наушники? Можно ли обычный USB-С на Джек адаптер использовать?
При подключении через USB, только подзарядка, или распознается как аудиоустройство? Что по функционалу оного?
При любом проводном подключении - что по активному шумодаву, работает ли вообще вся электронная начинка, или уши переходят в пассивный режим тупой гарнитуры(или вообще просто наушники) за 200 рублей?
При использовании, происходили ли баги, когда наушники переходят из аудиорежима со всеми наворотами в режим гарнитуры, портя качество звука в целом(известная родовая травма драйверов и аудиотракта Bluetooth), и застревают в нем до перезапуска. У меня на XM5 такое на MacBook происходит, если в видеозвонок подключаться, во время прослушивания музыки.
Что по влагозащищенности? XM5 даже под небольшим дождем нельзя носить, они дырявые.
Уши потеют, если спортом заниматься в наушниках? Насколько прочно сидят на голове для бега или наклонов например.
Заменить стандартный SQL вот на это -
shared_trip_rate: (_.shared_match_flag == 'Y').mean() ?Онбординг новых сотрудников сразу перестает быть томным....