Pull to refresh
111
0.3

Разработчик

Send message
Но в отличие от THP, страницу не нужно резать сразу на 512 частей, можно и более аккуратно, например, отрезать половинки от большой страницы пока не останется сколько надо, после чего вытолкнуть на диск.
Мне кажется, в этом случае сильно усложнится процесс определения page fault'ов, то есть если раньше достаточно было проверить, к какой странице относится адрес и есть ли она в памяти, то теперь еще надо будет проверять, а есть ли именно нужная часть страницы в памяти. Как результат — замедление всего доступа к памяти.
При чем тут вообще перегрузка? Для разных базовых типов данных определены разные операции, и они работают по-разному. Этот принцип есть во многих языках (если не во всех).

Да, арифметика указателей — фишка C, еще только в C++ она есть, вряд ли где-то еще, ну а в каких-то языках есть оператор возведения в степень. К перегрузке это не имеет никакого отношения.
множественность значений отдельных знаков операций
Что?
А кроме Винды операционок на свете нет?
В C нет перегрузки операций, и никогда не будет. Учите матчасть.
Да, возможно, частично проблема в том, что квартира не пустая. Просто мне было нужно временное пристанище, примерно на год, и брать стандартный «голый» вариант я не хотел. Но и «голые» квартиры — это не 1000, к сожалению. Примерно в том же районе «голая» квартира, правда немного побольше и в новостройке, но сильно подальше от транспорта — 1600. Наверно, если поискать подольше, можно поймать за полторы.

После Брекзита международный бизнес (а это куча богатеньких буратин) ломанулся из UK в NL, так что цены, и до этого не низкие, подскочили за последние пару лет. Амстердам трещит по швам, инфраструктура не справляется с таким наплывом, в школах и детских садах нет мест. Сейчас строится куча нового жилья, но спрос все равно сильно превышает предложение.
2) Высокие зарплаты (для Европы топ. В Лондоне может и выше, но расходы намного больше, а качество жизни хуже)
Не особо-то высокие. В Германии заметно повыше. В Нидерландах senior — 65-75K до налогов. В Германии аналогичная позиция — 85K и вплоть до 100K (и налоги, как мне кажется, пониже). Про 30% ruling я в курсе.

3) Нет проблем с арендой. Даже в Амстердаме полно предложений по вменяемой цене. Страна небольшая, можно (нужно) жить в пригородах. Полчаса и ты в центре, а дома тихо и спокойно.
В радиусе получаса от центра никак не будет дешево. Да и если смотреть дальше, чем полчаса, Утрехт или Хаарлем какой-нибудь — тоже не будет дешево. Мебелированый two-bedroom (притом такой очень компактный, меньше 50 m2) в NDSM (это, хоть и более-менее популярное место, но все же Noord) — 1700 евро в месяц (мой личный опыт). Эту квартира — не первая попавшаяся, а лучший вариант за примерно полгода поисков. Уровень цен вполне лондонский, я бы сказал. В Берлине раза в два ниже будет.
А, на «Интрепиде» в NY, конечно, тоже был. Но там экспозиция небольшая.
Небольшая, но очень хорошая. Concord, Lockheed A-12 (ранний вариант SR-71), шаттл Enterprise, Harrier, F-4, F-14, F-16, МиГ-21 и еще много всякого.
Вот ещё даже не пробовал совсем ничего такого с user-defined types, работает?
С _Generic в GCC точно работает, в clang вроде тоже пробовал, но точно не помню. По идее, с __builtin_types_compatible_p() тоже должно работать.
Интересная статья.

Пара комментов:

1. Почему в качестве идентификатора типа не использоваться сразу format specifier? То есть вместо 'd' для double сразу писать "%lf"? Тогда можно избавиться от многоэтажного if… if else ..., а сразу использовать нужный формат — и код проще, и работает быстрее.

2. Действительно ли есть необходимость печатать массивы? Просто _Generic() — это C11, все нормальные (я не про MVSC сейчас) компиляторы его поддерживают, а __builtin_types_compatible_p() — расширение GCC. К тому же по крайней мере массивы char'ов _Generic() вполне нормально должен понимать, я его активно использую (с GCC), и проблем с этим не возникало.

3. Не скажу, что это прям реально нужно для печати, но я вот использую аналогичный механизм, когда мне надо к SQL statement'у прибайндить всякие значения, и намного удобнее написать что-то типа sql_bind(stmt, foo, 5, «bar», 7), чем несколько отдельных bind_int(), bind_text() и т.д.

4. Еще это дико полезно, когда есть свои типы, с которыми хочется уметь работать, «как с родными». Например, я использую в одном проекте свои «умные строки», и хочется не вспоминать каждый раз, «умная» это строка или нет, а просто указывать ее в качестве параметра тому же bind'у.
Документоориентированные БД и брокеры сообщений существовали еще до X/Open XA
И что? Без общего стандарта каждый делал что-то свое. С появлением единого стандарта стало намного проще разрабатывать (единый API) и по ходу дела менять компоненты систем, Oracle на PostgreSQL, WebLogic на JBoss и т.п. Не вижу, как это опровергает то, что я написал.

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

Новые инструменты сделаны не потому, что «хипстеры хотели придумать что-то новое» — PostgreSQL до сих пор остается одной из самых популярных БД, хотя сложно представить что-то менее хипстерское.
А разве я где-то написал, что PostgreSQL — хипстерский? В моем комментарии достаточно ясно сказано, что претензии у меня были к Rabbit'у.

Одно можно сказать точно — покуда можно избежать «распределенных» сущностей, их нужно избегать.
Вот с этим однозначно соглашусь. Но это не всегда возможно.
Про стандарт выше тоже знаю, но на практике покрыть распределенный процесс одной «распределенной транзакцией БД» не выйдет — просто пропускная способность системы снизится почти до нуля, т.к. время одной такой транзакции будет до десятков минут, а по пути будет куча блокировок.
XA — это не «распределенная транзакция БД», а распределенная транзакция, которая может включать в себя разные ресурсы, в том числе и БД. Но если сама бизнес-транзакция действительно такая длинная, то да, тут использование обычных транзакций скорее всего не подойдет.

Кроме того, XA не решит проблемы конвейерных процессов: когда вам нужно для создания сущности пройтись по шагам, на каждом из который делается дюжина вызовов к какому-нибудь вендорскому решению (привет, vmware), но при этом уметь обработать ошибки, не переделывая всю цепочку целиком, а еще уметь переживать падение приложения без прерывания транзакции.
А вот это как раз XA хорошо умеет, при условии, что для каждого компонента, участвующего в транзакции (который умеет как коммитить, так и откатывать) есть XA resource manager. Когда даешь transaction manager'у commit или rollback, он дергает все причастные resource manager'ы, чтобы они сделали свое дело.
В 1991 году (30 лет назад!) был принят стандарт X/Open XA, который описывает распределенные транзакции. Этот стандарт поддерживают практически все БД, и многие middleware, такие как Tuxedo, MQSeries, WebLogic, WebSphere, JBoss и прочие. Однако когда берешь что-то новомодное, ощущение, что люди вообще не в курсе того, что делали до них. Сам недавно столкнулся с ситуацией, когда надо было сделать распределенную транзакцию с участием PostgreSQL и RabbitMQ, и оказалось, что у Rabbit'а нет ничего похожего на XA, пришлось что-то самому костылить.

Далее не в адрес автора поста, а просто немного нытья о представителя поколения X. У меня иногда ощущение, что где-то после 2000-го в нашу индустрию пришли какие-то хипстеры, которые считают, что эти скучные бумеры и поколение X в принципе не могли ничего путного придумать (их ведь Цукерберг научил, что молодые просто умнее), и начали по-новой придумывать то, что уже давно придумано и хорошо работает. И не всегда у них получается лучше. Ньютон видел дальше, потому что стоял на плечах гигантов, а не изобретал всю физику и математику с нуля. Будь умный, будь как Ньютон.
А вот рыночный закат IBM начался с PS/2 — когда компания захотела обратно ввести закрытые стандарты на архитектуру ПК.
Вот как раз тоже хотел про это написать — это была если не главная, то одна из важнейших причин, когда выпустили реально прогрессивную, но закрытую и очень дорогую архитектуру MCA для PS/2, которую «почему-то» никто не захотел лицензировать, а все стали использовать EISA, которая, в принципе, не была лучше, но была открытая.

В результате получалось ситуация, что клиент должен быть купить изначально более дорогой компьютер, а потом, когда ему был нужен, скажем, Ethernet (на борту тогда не было сетевого адаптера), то надо было покупать IBM'овский MCA адаптер вместо куда более дешевого Intel'овского или 3Com'овского для ISA или EISA.
Пардон, да, беда у меня с немецкими фамилиями, похоже.
Угу, была. В моем начальном комменте есть цитата.
И да, ARM уж точно кремний руками никогда не трогает. Как и NVidia, собственно.
Лучше прочтите оригинал
Я прочитал. Об органике там ни слова. Но переводчик тоже уже убрал про органику.
Каждый год гиганты индустрии – Intel, AMD, ARM и NVIDIA – выпускают следующее поколение своих топовых кремнийорганических соединений
Точно кремнийорганических? Уже пора начинать бояться чужих, вылезающих из процов? (в оригинале органика не упоминается, кстати)
За многие годы переслушал много наушников, но сейчас китайцы берут рынок в свои руки. Shure, Etymotic – уходят в тень.
А что за китайцы такие, что бьют Shure?
Я как пересел на Shure лет 10-12 назад, так больше ни на какие в принципе не смотрел, лучший звук, что я слышал.
Вы сами себе противоречите. По той карте, которую вы привели выше, в России и в Беларуси как раз плохо с ВУЗами, у которых высокий рейтинг.

Information

Rating
2,446-th
Location
Рига, Латвия, Латвия
Registered
Activity