Прежде чем менять USB-C в телефоне, попробуйте другой кабель. Там бывает износ контактов (тоненькие они очень). Но новый, неизношенный кабель может еще долго работать. Вообще, USB-C разъем это тот еще компромис между передаваемой мощностью и размерами. И он очень чувствителен к позиционированию на плате. Бывает что при монтаже он становится на 0.2-0.3 мм глубже внутрь корпуса, и писец. Кабель довольно быстро перестает дотягиваться до контактов и начинаются проблемы с зарядкой.
Мммм, может быть. Но мне на miniUSB везло. Ни один не сдох, хотя несколько уже больше 10 лет эксплуатируются в автомобиле. Их любили в навигаторы ставить даже тогда, когда во всех остальных устройствах уже на micro перешли.
Принцип Парето (80/20) Принцип: 80% результата достигается за счёт 20% усилий, а оставшиеся 20% результата требуют 80% усилий. В разработке ПО: Обычно 20% разработчиков создают 80% ценного кода, а 20% функционала продукта удовлетворяют 80% потребностей пользователей. Этот принцип помогает менеджерам сосредоточиться на ключевых приоритетах, не растрачивая ресурсы на малозначительные задачи.
Но вы всегда ставите приоритет не на тех 20 процентах. И увольняете не те 20% инженеров.
Ограничения своего подхода авторы понимают. Но вот пользователи их результатов не всегда.
В больших компаниях, особенно если кодовые метрики учитываются в ежегодном ревью, попадается тип инженера - "энтузиаст". Он влезает в любой проект в самом начале. Пишет тонны кода. Но для того чтоб проект дошел хотя-бы до стадии MVP, нужно весь его код выкинуть и переписать. Этот код написан без размышлений о том как он будет взаимодействовать с другими компонентами, как он будет работать во всех сценариях, и прочее. Такой код даже заглушкой назвать нельзя. Он написан в стиле "суета ради суеты". Кодовые метрики таких типов всегда на высоте, на уровне лучших senior инженеров компании.
С другой стороны есть люди которые пишут очень мало кода. Но этот код критически важен, и часто сложен. Он определяет архитектуру системы на годы вперед. Часто такие люди проводят большую часть рабочего дня за разговорами в кабинетах и на кухнях. У этих людей кодовые метрики обычно не сильно хорошие. Единственно что их отличает, их код живет долго. Десятилетия спустя его все еще можно найти внутри основных библиотек. И он обычно обвешан комментариями вида: "ни в коем случае не менять", "обязательно code review с super-system-core командой", "director of engineering approval is a must".
И если первый тип инжинеров можно легко уволить, то вторые критически важны для развития компании. Но понять это, глядя на кодовые метрики, практически нереально.
Во-первых, мне не нравится, что нам нужно генерировать кучу бойлерплейта при помощи IDE после щелчков в UI-меню. Мне бы хотелось, чтобы у меня была более гибкая библиотека, параметризируемая в коде, чтобы можно было написать что-то типа InitUsbDevice(UsbClass.CDC), а не ползать по UI для генерации кода. ..... Я не просто так упомянул, что Linux может работать в качестве USB-устройства: мне кажется, это гораздо более чистый подход. Linux API гораздо надёжнее и стандартизированнее. Работа с Linux будет основана на взаимодействиях с псевдофайлами и системными вызовами. Пользовательское пространство очень чётко отделено от пространства ядра. Кроме того, я воспринимаю Linux как слой HAL.
Автор сильно недооценивает количество "железных" блоков в контроллере которые делают возможной поддержку USB. Да и вообще всю эту периферию. Перекладывать все это на Линукс в надежде на то, что Линукс сделает тебе "хорошо и прозрачно" это ..мммм.. наивность какая-то! Гибкость Линукса при работе с железом обеспечивается драйверами. Но их кто-то должен писать и именно внутри драйверов будет сидеть весь этот boilerplate код. А создание драйверов для всех вариантов периферии которая бывает в контроллерах это немного неподъемная задача, т.к. вариантов этой периферии несколько даже внутри одного семейства контроллеров. И это не говоря о том, что часть инициализации периферии делается на этапе прошивки устройства путем прописывания магических чисел в регистровые файлы конфигурации, прожигания фьюзов и т.п. А уж выяснение какие аппаратные блоки можно активировать одновременно - это отдельная прикольная задача. Конфигуратор из IDE может хоть проверить, что все эти режимы тактирования, назначения ног (для конкретной модели контроллера), IO блоки не конфликтуют друг с другом. А повесить эту задачу на драйвера OS прошитой в контроллер - это просто не реально! Вендоры тоже неохотно делятся подробностями конфиругирования встроенных устройств. Бывает что требуют подписать NDA, а бывает что дают только скомпилированный бинарный blob который магически включает то, что вам обещано. Ну и как вишенка на торте, портирование Линукса на все архитектуры контроллеров - это отдельное большое удовольствие. Все эти i51, AVR, ARM xx, и прочие будет очень приятно поддерживать. А про защищенный режим на половине архитектур можно будет просто забыть.
С механической прочностью у microUSB как раз совсем плохо. На практике USB-C переносит больше подключений/отключений. А совсем хорошая прочность была у miniUSB, но там разъем великоват и из-за этого ушел в небытие.
I paid - это "я платил" - past simple. Но не "я выплатил". Т.е. к какому варианту не прикладывай, все коряво выходит. Но такое в разговорной речи сплошь и рядом, а уж в постах и комментах - тем более. Чего он там имел ввиду не понятно.
Применять нормы литературного языка к постам на Реддите - это конечно форма йумора. Когда снимают жилье или еще выплачивают тоже говорят "I pay rent", "I pay for my house".
Вы не по курсу пересчитывайте, относительно медианного дохода. Чувак получает 2х медианный доход американских городов. Это прям немного, хотя в его городе и прилично выглядит.
Судя по Вике, это городок в агломерации на 150 тыс народа. И местность довольно депрессивная (median income $33,532). Крупнейший бизнес - местная страховая компания. Т.е. там натуральный "день сурка" зимой. Но на фоне местных он "богатый буратина". Из развлечений там оперный театр и "there are over 50 wineries near Traverse City". Типичная американская дыра средней дырявости. Зимой промозгло и сыро. Постоянный дождь со снегом (практически каждый день). Гулять конечно можно, но такое себе. Я начинаю понимать почему чувак так дни проводит.
"paid for our nice house" - означает "заплатил". "Выкупил" это "paid out our house". Так что что именно он заплатил (рент/ипотеку/выплатил полностью) не совсем понятно.
В том, что существует куча софта который уже не собирается последними компиляторами, либо существует ТОЛЬКО в бинарном виде. Этот софт (суммарно) тянет на триллионы долларов (стоимость замены). Если начнете играть с совместимостью нескольких ABI, то это все придется изобрести заново. И кто-то должен будет за эти работы заплатить. А добровольцев платить что-то не видно.
Самый главный вопрос, где именно чувак живет. Пока звучит как: "я имею 120к в месяц, сижу дома, играю в игры и накуриваюсь в говно" (пересчитал в рубли относительно российского уровня). Но 120к в Иваново - это одно, а 120к в Москве это совсем другое. В целом, текущий доход у него нормальный для многих городов. Кроме LA, SF, NY может быть. Но не ясно выкупил ли он дом, или только платит ипотеку. Ну и перспективы тоже не ясны. Сейчас он получает 125к в год от 2-миллионных активов. Но насколько рисковые активы? В среднем, консенсус сейчас, что надо иметь полностью выплаченный дом и 4 млн в инвестированных сбережениях (на семью из 2 человек без детей) чтоб позволить себе уйти на пенсию. Беда только в том, что экономика не стабильна и 2 млн в сбережениях легко превратятся в 1 млн буквально за пару лет. Такое уже произошло, с 2020 года реальная стоимость пенсионных сбережений опустилась на 25-40%. И это "малорискованные инвестиции" всего за 5 лет. Upper middle class в штатах прилично выдоили и продолжают со все большей силой. Так что я считаю, что рановато чувак расслабился! Ему бы еще лет 15 поработать, пока здоровье есть.
К сожалению, при 95 градусов процессор долго не живет. Нынешние проблемы у интеловских ЦПУ 13, 14 поколения тому примером. Просто производитель считает, что срок службы в 2-3 года достаточен.
Кроме того современные процессоры динамически снижают частоту и отключают блоки при повышении температуры. Т.е. при температуре ядра менее 60 градусов вы просто получаете большую производительность.
По поводу реверс-инжиниринга - поддержу. Наши китайские соседи имеют другое отношение к интеллектуальной собственности. И это не правовой нигилизм, а скорее культурные отличия. Отношение к реверс-инжинирингу у них совсем другое. Что-то вроде "сумел разобраться - молодец". Может вам предлагать "апрейды" и "альтернативные прошивки" к этим устройствам, раз уж производитель никакой поддержки не предлагает?
Про нагрев уже написали. А есть еще банальная стоимость производства. Зачем полировать радиатор (доп. технологическая операция), если термопаста дает то-же результат дешевле.
Технология вполне позволяет задать ориентацию. Даже в банальных нейлоновых колготках ориентация молекул полимера "в основном" идет вдоль волокна. Достигается банальным выдавливанием через фильеру и вытягиванием нити.
Что-то здесь не то. Байт "0b00110011" отображает многочлен "x^5 + x^4 + x + 1"
Прежде чем менять USB-C в телефоне, попробуйте другой кабель. Там бывает износ контактов (тоненькие они очень). Но новый, неизношенный кабель может еще долго работать.
Вообще, USB-C разъем это тот еще компромис между передаваемой мощностью и размерами. И он очень чувствителен к позиционированию на плате. Бывает что при монтаже он становится на 0.2-0.3 мм глубже внутрь корпуса, и писец. Кабель довольно быстро перестает дотягиваться до контактов и начинаются проблемы с зарядкой.
Мммм, может быть. Но мне на miniUSB везло. Ни один не сдох, хотя несколько уже больше 10 лет эксплуатируются в автомобиле. Их любили в навигаторы ставить даже тогда, когда во всех остальных устройствах уже на micro перешли.
Принцип Парето (80/20) Принцип: 80% результата достигается за счёт 20% усилий, а оставшиеся 20% результата требуют 80% усилий. В разработке ПО: Обычно 20% разработчиков создают 80% ценного кода, а 20% функционала продукта удовлетворяют 80% потребностей пользователей. Этот принцип помогает менеджерам сосредоточиться на ключевых приоритетах, не растрачивая ресурсы на малозначительные задачи.
Но вы всегда ставите приоритет не на тех 20 процентах. И увольняете не те 20% инженеров.
В корпорациях мера ВСЕГДА становится целью. Как результат - вы получаете то, что вы измеряете.
Ограничения своего подхода авторы понимают. Но вот пользователи их результатов не всегда.
В больших компаниях, особенно если кодовые метрики учитываются в ежегодном ревью, попадается тип инженера - "энтузиаст". Он влезает в любой проект в самом начале. Пишет тонны кода. Но для того чтоб проект дошел хотя-бы до стадии MVP, нужно весь его код выкинуть и переписать. Этот код написан без размышлений о том как он будет взаимодействовать с другими компонентами, как он будет работать во всех сценариях, и прочее. Такой код даже заглушкой назвать нельзя. Он написан в стиле "суета ради суеты".
Кодовые метрики таких типов всегда на высоте, на уровне лучших senior инженеров компании.
С другой стороны есть люди которые пишут очень мало кода. Но этот код критически важен, и часто сложен. Он определяет архитектуру системы на годы вперед. Часто такие люди проводят большую часть рабочего дня за разговорами в кабинетах и на кухнях. У этих людей кодовые метрики обычно не сильно хорошие. Единственно что их отличает, их код живет долго. Десятилетия спустя его все еще можно найти внутри основных библиотек. И он обычно обвешан комментариями вида: "ни в коем случае не менять", "обязательно code review с super-system-core командой", "director of engineering approval is a must".
И если первый тип инжинеров можно легко уволить, то вторые критически важны для развития компании. Но понять это, глядя на кодовые метрики, практически нереально.
Во-первых, мне не нравится, что нам нужно генерировать кучу бойлерплейта при помощи IDE после щелчков в UI-меню. Мне бы хотелось, чтобы у меня была более гибкая библиотека, параметризируемая в коде, чтобы можно было написать что-то типа InitUsbDevice(UsbClass.CDC), а не ползать по UI для генерации кода. ..... Я не просто так упомянул, что Linux может работать в качестве USB-устройства: мне кажется, это гораздо более чистый подход. Linux API гораздо надёжнее и стандартизированнее. Работа с Linux будет основана на взаимодействиях с псевдофайлами и системными вызовами. Пользовательское пространство очень чётко отделено от пространства ядра. Кроме того, я воспринимаю Linux как слой HAL.
Автор сильно недооценивает количество "железных" блоков в контроллере которые делают возможной поддержку USB. Да и вообще всю эту периферию. Перекладывать все это на Линукс в надежде на то, что Линукс сделает тебе "хорошо и прозрачно" это ..мммм.. наивность какая-то! Гибкость Линукса при работе с железом обеспечивается драйверами. Но их кто-то должен писать и именно внутри драйверов будет сидеть весь этот boilerplate код. А создание драйверов для всех вариантов периферии которая бывает в контроллерах это немного неподъемная задача, т.к. вариантов этой периферии несколько даже внутри одного семейства контроллеров.
И это не говоря о том, что часть инициализации периферии делается на этапе прошивки устройства путем прописывания магических чисел в регистровые файлы конфигурации, прожигания фьюзов и т.п. А уж выяснение какие аппаратные блоки можно активировать одновременно - это отдельная прикольная задача. Конфигуратор из IDE может хоть проверить, что все эти режимы тактирования, назначения ног (для конкретной модели контроллера), IO блоки не конфликтуют друг с другом. А повесить эту задачу на драйвера OS прошитой в контроллер - это просто не реально!
Вендоры тоже неохотно делятся подробностями конфиругирования встроенных устройств. Бывает что требуют подписать NDA, а бывает что дают только скомпилированный бинарный blob который магически включает то, что вам обещано.
Ну и как вишенка на торте, портирование Линукса на все архитектуры контроллеров - это отдельное большое удовольствие. Все эти i51, AVR, ARM xx, и прочие будет очень приятно поддерживать. А про защищенный режим на половине архитектур можно будет просто забыть.
С механической прочностью у microUSB как раз совсем плохо. На практике USB-C переносит больше подключений/отключений. А совсем хорошая прочность была у miniUSB, но там разъем великоват и из-за этого ушел в небытие.
I paid - это "я платил" - past simple. Но не "я выплатил". Т.е. к какому варианту не прикладывай, все коряво выходит. Но такое в разговорной речи сплошь и рядом, а уж в постах и комментах - тем более. Чего он там имел ввиду не понятно.
Применять нормы литературного языка к постам на Реддите - это конечно форма йумора.
Когда снимают жилье или еще выплачивают тоже говорят "I pay rent", "I pay for my house".
Вы не по курсу пересчитывайте, относительно медианного дохода. Чувак получает 2х медианный доход американских городов. Это прям немного, хотя в его городе и прилично выглядит.
Судя по Вике, это городок в агломерации на 150 тыс народа. И местность довольно депрессивная (median income $33,532). Крупнейший бизнес - местная страховая компания.
Т.е. там натуральный "день сурка" зимой. Но на фоне местных он "богатый буратина".
Из развлечений там оперный театр и "there are over 50 wineries near Traverse City". Типичная американская дыра средней дырявости.
Зимой промозгло и сыро. Постоянный дождь со снегом (практически каждый день). Гулять конечно можно, но такое себе. Я начинаю понимать почему чувак так дни проводит.
"paid for our nice house" - означает "заплатил". "Выкупил" это "paid out our house".
Так что что именно он заплатил (рент/ипотеку/выплатил полностью) не совсем понятно.
В том, что существует куча софта который уже не собирается последними компиляторами, либо существует ТОЛЬКО в бинарном виде. Этот софт (суммарно) тянет на триллионы долларов (стоимость замены). Если начнете играть с совместимостью нескольких ABI, то это все придется изобрести заново. И кто-то должен будет за эти работы заплатить. А добровольцев платить что-то не видно.
Самый главный вопрос, где именно чувак живет. Пока звучит как: "я имею 120к в месяц, сижу дома, играю в игры и накуриваюсь в говно" (пересчитал в рубли относительно российского уровня). Но 120к в Иваново - это одно, а 120к в Москве это совсем другое.
В целом, текущий доход у него нормальный для многих городов. Кроме LA, SF, NY может быть. Но не ясно выкупил ли он дом, или только платит ипотеку. Ну и перспективы тоже не ясны. Сейчас он получает 125к в год от 2-миллионных активов. Но насколько рисковые активы?
В среднем, консенсус сейчас, что надо иметь полностью выплаченный дом и 4 млн в инвестированных сбережениях (на семью из 2 человек без детей) чтоб позволить себе уйти на пенсию. Беда только в том, что экономика не стабильна и 2 млн в сбережениях легко превратятся в 1 млн буквально за пару лет. Такое уже произошло, с 2020 года реальная стоимость пенсионных сбережений опустилась на 25-40%. И это "малорискованные инвестиции" всего за 5 лет. Upper middle class в штатах прилично выдоили и продолжают со все большей силой.
Так что я считаю, что рановато чувак расслабился! Ему бы еще лет 15 поработать, пока здоровье есть.
К сожалению, при 95 градусов процессор долго не живет. Нынешние проблемы у интеловских ЦПУ 13, 14 поколения тому примером. Просто производитель считает, что срок службы в 2-3 года достаточен.
Кроме того современные процессоры динамически снижают частоту и отключают блоки при повышении температуры. Т.е. при температуре ядра менее 60 градусов вы просто получаете большую производительность.
По поводу реверс-инжиниринга - поддержу. Наши китайские соседи имеют другое отношение к интеллектуальной собственности. И это не правовой нигилизм, а скорее культурные отличия. Отношение к реверс-инжинирингу у них совсем другое. Что-то вроде "сумел разобраться - молодец".
Может вам предлагать "апрейды" и "альтернативные прошивки" к этим устройствам, раз уж производитель никакой поддержки не предлагает?
Отличная идея! С нетерпением жду ваш результат.
Про нагрев уже написали. А есть еще банальная стоимость производства. Зачем полировать радиатор (доп. технологическая операция), если термопаста дает то-же результат дешевле.
Технология вполне позволяет задать ориентацию. Даже в банальных нейлоновых колготках ориентация молекул полимера "в основном" идет вдоль волокна. Достигается банальным выдавливанием через фильеру и вытягиванием нити.