На собеседовании - ошибка в третьем "Да". Лучше тут было бы сказать "Нет": Из общих соображений понятно, что для всех, кроме узких профессионалов, т.е. - в большинстве случаев, можно обойтись без работы со скрытой по умолчанию служебной информацией. Тут главное не зарываться, а проскочить на минималках: как тот же упомянутый Пиркс, который на экзамене у профессора Меринуса, препа-зверя, свой хор. получил. И на курсах по прохождению собеседований этому, по-хорошему, должны учить. Но, боюсь, что с нуля такой совет не выполнить, здесь нужна некоторая база, типа списка типовых понятий по каждому продукту (по-хорошему, ее тоже надо давать на тех же курсах): например, заявить про PostgreSQL, что вы не использовали SELECT - это залёт. Короче, тут требуется творческий подход.
PS А если это не совсем на собеседовании, то подходящий ответ вполне гуглится в поставленных вами рамках - например я так нашел это в качестве ответа на ваш последний вопрос
но мне это не нравится
Во мне все восстает против таблиц без первичного ключа, тем тем более, что для поиска можно использовать и более стандартный способ - SELECT DISTINCT ... FROM ... GROUP BY все_поля HAVING COUNT(*)>1
Так что, было бы желание у меня пустить пыль в глаза в том обсуждении вашей статьи - нашел бы способ, быстро. Не факт, конечно, что вышло бы, но у меня даже и желания не было.
PPS А вообще, хорошие общие курсы по прохождению собеседований (краткосрочные, ибо много материала там просто нет) моли бы быть востребованы народом. Только вот для ифноцыган тема сложновата будет, наверное, им такие курсы - как свинью стричь: "визгу много, шерсти мало".
Если мне, предположим, действительно требуется человек с актуальным коммерческим опытом, то отношение будет отрицательное.
Это я понял по преыдущему ответу.. Но речь шла не о вас, потому что вы - не HR: у вас нет необходимости отсеивать мутный поток негодных соискателей. А HR, если не поставит такой фильтр, то утонет в этом саммом мутном потоке откликов от вайтишников. но на мой вопрос вы ответили - когда про требование диплома написали: это - ещё более формальный фильтр, и ещё более бессмысленный (если речь не идет от вчерашнем студенте, а, к примеру, о человеке вашего возраста). Правда - труднее фальсифицируемый.
Ну про "ни разу" - точно не про меня.
Это я про себя писал - таки не работал.
Хотя бы потому, что знаю, насколько различается архитектура PostgreSQL от MS SQL или Oracle.
Ну, я работал-то, в основном, с Interbase - в те годы, когда он был. И его потомками. А с MS SQL - сильно меньше, но заметно позже. А у Interbase что-то сходное в архитектуре хранилища есть, поскольку у него хранилище - тоже многоверсионное. Например, например, операция уборки неактуальных версий записей у него тоже была, только на уровне не таблиц, а всей БД (sweep). Ну, а ещё я в том обсуждении не старался делать вид, что я с PostgreSQL хоть как-то активно работал, так что эксперимент не совсем чистый и с этой стороны: соискатель модели "лжец" все-таки будет стараться: например, воспользуется "методом Пиркса" и найдет точные названия всех обсуждаемых служебных полей и прочие необходиммые термины - это поиском по документации находится быстро).
Это уже зависит во многом и от меня. Требования к вакансии все же со мной согласуются.
Зачетный ответ. Прямо как правильный ответ на вопрос немцкого теста на восстановление прав для залетевших выпимши за рулем (AKA Idiotentest). Типичные вопросы там были на тему, что вы будете делать, оказавшись ситуации, связанной с употреблением алкоголя и автомобилем, а правильный ответ - "я не окажусь в такой ситуации".
Но все-таки хотелось бы узнать ваше отношение к лжи, направленной чисто на прохождение формального фильтра. В частности, как бы вы вакансию ни согласовывали, но требование опыта коммерческой разработки для мидла вы из нее не выкинете, так? В таком случае - вопрос: как вы отнесетесь к человеку, приписавшему себе актуальный коммерческий опыт, чтобы пройти фильтр, и честно скзавшему вам об этом. Для усложнения задачи предположим, что у него есть неактуальный опыт - например, лет пять работы программистом лет пятнадцать назад где-нибудь в тогдашней фирмочке, после - переход куда-нибудь тоже в IT, но не разработчиком: админ, аналитик и т.п. - и знание актуального языка/фреймворка и т.п., подтверждаемое этим самым пет-проектом и проверяемое (в принципе ;-) на техсобесе? По-моему, это удовлетворяет исходному условию: человек, не проходящий без вранья через формальный фильтр, но, в принципе, могущий оказаться годным кандидатом. Что скажете: будете продолжать собеседование, услышав про ложь, или отвергнете соискателя [тут должен быть плакат с образцовым советским человеком, гневно отвергающим протянутый ему стакан водяры]?
И спокойно отношусь к тому, что кто-то не знает то, что гуглится за 30 секунд. Но для того, чтобы нагуглить это за 30 секунд нужно иметь уже иметь определенные базовые знания и понимание.
Кстати, по этому поводу: чисто для себя поинтересуюсь - вы обратили в нашей с вами недавней дискуссии по вашей статье, что я конкретно c PostgreSQL ни разу не работал? Интересуюсь в контексте чисто теоретического вопроса, который я уже тут задавал : является ли необходимымым/поддается ли симуляции пресловутый "опыт работы"? Правда, эксперимент тут не чистый: я работал, и немало с другими SQL-серверами, начиная с упомянутого там древнего Interbase, а потому, наверное, как раз имею упомянутые вами базовые знания.
А отказываю соискателям я, чаще всего, за ложь. То есть задаю вопросы "знаете ли вы это?". И, в какой-то момент, после получения утвердительного ответа, вдруг проверяю эти знания. Если соискатель солгал - прощаемся."
Горячо одобряю и поддерживаю. Только вот есть нюанс: как этот честный соискатель, которого вы ищете до вас доберется - если, конечно, он не реальный мидл, причем - с реальным коммерческим опытом разработки именно на вашем конкретном стеке. С рынка у него же мало шансов пройти формальный фильтр HR. Разве что, как вы - в обход этого фильтра, через связи. Но как я уже писал, умение поддерживать связи для программиста нехарактерно. Да и в целом по стране проблему нехватки разработчиков так не решить (если она есть конечно - потому что, к примеру смысл обсуждаемого высказывания главы Тинька я оцениваю как обращение "дайбаблабля" к Максудову и прочему правительству). А вот если соискатель последует часто встречающимся (даже тут, на Хабре) рекомендациям соврать про коммерческий опыт и про ваш стек - то как раз до вас, до технического собеседования, то бишь, и доберется.Так что шибко честных ещё до вас отсеют, согласны? И в связи с этим у меня есть вопрос - как вы среагируете на "сравнительно честного" соискателя, который на техсобесе честно признается вам, что коммерческий опыт он накрутил, чтобы фильтр HR пройти, а на самом деле у него за душой изучение(самостоятельное) и пет-проект (ссылка в резюме), который он, правда, написал сам и без помощи stackoverflow (ну, почти без - он же сравнительно честный, по определению)?
PS И да, ещё, учитывая чтопроверка проверке рознь, пара вопросов. Вот, к примеру, как вы думаете, сможет ли подтвердить свои знания PostgreSQL, типичный разработчик, если ему будет для проверки подкинут сценарий из вашей крайней статьи (которая про очистку громадной таблицы), которую мы с вами вчера-сегодня обсуждали, да ещё и без Гугля. И будете ли вы задавать такой вопрос с этой целью (информация к размышлению: есть жалобы, опубликованные но не проверенные, что подобные вопросы на техсобесах таки задают)?
Что-то это мне, в рамках моей общей эрудиции, напоминает часть алгоритма планировщика запросов к БД, а ваш "частотный словарь" для которого называется "статистика индекса".
Если так, то тяжко вам там приходится - писать свой планировщик запросов БД: и не просто, и беда с этим навком - не востребован он среди людей с опытом коммерческого программирования: они все больше штатным планировщиком БД пользуются, да ещё и через SQL и даже ORM при этом. И на вопрос куда с этим навыком в случае чего податься, мне приходит в голову разве что PostgresPro (но это не точно).
Кстати, об админах, которые не знают, не могут и не будут ничего такого мониторить. Мне тут вспонилось время, довольно давнее, когда я работал в некоем банке - так вот, там была специальная группа мониторинга, в которой работали даже не админы, а специально обученные люди. Они работали круглосуточно, в совершенно отдельном помещении, с какой-то навороченной и недешевой прогрограммой, которая мониторила кучу банковских систем - а их там была реально куча, на разных платформах - начиная с оборудования: сетевое, СХД, серверы. События эта система могла мониторить по разным протколам. С Windows, в частности она умела брать данные из стандартных для нее источников: совершенно точно - счетчиков Performance Monitor и записей Event Log, про события WMI(это, в основном, конфигурация, но не только) и ETW (это - стандартная трассировка системы и приложений, которые с ней работать обучены). Пороги оповещений устанавливались ответсвенными за конкретные системы, с учетом опыта эксплуатции (в том числе - инцидентов, эскалированных в техподдержку вендоров).
Ну, а сами админы Windows тоже могли себе мониторинг настроить. Например, "при помощи палки и веревки" - на скриптах на ЛинуксеPowershell (все средства для этого были документированы, и этому даже немного - совсем чуть-чуть - учили на курсах для получения статуса сертифицированных специалистов) - и не только. И настраивали - у эксченжистов, коим я в том некоем банке работал, был, к примеру, для этого трофейный(да, теперь об этом можно рассказать - того банка давно нет) Microsoft Operations Manager, громадным плюсом которого были готовые шаблоны для Exchange. Правда официальный мониторинг с ним не работал (и, кажется, даже не знал про него: анархия там была ещё та, а потому с тех пор я не держу много денег на карточке). А уж разбирательство с логом трассировки прохождения сообщений по почтовой системе - тех самых "перекладываемых байтиков" - это было чуть ли не основным занятием эксченжиста.
Тем не менее, эти админы были не те админы, которые обсуждались выше - которые с опытом два года в эникействе. Так что ваше утверждение что младшему админу негде было бы научиться в мониторинг - оно отчасти все же верно. Ну, а группа мониторинга не сталкивалась со многими другими вещами.
Так что я, похоже, неправильно поставил вопрос, за что получил кучу минусов. Правильным был бы другой вопрос - может ли (и насколько легко) человек, поработавший этим самым младщим админом, изучивший посильное количество теории и сделавший пет-проект, приписать себе коммерческий опыт (чтобы избежать предубеждений против вайтишников) пройти проверку на техсобеседовании для получения оффера на мидла и пройти испытательный срок. Но этот вопрос я как-нибудь в другом обсуждении задам - тут он в коментариях потонет.
А можно я вмешаюсь в ваш разговор с молодежью? А то они тогдашнюю конкретику не знают - а я-то знаю, потому что жил тогда.
Так вот, конкретно в то время (90-91-й) у России и людей в ней было не три пути, как сейчас ;-) а сильно больше. И какой из них был правильным - априори было не очевидным. Так что вам, на самом деле повезло, что вы оказались именно в той тусовке, которая привела вас на место в совместном предприятии/представительстве инофирмы. Таких мест тогда было мало даже в Москве, на всех желающих (и даже достойных того) не хватало. А ещё тусовок (групп, кланов и пр.) было много разных, и априори тогда было непонятно, какая окажется в выигрыше. Например, денег тогда было много во всяких околовоенных темах - которые однако в 1992 обрушились внезапно. И если бы вы оказались в той тусовке, которая занималась чем-то околовоенным, то, возможно, ваша жизнь пошла бы по-другому, и тут тоже есть разные варианты - от миллионеров до покойников, которые поехали в лес (одни, на машине, ночью, в багажнике) и не вернулись. А ещё, хоть вы и пишете, что аж в 1987 осознали, что схемотехника в СССР - это тупик (хотя мои знакомые ещё в 90-92 паяли АОНы и на жизнь не жаловались), но это было не совсем так очевидно. Например, в Зеленограде где-то году в 89 (вы хоть и не успевали попасть, но тем не менее это было близко) развернулось строительство чего-то там грандиозного, куда выпускников брали вовсю. У меня, например, было немало близких и дальних знакомых, которые туда распределились. И, что совершенно в то время было неслыханно - им давали жилье, даже иногородним: одиноким - комнату, семейным, вроде вас тогда - квартиру: это реально известные мне случаи. А с двумя детьми можно было и двушку, наверное, получить: таких знакомых у меня хоть не было, но по нормам жилплощади получалось именно так. Да только вот в 92-м там все умерло. Но жилье даденное у людей все равно осталось, да. И ещё, тот способ, которым вы попали хотя бы в перспективное место, тогда назывался "связи" (сейчас - "нетворкинг"), а скилл, чтобы им воспользоваться - он, вообще-то, для програмистов кросс-классовый (см. правила D&D для пояснений), т.е. - нехарактерный, не только лишь все программисты в него умеют.
Так что, не преуменьшайте роль удачи. А то она обидится и отвернется от вас - что делать-то тогда будете? Удача сама по себе, конечно, ничего не решит, но без нее - никак.
PS Ну, а лично мне пойти по вашему пути помешало бы банальное отсутствие телефона в местности где я жил (именно в местности: телефоны - даже чтобы Скорую вызвать - там были в считанных местах, на местном заводе, к примеру). И это - при том, что эта местность была к Москве даже ближе, чем Крюково. Но у меня, впрочем, был тогда другой путь. Однако это уже совсем другая история.
Ну, мне оно без надобности. Да и большинству "разработчиков с коммерческим опытом" - тоже : нормальные веб-программисты работают любыми базами через ORM, потому что мысльдедлайн, надо фичи в прод катить. Самое ценное в этом решении - термин "lock queue" (она же - "lock tree"): в документации на postgresql.org такого термина не найти (по крайней мере, утка - не находит). Но лучше IMHO - другая ссылка https://joinhandshake.com/blog/our-team/postgresql-and-lock-queue/ - там как раз черным по-английски написано, что запросы на блокировку PostgreSQL обрабатывает (против моих ожиданий) в порядке FIFO (как вам, вроде бы, и надо), и как с этим бороться (когда это не надо) . И если бы вы в статье про эту, недокументированную, особенность PostgreSQL написали сразу - вопроса бы не было. Ну, а я просто приму к сведению.
Так как в Вашем примере удаляются все записи, то PostgreSQL лишь переписывает *_vm файл, отмечая все страницы очищенными.
Ну, не зря - я что-то подобное и предполагал. Однако, тут есть нюанс: "Visibility map bits are only set by vacuum ", т.е. при самом удалении удаленные страницы останутся видимыми, и записи в них как-то нужно пометить, чтобы транзакции, стартовавшие после фиксации удаляющей, их не видели, а вот запущенные до нее - наоборот, - и эти пометки, по логике, должны заехать и в WAL, и в файл с таблицей (детали реализации опять-таки смотреть лень). А карта видимости будет обновлена уже как-нибудь потом.
Как Вы чужими терабайтами разбрасываетесь )
Не, я другим предлагаю разбрасываться - своими терабайтами. Или - не разбрасываться, чисто на их выбор. Главное - чтобы выбор был.
PS Думаю, пора кончать это бзанудство, потому что на полезность вашей статьи оно не влияет, а кого с этими нюансами припрет (а это не я) - сам информацию найдет: в конце концов, есть же исходники.
Использование явной блокировки фиктивного ресурса (advisory lock) взамен неявной реальных ресурсов- оно, конечно полезно: и требование всё делать в одной транзакции снимает, и от deadlock (который иначе не исключен, т.к. требуется блокировка нескольких ресурсов - таблицы и индексов) гарантирует. Но вот проблему с описанным выше сценарием - потоком разделяемых блокировок, мешающим получить эксклюзивную - она не решает. Точнее, решает только при политике, запрещающей выдавать разделяемые блокировки на ресурс при наличии ожидающего запроса на эксклюзивную. Но у такая политика - она, вообще-то, мешает выполнить параллельно те запросы, которые при выдаче блокировки чисто по состоянию ресурса выполнить было бы можно. Так что используется ли в PostgreSQL такая политика (тем более - по умолчанию) - это для меня нерешенный вопрос - в документации верхнего уровня по блокировкам про это не сказано, глубже я не лазил, а из общих соображений использовать такую политику по умолчанию - это сомнительное решение.
Это мелочи по сравнению с удалением записей из таблицы, вместо удаления всей таблицы. Прикиньте нагрузку на WAL.
Ну, нагрузка на WAL - в который запись идет последовательно, что быстрее (на HDD - сильно быстрее) - она всяко меньше чем нагрузка из-за записи в само хранилище пометок о том, что записи после указанной транзакции больше не с нами (детали чего и сколько для этого писать не смотрел). Насчет мелочи это или нет - не знаю: последовательная вставка в записей дерево индекса (особенно - в порядке, постоянно вызывающем его перебалансировку) - это тоже не подарок, создать дерево с нуля при создании индекса может быть сильно лучше. Но нагрузка таки действительно больше, да. А насколько это критично - это надо смотреть по месту, как я уже написал.
Но это все равно нагрузка на БД. В первую очередь на диск. Ведь ему в Вашем сценарии нужно переместить миллиард записей на место мертвых кортежей.
Дык я писал не про VACUUM FULL (который, кстати, автоочистка AFAIK не делает), а про просто VACUUM - который ничего никуда не перемещает, а только помечает ненужные уже удаленные записи как свободное пространство.
И пока он это не сделает, таблица на диске будет занимать двукратный объем.
И пусть занимает. Все равно этот объем дискового пространства должен быть зарезервирован для следующей перезаливки данных в таблицу. А если так, то какая разница где он будет зарезервирован - в свободном пространстве файловой системы или в свободном пространстве внутри файла, принадлежащего БД?
Соображения за ваш варинат понятны, но есть и соображения против. У PosgreSQL поддержка снимков ограничена AFAIK: выполнение операторов DDL с изоляцией через снимок не поддерживатся, операторы DDL, типа ALTER TABLE, требуют накложения на таблицу эксклюзивной блокировки (в Interbase, кстати, по крайней мере версии 4, ЕМНИП, DDL тоже поддерживался через снимки). И если у вас имеются долгие транзакции на чтение из этой таблицы, да ещё и перекрывающиеся друг с другом, то улучить момент для переименования может быть трудно, вплоть до невозможности. Но это уже надо смотреть по месту, для конкретной базы и конкретного профиля нагрузки.
Недостатки альтернативного способа - удаление и заливка данных в одной транзации без операторов DDL - тоже надо смотреть по месту. Например - как много индексов у таблицы: если немного, то замедление в пару разу может быть некритичным. А что до VACUUM, то он может выполняться и в параллель с нормальной работой (и выполняется - автооочисткой) и тут тоже надо смотреть конкретно, успевает ли он подчистить удаленные записи за разумное время. Ну, и статистику пересчитать, чтобы запросы не слишком неоптимальными после очистки были.
Но в целом ваш вариант, как вариант выбора, несомненно заслуживает внимания. Благодарю за статью.
Простой вопрос: а что мешает сделать максимально просто и даже тупо: открыть транзакцию с уровнем изоляции REPEATABLE READ, удалить все старые данные из таблицы, залить туда новые и зафиксировать транзакцию? Ведь если клиенты не изменяют таблицу, а только читают из нее, то они, судя по описанию уровней изоляции в документации, будут видеть либо только старые данные, либо только новые, в зависимости от того, началась ли их читающая транзакция до фиксации обновляющей транзакции или после.
PS Вопрос связан с тем, что в древние времена с Interbase, который изначально имел многоверсионное хранилище, как и современный (ну как современный - четверть века, вроде как) PostgreSQL, такие приемы работали на ура.
Благодарю. Однако вы, похоже, не обратили внимание на вторую часть условия: опыт практической работы в несколько другой области. Вот уж чего-чего, а опыт работы с людьми - с коллегами ("в команде"), с заказчиками и посредниками заказчиков, типа аналитиков, начальниками и пр. - там надбирается быстро: на своей-то шкуре. Общие понимание про костыли (по науке, в ITSM, это называется "обходное решение", в противоположность "структурному") там тоже преобретается довольно быстро и доходчиво, ибо тоже на своей шкуре. Мониторинг - это и админская задача тоже, просто взгляд на него идет с другой стороны: не встроить, а использовать. Но, зная, как использовать, можно догадаться, куда встроить (и можно даже - в пет-проект). Но да, нюансы, требующие именно опыта программирования, тоже остаются, согласен: как принятые решения повлияют на трудоемкость модификации, как код будет держать нагрузку (и что хорошо, если он отреагирует на нее просто тормозами, а не дедлоками или гонками - в наше асинхронное время это запросто). Но что-то мне подсказывает, что для избежания этих нюансов в большинстве случаев можно тупо использовать наилучшие практики: осмысленные имена, разбиение кода на обозримые части, шаблоны проектирования, KISS и SOLID , не лепить "квадраты" (сортировку пузырьком и т.п.) там, где есть хоть намек на расширение (или явно отмечать их как "обходное решение"), явным образом блокировать участки, где есть параллельный доступ, и т.д. - а наилучшим практикам сечас даже студентов учат. То есть, в большинстве случаев тут тоже именно опыт, который "на своей шкуре", не требуется. Ну а меньшинство случаев пусть сеньоры разгребают - зря им что ли деньги плятят :-) Да и что-то подсказывает мне, что типичный мидл-JSONmover и с такими нюансами сталкивается нечасто (но тут утверждать не берусь).
Ало, миддл - это коммерческий опыт разработки, а не "ну я там что-то делал"
А можно с этого места поподробнее?
А то мне непонятео, что такое дает коммерческий опыт разработки, но чего не может дать самостоятельное изучение языка и средств разработки плюс практическая работа в IT в реальной жизни? То есть - работа над пет-проектом, с изучением языка и его механизмов, полученим навыков программирования, изучением типовых инструментов, испольуемых в разработке (Git и пр.), плюс - опыт практической работы пусть и в другой, но смежной области, с усвоение понятий из жизни, типа "дедлайн", "костыль" и пр., пониманием принципов поиска ошибок, уменим пользоваться поиском в Интернете для решения своей конкретной задачи (а не просто нагугливания решения, которое обычно не применимо напрямую, потому что условия несколько различаются), чтения документации (в том числе - неполной и неточной) и прочих прелестей работы, например администратором мелкой фирмы (AKA "многоруким шивой"), плюс обретение соответсвующих полезных социальных навков?
PS Я ничего не пытаюсь ни утверждать, ни опровергать. Я просто хочу понять то, что я не понимаю.
Эти вопросы надо задавать, прежде всего, государству, которое нагружает государственную почтовую службу социальными требованиями и запрещает закрывать экономически неэффективные отделения и отказываться от экономически неэффективных видов деятельности. Но руководству почтовой службы такие вопросы задавать следует тоже, да: пусть они и не могут выйти на окупаемость без отказа от требований государства, но совсем о качестве услуг тоже забывать негоже.
И, насколько мне известно, финансирование государственной почтовой службы - это далеко не только россйская проблема: например, сходные проблемы есть у US Postal Service.
Интересно. Но я вот только не пойму, зачем реляционную CEБД PostgreSQL использовать таким образом - хранить сырые объекты в JSON? Можно ведь использовать объектную NoSQL СУБД - она специально сконструирована под такое использование. Или - с помощью какой-нибудь ОРМ либо вручную отображать объекты на обычные поля обычных таблиц (хотя бы частично, для тех полей, по которым поиск и фильтрация часто производятся)?
Или хранение JSON и манипуляции с ним - это очень маленькая часть большого проекта, которому в остальной части требуется именно реляционная СУБД?
Ну, можете посмотреть и другие примеры других авторов на том же сайте - Мараховский там там не один такой.
Но кое в чём вы всё-таки были правы: журналисту заплатит тот, кто заинтересован. Не правы вы были в другом: в том, что читатели в принципе не являются теми кто платит, платежеспособной аудиторией.
PS Лично мне платная подписка по своему принциипу нравится больше, чем нынешняя модель финансирования публикаций через рекламу. Но чисто конкретных своих денег мне, конечно, жалко.
Журналисту могут заплатить и читатели, через сервис платных подписок, типа Спонсор, Бусти и т.п. И ведь платят, что характерно! Вон, есть такой журналист Мараховский, он на Спонсоре сейчас пишет. Денег с этого немало получает (можете посмотреть - там статистика открытая), и при этом доволен, как слон (постоянно об этом упоминает), что деньги есть, а начальства нет.
Другой вот вопрос - как обычному журналисту свое имя раскрутить, чтобы стать хорошим журналистом, на которого подписываются?
Ну, и самое главное, что проект Samba AD изначально был направлен на создание совместимости с Windows, а не разработку нативного доменного решения для Linux, поэтому участникам Samba Team навсегда уготована роль догоняющих.
Пардон, что там догонять-то?
Вы в курсе, что текущие функциональные уровни домена и леса AD DS для новейшей на сечас версии Windows Server 2022 - то, что определяет возможности AD DS как распределенной базы данных учетных записей - это уровни Windows Server 2016. Что касается клиентов, то они в большинстве случаев нечуствительны даже к таким изменениям этих самых функциональных уровней. То есть, спецификация продукта под названием Active Directory Domain Services не меняется уже почти 8 лет. Неужели за это время нельзя было (при нормальной работе) проапгрейдить роль догоняющих на роль догнавших и на это успокоившихся?
Ну, и прошу вас прояснить вопросы, которые у меня возникли к авторам обзора другой альтернативной службы каталога и централизованной аутентификации (ссылка), потому что упомянутые там возможности вашего продукта мне из этого обзора непонятны
Из обзора совершенно непонятно, что поддерживается каждым продуктом из возможнойстей AD, кроме базовых: каталог LDAP, хранение пользователей и групп в рамках одного домена, доступ к спискам пользователей и групп по протоколу Netlogon, аутентификация с передачей авторизационной информацией по протоколам Kerberos и NTLM. Интересует: -возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации; -возможность хранения в одном каталоге учетных записей и групп для нескольких разных доменов (поддержка леса доменов) с автоматическими доверительными отношениями между этими доменами; -возможность установки доверительных отношений через протоколы NTLM (внешнее доверие) и Kerberos (межлесное доверие); -возможность репликации с контроллерами AD под Windows (поддержка соответствующего протокола репликации)
IMHO в техническом обзоре всё это должно быть.
PS Особенно интересует первый пункт: возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации. Потому что в те времна, когда я смотрел возможности Netscape Directory Server, этой возможности в нем не было.
На собеседовании - ошибка в третьем "Да". Лучше тут было бы сказать "Нет": Из общих соображений понятно, что для всех, кроме узких профессионалов, т.е. - в большинстве случаев, можно обойтись без работы со скрытой по умолчанию служебной информацией. Тут главное не зарываться, а проскочить на минималках: как тот же упомянутый Пиркс, который на экзамене у профессора Меринуса, препа-зверя, свой хор. получил. И на курсах по прохождению собеседований этому, по-хорошему, должны учить.
Но, боюсь, что с нуля такой совет не выполнить, здесь нужна некоторая база, типа списка типовых понятий по каждому продукту (по-хорошему, ее тоже надо давать на тех же курсах): например, заявить про PostgreSQL, что вы не использовали SELECT - это залёт. Короче, тут требуется творческий подход.
PS А если это не совсем на собеседовании, то подходящий ответ вполне гуглится в поставленных вами рамках - например я так нашел это в качестве ответа на ваш последний вопрос
но мне это не нравится
Во мне все восстает против таблиц без первичного ключа, тем тем более, что для поиска можно использовать и более стандартный способ - SELECT DISTINCT ... FROM ... GROUP BY все_поля HAVING COUNT(*)>1
Так что, было бы желание у меня пустить пыль в глаза в том обсуждении вашей статьи - нашел бы способ, быстро. Не факт, конечно, что вышло бы, но у меня даже и желания не было.
PPS А вообще, хорошие общие курсы по прохождению собеседований (краткосрочные, ибо много материала там просто нет) моли бы быть востребованы народом. Только вот для ифноцыган тема сложновата будет, наверное, им такие курсы - как свинью стричь: "визгу много, шерсти мало".
Это я понял по преыдущему ответу.. Но речь шла не о вас, потому что вы - не HR: у вас нет необходимости отсеивать мутный поток негодных соискателей. А HR, если не поставит такой фильтр, то утонет в этом саммом мутном потоке откликов от вайтишников.
но на мой вопрос вы ответили - когда про требование диплома написали: это - ещё более формальный фильтр, и ещё более бессмысленный (если речь не идет от вчерашнем студенте, а, к примеру, о человеке вашего возраста). Правда - труднее фальсифицируемый.
Это я про себя писал - таки не работал.
Ну, я работал-то, в основном, с Interbase - в те годы, когда он был. И его потомками. А с MS SQL - сильно меньше, но заметно позже.
А у Interbase что-то сходное в архитектуре хранилища есть, поскольку у него хранилище - тоже многоверсионное. Например, например, операция уборки неактуальных версий записей у него тоже была, только на уровне не таблиц, а всей БД (sweep).
Ну, а ещё я в том обсуждении не старался делать вид, что я с PostgreSQL хоть как-то активно работал, так что эксперимент не совсем чистый и с этой стороны: соискатель модели "лжец" все-таки будет стараться: например, воспользуется "методом Пиркса" и найдет точные названия всех обсуждаемых служебных полей и прочие необходиммые термины - это поиском по документации находится быстро).
Зачетный ответ. Прямо как правильный ответ на вопрос немцкого теста на восстановление прав для залетевших выпимши за рулем (AKA Idiotentest).
Типичные вопросы там были на тему, что вы будете делать, оказавшись ситуации, связанной с употреблением алкоголя и автомобилем, а правильный ответ - "я не окажусь в такой ситуации".
Но все-таки хотелось бы узнать ваше отношение к лжи, направленной чисто на прохождение формального фильтра. В частности, как бы вы вакансию ни согласовывали, но требование опыта коммерческой разработки для мидла вы из нее не выкинете, так?
В таком случае - вопрос: как вы отнесетесь к человеку, приписавшему себе актуальный коммерческий опыт, чтобы пройти фильтр, и честно скзавшему вам об этом. Для усложнения задачи предположим, что у него есть неактуальный опыт - например, лет пять работы программистом лет пятнадцать назад где-нибудь в тогдашней фирмочке, после - переход куда-нибудь тоже в IT, но не разработчиком: админ, аналитик и т.п. - и знание актуального языка/фреймворка и т.п., подтверждаемое этим самым пет-проектом и проверяемое (в принципе ;-) на техсобесе? По-моему, это удовлетворяет исходному условию: человек, не проходящий без вранья через формальный фильтр, но, в принципе, могущий оказаться годным кандидатом. Что скажете: будете продолжать собеседование, услышав про ложь, или отвергнете соискателя [тут должен быть плакат с образцовым советским человеком, гневно отвергающим протянутый ему стакан водяры]?
Кстати, по этому поводу: чисто для себя поинтересуюсь - вы обратили в нашей с вами недавней дискуссии по вашей статье, что я конкретно c PostgreSQL ни разу не работал? Интересуюсь в контексте чисто теоретического вопроса, который я уже тут задавал : является ли необходимымым/поддается ли симуляции пресловутый "опыт работы"? Правда, эксперимент тут не чистый: я работал, и немало с другими SQL-серверами, начиная с упомянутого там древнего Interbase, а потому, наверное, как раз имею упомянутые вами базовые знания.
Горячо одобряю и поддерживаю. Только вот есть нюанс: как этот честный соискатель, которого вы ищете до вас доберется - если, конечно, он не реальный мидл, причем - с реальным коммерческим опытом разработки именно на вашем конкретном стеке.
С рынка у него же мало шансов пройти формальный фильтр HR. Разве что, как вы - в обход этого фильтра, через связи. Но как я уже писал, умение поддерживать связи для программиста нехарактерно. Да и в целом по стране проблему нехватки разработчиков так не решить (если она есть конечно - потому что, к примеру смысл обсуждаемого высказывания главы Тинька я оцениваю как обращение "дайбаблабля" к Максудову и прочему правительству).
А вот если соискатель последует часто встречающимся (даже тут, на Хабре) рекомендациям соврать про коммерческий опыт и про ваш стек - то как раз до вас, до технического собеседования, то бишь, и доберется.Так что шибко честных ещё до вас отсеют, согласны?
И в связи с этим у меня есть вопрос - как вы среагируете на "сравнительно честного" соискателя, который на техсобесе честно признается вам, что коммерческий опыт он накрутил, чтобы фильтр HR пройти, а на самом деле у него за душой изучение(самостоятельное) и пет-проект (ссылка в резюме), который он, правда, написал сам и без помощи stackoverflow (ну, почти без - он же сравнительно честный, по определению)?
PS И да, ещё, учитывая чтопроверка проверке рознь, пара вопросов. Вот, к примеру, как вы думаете, сможет ли подтвердить свои знания PostgreSQL, типичный разработчик, если ему будет для проверки подкинут сценарий из вашей крайней статьи (которая про очистку громадной таблицы), которую мы с вами вчера-сегодня обсуждали, да ещё и без Гугля.
И будете ли вы задавать такой вопрос с этой целью (информация к размышлению: есть жалобы, опубликованные но не проверенные, что подобные вопросы на техсобесах таки задают)?
Что-то это мне, в рамках моей общей эрудиции, напоминает часть алгоритма планировщика запросов к БД, а ваш "частотный словарь" для которого называется "статистика индекса".
Если так, то тяжко вам там приходится - писать свой планировщик запросов БД: и не просто, и беда с этим навком - не востребован он среди людей с опытом коммерческого программирования: они все больше штатным планировщиком БД пользуются, да ещё и через SQL и даже ORM при этом.
И на вопрос куда с этим навыком в случае чего податься, мне приходит в голову разве что PostgresPro (но это не точно).
Кстати, об админах, которые не знают, не могут и не будут ничего такого мониторить.
Мне тут вспонилось время, довольно давнее, когда я работал в некоем банке - так вот, там была специальная группа мониторинга, в которой работали даже не админы, а специально обученные люди. Они работали круглосуточно, в совершенно отдельном помещении, с какой-то навороченной и недешевой прогрограммой, которая мониторила кучу банковских систем - а их там была реально куча, на разных платформах - начиная с оборудования: сетевое, СХД, серверы. События эта система могла мониторить по разным протколам. С Windows, в частности она умела брать данные из стандартных для нее источников: совершенно точно - счетчиков Performance Monitor и записей Event Log, про события WMI(это, в основном, конфигурация, но не только) и ETW (это - стандартная трассировка системы и приложений, которые с ней работать обучены). Пороги оповещений устанавливались ответсвенными за конкретные системы, с учетом опыта эксплуатции (в том числе - инцидентов, эскалированных в техподдержку вендоров).
Ну, а сами админы Windows тоже могли себе мониторинг настроить. Например, "при помощи палки и веревки" - на скриптах на
ЛинуксеPowershell (все средства для этого были документированы, и этому даже немного - совсем чуть-чуть - учили на курсах для получения статуса сертифицированных специалистов) - и не только. И настраивали - у эксченжистов, коим я в том некоем банке работал, был, к примеру, для этого трофейный(да, теперь об этом можно рассказать - того банка давно нет) Microsoft Operations Manager, громадным плюсом которого были готовые шаблоны для Exchange. Правда официальный мониторинг с ним не работал (и, кажется, даже не знал про него: анархия там была ещё та, а потому с тех пор я не держу много денег на карточке).А уж разбирательство с логом трассировки прохождения сообщений по почтовой системе - тех самых "перекладываемых байтиков" - это было чуть ли не основным занятием эксченжиста.
Тем не менее, эти админы были не те админы, которые обсуждались выше - которые с опытом два года в эникействе. Так что ваше утверждение что младшему админу негде было бы научиться в мониторинг - оно отчасти все же верно. Ну, а группа мониторинга не сталкивалась со многими другими вещами.
Так что я, похоже, неправильно поставил вопрос, за что получил кучу минусов. Правильным был бы другой вопрос - может ли (и насколько легко) человек, поработавший этим самым младщим админом, изучивший посильное количество теории и сделавший пет-проект, приписать себе коммерческий опыт (чтобы избежать предубеждений против вайтишников) пройти проверку на техсобеседовании для получения оффера на мидла и пройти испытательный срок. Но этот вопрос я как-нибудь в другом обсуждении задам - тут он в коментариях потонет.
А можно я вмешаюсь в ваш разговор с молодежью? А то они тогдашнюю конкретику не знают - а я-то знаю, потому что жил тогда.
Так вот, конкретно в то время (90-91-й) у России и людей в ней было не три пути, как сейчас ;-) а сильно больше. И какой из них был правильным - априори было не очевидным.
Так что вам, на самом деле повезло, что вы оказались именно в той тусовке, которая привела вас на место в совместном предприятии/представительстве инофирмы. Таких мест тогда было мало даже в Москве, на всех желающих (и даже достойных того) не хватало.
А ещё тусовок (групп, кланов и пр.) было много разных, и априори тогда было непонятно, какая окажется в выигрыше. Например, денег тогда было много во всяких околовоенных темах - которые однако в 1992 обрушились внезапно.
И если бы вы оказались в той тусовке, которая занималась чем-то околовоенным, то, возможно, ваша жизнь пошла бы по-другому, и тут тоже есть разные варианты - от миллионеров до покойников, которые поехали в лес (одни, на машине, ночью, в багажнике) и не вернулись.
А ещё, хоть вы и пишете, что аж в 1987 осознали, что схемотехника в СССР - это тупик (хотя мои знакомые ещё в 90-92 паяли АОНы и на жизнь не жаловались), но это было не совсем так очевидно. Например, в Зеленограде где-то году в 89 (вы хоть и не успевали попасть, но тем не менее это было близко) развернулось строительство чего-то там грандиозного, куда выпускников брали вовсю. У меня, например, было немало близких и дальних знакомых, которые туда распределились. И, что совершенно в то время было неслыханно - им давали жилье, даже иногородним: одиноким - комнату, семейным, вроде вас тогда - квартиру: это реально известные мне случаи. А с двумя детьми можно было и двушку, наверное, получить: таких знакомых у меня хоть не было, но по нормам жилплощади получалось именно так. Да только вот в 92-м там все умерло. Но жилье даденное у людей все равно осталось, да.
И ещё, тот способ, которым вы попали хотя бы в перспективное место, тогда назывался "связи" (сейчас - "нетворкинг"), а скилл, чтобы им воспользоваться - он, вообще-то, для програмистов кросс-классовый (см. правила D&D для пояснений), т.е. - нехарактерный, не только лишь все программисты в него умеют.
Так что, не преуменьшайте роль удачи. А то она обидится и отвернется от вас - что делать-то тогда будете? Удача сама по себе, конечно, ничего не решит, но без нее - никак.
PS Ну, а лично мне пойти по вашему пути помешало бы банальное отсутствие телефона в местности где я жил (именно в местности: телефоны - даже чтобы Скорую вызвать - там были в считанных местах, на местном заводе, к примеру). И это - при том, что эта местность была к Москве даже ближе, чем Крюково. Но у меня, впрочем, был тогда другой путь. Однако это уже совсем другая история.
Ну, мне оно без надобности. Да и большинству "разработчиков с коммерческим опытом" - тоже : нормальные веб-программисты работают любыми базами через ORM, потому что
мысльдедлайн, надо фичи в прод катить.Самое ценное в этом решении - термин "lock queue" (она же - "lock tree"): в документации на postgresql.org такого термина не найти (по крайней мере, утка - не находит). Но лучше IMHO - другая ссылка https://joinhandshake.com/blog/our-team/postgresql-and-lock-queue/ - там как раз черным по-английски написано, что запросы на блокировку PostgreSQL обрабатывает (против моих ожиданий) в порядке FIFO (как вам, вроде бы, и надо), и как с этим бороться (когда это не надо) . И если бы вы в статье про эту, недокументированную, особенность PostgreSQL написали сразу - вопроса бы не было. Ну, а я просто приму к сведению.
Ну, не зря - я что-то подобное и предполагал. Однако, тут есть нюанс: "Visibility map bits are only set by vacuum ", т.е. при самом удалении удаленные страницы останутся видимыми, и записи в них как-то нужно пометить, чтобы транзакции, стартовавшие после фиксации удаляющей, их не видели, а вот запущенные до нее - наоборот, - и эти пометки, по логике, должны заехать и в WAL, и в файл с таблицей (детали реализации опять-таки смотреть лень). А карта видимости будет обновлена уже как-нибудь потом.
Не, я другим предлагаю разбрасываться - своими терабайтами. Или - не разбрасываться, чисто на их выбор. Главное - чтобы выбор был.
PS Думаю, пора кончать это
бзанудство, потому что на полезность вашей статьи оно не влияет, а кого с этими нюансами припрет (а это не я) - сам информацию найдет: в конце концов, есть же исходники.Использование явной блокировки фиктивного ресурса (advisory lock) взамен неявной реальных ресурсов- оно, конечно полезно: и требование всё делать в одной транзакции снимает, и от deadlock (который иначе не исключен, т.к. требуется блокировка нескольких ресурсов - таблицы и индексов) гарантирует. Но вот проблему с описанным выше сценарием - потоком разделяемых блокировок, мешающим получить эксклюзивную - она не решает. Точнее, решает только при политике, запрещающей выдавать разделяемые блокировки на ресурс при наличии ожидающего запроса на эксклюзивную. Но у такая политика - она, вообще-то, мешает выполнить параллельно те запросы, которые при выдаче блокировки чисто по состоянию ресурса выполнить было бы можно. Так что используется ли в PostgreSQL такая политика (тем более - по умолчанию) - это для меня нерешенный вопрос - в документации верхнего уровня по блокировкам про это не сказано, глубже я не лазил, а из общих соображений использовать такую политику по умолчанию - это сомнительное решение.
Ну, нагрузка на WAL - в который запись идет последовательно, что быстрее (на HDD - сильно быстрее) - она всяко меньше чем нагрузка из-за записи в само хранилище пометок о том, что записи после указанной транзакции больше не с нами (детали чего и сколько для этого писать не смотрел). Насчет мелочи это или нет - не знаю: последовательная вставка в записей дерево индекса (особенно - в порядке, постоянно вызывающем его перебалансировку) - это тоже не подарок, создать дерево с нуля при создании индекса может быть сильно лучше. Но нагрузка таки действительно больше, да. А насколько это критично - это надо смотреть по месту, как я уже написал.
Дык я писал не про VACUUM FULL (который, кстати, автоочистка AFAIK не делает), а про просто VACUUM - который ничего никуда не перемещает, а только помечает ненужные уже удаленные записи как свободное пространство.
И пусть занимает. Все равно этот объем дискового пространства должен быть зарезервирован для следующей перезаливки данных в таблицу. А если так, то какая разница где он будет зарезервирован - в свободном пространстве файловой системы или в свободном пространстве внутри файла, принадлежащего БД?
Соображения за ваш варинат понятны, но есть и соображения против. У PosgreSQL поддержка снимков ограничена AFAIK: выполнение операторов DDL с изоляцией через снимок не поддерживатся, операторы DDL, типа ALTER TABLE, требуют накложения на таблицу эксклюзивной блокировки (в Interbase, кстати, по крайней мере версии 4, ЕМНИП, DDL тоже поддерживался через снимки). И если у вас имеются долгие транзакции на чтение из этой таблицы, да ещё и перекрывающиеся друг с другом, то улучить момент для переименования может быть трудно, вплоть до невозможности. Но это уже надо смотреть по месту, для конкретной базы и конкретного профиля нагрузки.
Недостатки альтернативного способа - удаление и заливка данных в одной транзации без операторов DDL - тоже надо смотреть по месту. Например - как много индексов у таблицы: если немного, то замедление в пару разу может быть некритичным. А что до VACUUM, то он может выполняться и в параллель с нормальной работой (и выполняется - автооочисткой) и тут тоже надо смотреть конкретно, успевает ли он подчистить удаленные записи за разумное время. Ну, и статистику пересчитать, чтобы запросы не слишком неоптимальными после очистки были.
Но в целом ваш вариант, как вариант выбора, несомненно заслуживает внимания. Благодарю за статью.
Простой вопрос: а что мешает сделать максимально просто и даже тупо: открыть транзакцию с уровнем изоляции REPEATABLE READ, удалить все старые данные из таблицы, залить туда новые и зафиксировать транзакцию? Ведь если клиенты не изменяют таблицу, а только читают из нее, то они, судя по описанию уровней изоляции в документации, будут видеть либо только старые данные, либо только новые, в зависимости от того, началась ли их читающая транзакция до фиксации обновляющей транзакции или после.
PS Вопрос связан с тем, что в древние времена с Interbase, который изначально имел многоверсионное хранилище, как и современный (ну как современный - четверть века, вроде как) PostgreSQL, такие приемы работали на ура.
Благодарю.
Однако вы, похоже, не обратили внимание на вторую часть условия: опыт практической работы в несколько другой области. Вот уж чего-чего, а опыт работы с людьми - с коллегами ("в команде"), с заказчиками и посредниками заказчиков, типа аналитиков, начальниками и пр. - там надбирается быстро: на своей-то шкуре. Общие понимание про костыли (по науке, в ITSM, это называется "обходное решение", в противоположность "структурному") там тоже преобретается довольно быстро и доходчиво, ибо тоже на своей шкуре. Мониторинг - это и админская задача тоже, просто взгляд на него идет с другой стороны: не встроить, а использовать. Но, зная, как использовать, можно догадаться, куда встроить (и можно даже - в пет-проект).
Но да, нюансы, требующие именно опыта программирования, тоже остаются, согласен: как принятые решения повлияют на трудоемкость модификации, как код будет держать нагрузку (и что хорошо, если он отреагирует на нее просто тормозами, а не дедлоками или гонками - в наше асинхронное время это запросто).
Но что-то мне подсказывает, что для избежания этих нюансов в большинстве случаев можно тупо использовать наилучшие практики: осмысленные имена, разбиение кода на обозримые части, шаблоны проектирования, KISS и SOLID , не лепить "квадраты" (сортировку пузырьком и т.п.) там, где есть хоть намек на расширение (или явно отмечать их как "обходное решение"), явным образом блокировать участки, где есть параллельный доступ, и т.д. - а наилучшим практикам сечас даже студентов учат. То есть, в большинстве случаев тут тоже именно опыт, который "на своей шкуре", не требуется. Ну а меньшинство случаев пусть сеньоры разгребают - зря им что ли деньги плятят :-) Да и что-то подсказывает мне, что типичный мидл-JSONmover и с такими нюансами сталкивается нечасто (но тут утверждать не берусь).
Но за указание на нюансы благодарю.
А можно с этого места поподробнее?
А то мне непонятео, что такое дает коммерческий опыт разработки, но чего не может дать самостоятельное изучение языка и средств разработки плюс практическая работа в IT в реальной жизни? То есть - работа над пет-проектом, с изучением языка и его механизмов, полученим навыков программирования, изучением типовых инструментов, испольуемых в разработке (Git и пр.), плюс - опыт практической работы пусть и в другой, но смежной области, с усвоение понятий из жизни, типа "дедлайн", "костыль" и пр., пониманием принципов поиска ошибок, уменим пользоваться поиском в Интернете для решения своей конкретной задачи (а не просто нагугливания решения, которое обычно не применимо напрямую, потому что условия несколько различаются), чтения документации (в том числе - неполной и неточной) и прочих прелестей работы, например администратором мелкой фирмы (AKA "многоруким шивой"), плюс обретение соответсвующих полезных социальных навков?
PS Я ничего не пытаюсь ни утверждать, ни опровергать. Я просто хочу понять то, что я не понимаю.
Эти вопросы надо задавать, прежде всего, государству, которое нагружает государственную почтовую службу социальными требованиями и запрещает закрывать экономически неэффективные отделения и отказываться от экономически неэффективных видов деятельности.
Но руководству почтовой службы такие вопросы задавать следует тоже, да: пусть они и не могут выйти на окупаемость без отказа от требований государства, но совсем о качестве услуг тоже забывать негоже.
И, насколько мне известно, финансирование государственной почтовой службы - это далеко не только россйская проблема: например, сходные проблемы есть у US Postal Service.
У вас - совершенно не относящееся к делу замечание. Мы тут, вроде как, про деньги говорим - как журналисту заработать. А не про политику.
Интересно. Но я вот только не пойму, зачем реляционную CEБД PostgreSQL использовать таким образом - хранить сырые объекты в JSON? Можно ведь использовать объектную NoSQL СУБД - она специально сконструирована под такое использование. Или - с помощью какой-нибудь ОРМ либо вручную отображать объекты на обычные поля обычных таблиц (хотя бы частично, для тех полей, по которым поиск и фильтрация часто производятся)?
Или хранение JSON и манипуляции с ним - это очень маленькая часть большого проекта, которому в остальной части требуется именно реляционная СУБД?
Ну, можете посмотреть и другие примеры других авторов на том же сайте - Мараховский там там не один такой.
Но кое в чём вы всё-таки были правы: журналисту заплатит тот, кто заинтересован. Не правы вы были в другом: в том, что читатели в принципе не являются теми кто платит, платежеспособной аудиторией.
PS Лично мне платная подписка по своему принциипу нравится больше, чем нынешняя модель финансирования публикаций через рекламу. Но чисто конкретных своих денег мне, конечно, жалко.
Таки платят. Я же вам не только общие слова сказал, но и пример привёл.
Журналисту могут заплатить и читатели, через сервис платных подписок, типа Спонсор, Бусти и т.п.
И ведь платят, что характерно! Вон, есть такой журналист Мараховский, он на Спонсоре сейчас пишет. Денег с этого немало получает (можете посмотреть - там статистика открытая), и при этом доволен, как слон (постоянно об этом упоминает), что деньги есть, а начальства нет.
Другой вот вопрос - как обычному журналисту свое имя раскрутить, чтобы стать хорошим журналистом, на которого подписываются?
Пардон, что там догонять-то?
Вы в курсе, что текущие функциональные уровни домена и леса AD DS для новейшей на сечас версии Windows Server 2022 - то, что определяет возможности AD DS как распределенной базы данных учетных записей - это уровни Windows Server 2016. Что касается клиентов, то они в большинстве случаев нечуствительны даже к таким изменениям этих самых функциональных уровней. То есть, спецификация продукта под названием Active Directory Domain Services не меняется уже почти 8 лет. Неужели за это время нельзя было (при нормальной работе) проапгрейдить роль догоняющих на роль догнавших и на это успокоившихся?
Ну, и прошу вас прояснить вопросы, которые у меня возникли к авторам обзора другой альтернативной службы каталога и централизованной аутентификации (ссылка), потому что упомянутые там возможности вашего продукта мне из этого обзора непонятны
PS Особенно интересует первый пункт: возможность изменения содержимого каталога параллельно на нескольких контроллерах домена с репликацией этих изменений на другие контроллеры и разрешением конфликтов при репликации. Потому что в те времна, когда я смотрел возможности Netscape Directory Server, этой возможности в нем не было.