Pull to refresh
-11
0
Руссков Андрей @Antervis

Разработчик

Send message

общественный совет был альтернативой со стороны яндекса чтобы избежать прямого контроля со стороны правительства. Насколько я понимаю, сейчас этот прямой контроль хотят установить уже силой

Да никуда клиенты не денутся, ремонт в СЦ Apple уже сейчас удовольствие не на час и зачастую даже не на неделю

тут раз на раз. Последний раз когда я делал ремонт в авторизованном СЦ (гарантийная замена экрана на iphone x), сделали за пару часов. Если что-то сильно нетиповое или в неавторизованном СЦ то да, мб придется подождать.

А умники да, за пару месяцев закончатся, когда поймут, что схема не работает.

вы никак не адресовали то, что экспертиза на каждое устройство сильно увеличит время среднего ремонта.

на экспертизу, на экспертизу

угу, на каждый 15-минутный ремонт проводить экспертизу по часу. Умники быстро закончатся, это верно. Клиенты в общем-то тоже.

Я про то, что они перестанут клепать эксклюзивные чипы только ради того, чтобы поломать компонентный ремонт.

так в этом-то и идея. Пусть клепают сколько душе угодно, лишь бы они были доступны в свободной продаже.

Всего-то надо научить своих работяг отличать китайский экран от оригинального. Покупатели на вторичке даже справлялись в свое время, а работяги не справятся?

как вы отличите скажем нерабочий китайский экран, спроектированный с целью имитировать оригинальный, и оригинальный? А даже если и рабочий - отличать будете "на глазок"? В смысле, если он ID-шники одинаковые возвращает. Или предлагаете по неавторизованному открытию крышки снимать с устройства гарантию производителя? Такое в зависимости от страны может быть нелегально.

В общем, производитель всегда выберет самый выгодный из законодательно доступных ему вариантов.

Ну да, если Apple запретят лепить на ровном месте «эксклюзивные» чипы, то оно пойдет в массовое производство. Если запретят завязывать все на свои СЦ и свой софт — тоже. Право на ремонт об этом.

нет, право на ремонт не об этом, а о том, чтобы необходимые для ремонта запчасти, инструменты и документация были в свободном доступе. Оно вот прям вообще никак не заставит apple клепать свои чипы для устройств конкурентов.

В автомобиль я могу поставить левую запчасть неизвестного происхождения и поехать по трассе на 150 км\ч.

не совсем - ваш автомобиль всё еще должен будет пройти техосмотр. И просто так заменить бензобак пластиковой канистрой конечно же не прокатит.

От этого нельзя защититься. Точнее, не рационально.

ну почему же, apple как раз и защитились таким образом от кучи разных махинаций, которые проворачивали во времена айфонов 4/4S, особенно в китае. Например, брали айфон, меняли экран на китайский, приходили в авторизованный СЦ с "ой у меня чет экран тусклый", СЦ заменял на новый по гарантии, получался айфон + оригинальный экран, экран продавали в левые СЦ, цикл.

ну я например долго не мог привыкнуть к десятке после восьмерки, хотя по габаритам они отличаются, казалось бы, совсем чуть-чуть.

допустим толщина среднего чехла порядка 1 мм. Значит разница будет не между 7 и 7.5 мм а между 8 и 8.5 мм. Она всё так же ощущаема.

Опять же, вот вы говорите даже не держали, а я последние 10+ лет свои айфоны только без чехла и таскаю. И мне нравится как моя 10-ка лежит в руке, а вот 13-й по мне большеват даже без чехла. Так или иначе, это всё личные предпочтения. Важно другое - "тоньше" значит "удобнее". Если бы еще аккумуляторы не были ограничивающим фактором...

так у вас же рассрочка никак на баланс и сумму кредитки не влияет

И что конкретно это меняет? Её всё равно надо выплатить в непонятно насколько ограниченное время с непонятно насколько ограниченным штрафом. Да, в теории клиент просто получает дополнительную услугу нахаляву. На практике есть граничные случаи, выгодные банку/партнеру и не выгодные клиенту.

А ребенку такие услуги в принципе не доступны...

Это если на ребенка заводится отдельный счет с картой и прямым и явным отказом от кредитки. А если для ребенка заводится доп. карта с уже существующего счета, могут быть нюансы

Допустим я использую карту тинькофф в качестве прокси - для мелких покупок и обычно пополняю её по истечению баланса. Вполне разумный сценарий. Теперь допустим что я не уследил (ожидая что в платеже при недостаточном балансе будет отказано) и ушел в минус со всеми этими рассрочками. Как по мне, я и не должен был следить. Теперь допустим я решил перестать пользоваться этой картой. Имею право. Вот только через пару месяцев на мне будет висеть куча непогашенных рассрочек и начнет набегать пеня. Заодно с подпорченной кредитной историей.

Это был сложный сценарий. Простой сценарий - ребенку заводится карта куда капают карманные и он уходит в овердрафт.

И еще раз: "рассрочка" это всё еще кредит, со всеми вытекающими формальностями, и процент здесь не имеет решающего значения. Собственно поэтому я и поставил вопрос о лазейке в законодательстве.

раньше навязывание услуг, кредитов в частности, было нелегальным. Что за лазейку они нашли/придумали?

«Общая масса покупателей» будет хавать то, что им впихнет реклама и агрессивный маркетинг.

вы думаете что общая масса потребителей следит за всеми этими новинками мира телефоностроения? Большинство приходит в магазин имея слабое представление о характеристиках, всех этих гигагерцах/мегабайтах/мегапикселях и т.д. Как думаете, много людей смогут ответить на вопрос "какой у тебя в телефоне процессор?". Зато критерии а-ля "красивый"/"удобный"/"нравится цвет"/"приятный на ощупь" осязаемы для всех покупателей и часто являются решающими. И по мне весьма логично хотеть чтобы штука, которую держишь в руках по паре часов в день, лежала в руке и была приятной на ощупь.

Не было бы навязанного хайпа по поводу излишней тонкости, от которой телефоны в карманах гнулись, общей массе было бы ровно пофиг на пару лишних миллиметров толщины

"Пара миллиметров", говорите? А вы давно последний раз сравнивали как лежат в руке телефоны толщиной 7 мм и 9 мм? Даже разница между 7 и 7.5 мм кажется разительной.

производителю выгодно делать одноразовые и как можно меньше допускающие самостоятельное обслуживание устройства.

чтобы разочарованный потребитель потом купил устройство другого производителя...

По мне так вы пытаетесь объяснить различие вашего миропонимания и реальности через теории заговора.

Во-первых, std::unique_ptr'у нельзя подсунуть аллокатор, а только deleter, поэтому не получится так просто его использовать, придётся действительно огородить свой operator new и связывать его с deleter'ом.

не обязательно, можно сделать свою make-функцию. С аллокатором я косякнул, да

Можно ссылаться на этот тред, когда в следующий раз вдруг в комментах зайдёт речь, что для производительности необходимо и достаточно брать плюсы.

не помню чтобы я утверждал ни про необходимость, ни про достаточность. По крайней мере безоговорочно.

Ну, да. Но как это здесь мешает?

может мешать, в зависимости от задачи/архитектуры/команды

Нет:

ok my bad. Такое чувство словно инструкция rcr была заведена под этот кейс...

Если вам действительно нужно оптимально

то подавляющее большинство ЯП отпали пару порядков оптимизаций назад. Из оставшихся, которые можно пересчитать по пальцам одной руки, с инлайн асмом/интринсиками справятся все.

Утверждаю, что писать на хаскеле код, более-менее равный плюсам без микрооптимизаций, не сильно сложно, и с лихвой компенсируется простотой нечувствительных к производительности частей.

хаскель как минимум функциональный язык. Остальное субъективно.

Ну а как называется то, чем мы тут занимались? Написали один вариант, посмотрели, что gcc оптимизирует так, clang оптимизирует сяк. Написали другой вариант, посмотрели…

тем не менее код будет работать под все поддерживаемые платформы, даже если не везде оптимально. В этом и заключается свойство переносимости. Опять же, оптимизации, сделанные на миддленде, будут применены под любую архитектуру.

Как это сделать на ассемблере под amd64?

Как это сделать на плюсах?

Ну вы сами того не заметив подкрепили все мои же аргументы. Во-первых, ваша asm версия с ошибкой - rcr это циклический сдвиг вправо, т.е. будет возвращать некорректный результат при нечетных a + b. Во-вторых, вы либо слукавили либо допустили вторую ошибку - реализация на asm в отличие от с++ версий еще и не обрабатывает переполнение. Две ошибки в трех командах, хах. В-третьих, как я и сказал, компиляторы микрооптимизируют лучше - складывают через lea.

Только это уже не стандартный C++ :]

честно говоря я забыл что unreachable еще не является стандартным аттрибутом. Опять же, он нужен для оптимизаций компилятора, а не для обеспечения корректности кода.

А зачем плюсы вне подобных задач?

везде где данных/rps по-настоящему много, реализация на с++ сэкономит больше на железе даже без микрооптимизаций.

Подглядывая в ассемблер.

ну во-первых, жертвуя переносимостью. Во-вторых, в асме тоже можно начудить - компиляторы нынче учитывают больше нюансов и особенностей архитектуры при микрооптимизациях чем человек в состоянии знать. Не говоря о том, что как только доходит дело до макрооптимизаций, проще писать на тех же плюсах, чем переизобретать структуры данных.

В некоторых других ЯП короткоживущий мусор на хипе стоит сильно дешевле плюсового хипа (bump/arena allocator, nursery, вот это всё).

В плюсах у программиста есть свобода переопределять аллокатор глобально, а также в масштабах контейнеров и отдельных классов.

Абсолютно верно. Только что вы напишете внутри ифа, если таки хотите вернуть ссылку? __builtin_unreachable();?

ну да, сработает же

Да, я тоже рад, что уже третий год практически не прикасаюсь к плюсам.

это я так тонко намекнул что проблема может быть не в плюсах, а в этом "вашем байтоложенском лоулейтенси"

«Плюсы — это гарантированная производительность», говорили они

кто "они" то? Производительность не бывает "гарантированной", однако возможность написать производительный код на плюсах всегда остается. В большинстве других ЯП вопрос экономии на аллокациях даже не ставится...

А я хочу ссылочку, потому что nullptr по логике быть не может никогда.

ну раз nullptr никогда не будет, то и UB в случае которого никогда не будет не проблема, верно?

ХЗ, более-менее стандартный код для этого нашего байтоложеского лоу-летенси.

брр

Интересно, а почему?

полагаю потому, что как только дело доходит до исключений, компиляторы сходят с ума и теряют возможность оптимизировать даже тривиальные сценарии.

Я предполагаю, что в adt что-то есть. Гарантировать отсутствие valueless by exception предлагается читателю в качестве упражнения.

лучше добавить проверку, учитывая что это может помочь компилятору

Ну тут всё просто:

я понял как это работает благодаря пониманию что этот метод должен делать. Без этого понимания пришлось бы почесать лоб и помянуть добрым словом автора.

Там сильно зависит от версии компилятора и от того, является ли базовый класс виртуальным. Хотя признаться я изначально смотрел на более старых компиляторах.

Хотя это ж C++17, можно обмазаться fold expressions:

да, так тоже можно, правда там UB - нельзя брать ссылку от nullptr.

то компилятор перестаёт понимать, что от него хотят, и генерирует что-то более сложное.

ну тут не только компилятор перестанет понимать чего от него хотят...

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Date of birth
Registered
Activity