Ну или по-Go-шечному, сделать errno таким волшебным словом, которое обозначает не просто переменнию, а тред-локальную. В конце концов, memcpy примерно так и устроен в ряде компиляторов.
Кажется, явтор не понимает, что есть три явления, и они все разные:
При параллельном исполнении нескольких нитей, оперирующих общими данными, трудно угадать, как между собой будут упорядочены действия, осуществляемые разными нитями
Даже в пределах одного потока исполнения (одной нити), компилятор может изменить последовательность действий, если это ему так удобно и если это не меняет семантики кода. При этом для данной конкретной нити ничего не изменится, но если нить имеет доступ к памяти, к которой имеет доступ другие нити, то "глядя со стороны", порядок действий с памятью может измениться.
При исполнении последовательного кода процессор может переупорядочивать инструкции или операции обращения к памяти таким образом, что с точки зрения самого этого последовательного кода ничего не меняется, но глядя с другого ядра (а не нити, как в предыдущем случае) можно увидеть другой порядок обращения к памяти
Чтобы со всем этим можно было жить, существуют примитивы синхронизации, и они разные для разных случаев.
Барьеры памяти - это примитивы синхронизации между ядрами процессора (но разумеется, и компилятор не переставляет последовательные действия мимо барьера).
Я вам в своей области на любой осмысленный вопрос дам вразумительный ответ. Не потому, что я вызубрил всё, а потому, что я ориентируюсь в своей области, понимаю, как жизнь устроена и чего напрямую не знаю, опираясь на понимание вещей и взаимосвязей между ними, соображу.
Но это не значит, что я ходячий справочник. Малозначительные, случайные факты (ну, например, порядок аргументов fopen) я в голове не держу и при необходимости подглядываю в man.
Сотрудник принимается на работу в данную компанию на полный рабочий день, возможность параллельного трудоустройства или подработки на стороне не предусматривается. Компания оставляет за собой право расторгнуть трудовой договор в одностороннем порядке при обнаружении фактов работы сотрудника на другую компанию.
Не бойся тех, кто где-то сильнее тебя. Научись видеть в опытных разработчиках не угрозу, а ресурс.
Это же очень просто решается. Тимлид ведет дела с бизнесом, с вышестоящим начальством, с "большой" компанией. Опытный разработчик хочет понимать, что там в целом творится, потому что это может влиять на принимаемые им решения, но в детали быть погружен не хочет (у него нет на это ресурсов). В то же время, разработчик погружен в технические аспекты проекта, а тимлиду было бы комфортно понимать общую картину, но без излишней детализации.
В целом, тут разные зоны ответственности, и нет повода для ревности. Но есть повод для объединения усилий.
P.S. Плохо, когда тимлид не уверен в себе и хочет во всё лезть. От таких лучше держаться подальше.
В итоге, если мы можем запустить iptables от имени root (то есть, помощью sudo), мы можем использовать его для выполнения произвольных системных команд.
Я что-то не понимаю. Если у нас есть возможность что-то запускать от имени root, то вроде у нас все права уже и без того есть. Зачем к этой конструкции привлекать еще и iptables
Установим iptables и в файл /etc/sudoers добавим следующее:
Ну да. Если ослабить правила sudo, они будут ослабленными :-) В этом вроде нет ничего неожиданного.
Если какая-то команда выглядит безобидно, но требует рутовых прав, может, она не столь уж и безобидна? Может не надо ее всем пользователям подряд так вот бездумно открывать?
Я не про законность. Я про вынос личной переписки на публику без согласия другого участника этой переписки. Закон этого не запрещает, но такое поведение считается не этичным.
Дисклеймер: в статье приведены скриншоты из моих личных переписок с разработчиками. Публикация таких переписок одной из сторон не требует согласия другой
Не берусь судить, является ли в нашей стране публикация выдержек из личной переписки уголовным преступлением, но определенно так делать не принято. На то это и личная переписка.
extern __thread int errno;Ну или по-Go-шечному, сделать
errnoтаким волшебным словом, которое обозначает не просто переменнию, а тред-локальную. В конце концов,memcpyпримерно так и устроен в ряде компиляторов.Это про то, что errno - не обязательно настоящая переменная, а может быть и макрос.
Но в целом, сами по себе POSIX threads стандартизованы в 1995-м...
Торвальдс очень категоричен.
А в POSIX это когда появилось?
И быстренько решили эту проблему, сделав errno thread-local...
Кажется, явтор не понимает, что есть три явления, и они все разные:
При параллельном исполнении нескольких нитей, оперирующих общими данными, трудно угадать, как между собой будут упорядочены действия, осуществляемые разными нитями
Даже в пределах одного потока исполнения (одной нити), компилятор может изменить последовательность действий, если это ему так удобно и если это не меняет семантики кода. При этом для данной конкретной нити ничего не изменится, но если нить имеет доступ к памяти, к которой имеет доступ другие нити, то "глядя со стороны", порядок действий с памятью может измениться.
При исполнении последовательного кода процессор может переупорядочивать инструкции или операции обращения к памяти таким образом, что с точки зрения самого этого последовательного кода ничего не меняется, но глядя с другого ядра (а не нити, как в предыдущем случае) можно увидеть другой порядок обращения к памяти
Чтобы со всем этим можно было жить, существуют примитивы синхронизации, и они разные для разных случаев.
Барьеры памяти - это примитивы синхронизации между ядрами процессора (но разумеется, и компилятор не переставляет последовательные действия мимо барьера).
Ну вот я и не готовлюсь :)
Я вам в своей области на любой осмысленный вопрос дам вразумительный ответ. Не потому, что я вызубрил всё, а потому, что я ориентируюсь в своей области, понимаю, как жизнь устроена и чего напрямую не знаю, опираясь на понимание вещей и взаимосвязей между ними, соображу.
Но это не значит, что я ходячий справочник. Малозначительные, случайные факты (ну, например, порядок аргументов fopen) я в голове не держу и при необходимости подглядываю в man.
Понятно. Спасибо.
Я тоже не готовлюсь. Зачем мне делать вид, что я знаю то, чего я не знаю?
@JuliaRakitina,
а в какой области Вы специализируетесь?
"Некогда думать, трясти надо!" :)
А это, вообще, законно?
Это же очень просто решается. Тимлид ведет дела с бизнесом, с вышестоящим начальством, с "большой" компанией. Опытный разработчик хочет понимать, что там в целом творится, потому что это может влиять на принимаемые им решения, но в детали быть погружен не хочет (у него нет на это ресурсов). В то же время, разработчик погружен в технические аспекты проекта, а тимлиду было бы комфортно понимать общую картину, но без излишней детализации.
В целом, тут разные зоны ответственности, и нет повода для ревности. Но есть повод для объединения усилий.
P.S. Плохо, когда тимлид не уверен в себе и хочет во всё лезть. От таких лучше держаться подальше.
Скажите, а ноутбуки под маркой KVADRA - это ваше изделие?
...и вот теперь я здесь, перед вами.
А разве WebRTC - не единстванная p2p-технология, доступная в веб-бровсере?
А сколько времени тратит WebRTC на установление прямого p2p соединения, включая NAT traversal?
Шелловские скрипты становятся очень хрупкими при работе с именами файлов, которые могут содержать пробелы...
Я что-то не понимаю. Если у нас есть возможность что-то запускать от имени root, то вроде у нас все права уже и без того есть. Зачем к этой конструкции привлекать еще и iptables
Ну да. Если ослабить правила sudo, они будут ослабленными :-) В этом вроде нет ничего неожиданного.
Если какая-то команда выглядит безобидно, но требует рутовых прав, может, она не столь уж и безобидна? Может не надо ее всем пользователям подряд так вот бездумно открывать?
Я не про законность. Я про вынос личной переписки на публику без согласия другого участника этой переписки. Закон этого не запрещает, но такое поведение считается не этичным.
Не берусь судить, является ли в нашей стране публикация выдержек из личной переписки уголовным преступлением, но определенно так делать не принято. На то это и личная переписка.