И всё же нет. Ну то есть если вам пофиг на оверхеды или вы надеетесь что компилятор вам всё сам соптимизирует, то можно. Если же не хотите, чтобы ваш софт выполнял кучу лишних копирований, либо просто читаете чей-то код, где автор этого не хотел, то без rvalue-ссылок вам не обойтись. Хотя официальную терминологию со всеми этими xvalue я даже не пытался запомнить.
noscript вроде проверяет и блокирует локальный xss по айпи-адресам (локалхоста и локальных сеток), т.е. смотрит куда резолвится домен
хотя точно не помню уже, могу ошибаться в деталях
Ужасно, как можно на такой элементарный вопрос написать столько текста.
Ну и
Ну и напоследок — как выделить младший бит числа (не знаю, зачем это может потребоваться, но вдруг пригодится)
define LowerBit(N) ((((N) — 1) ^ (N)) & (N)).
define LowerBit(N) ((N) & 1)
А то что у вас — это не младший бит, а младший единичный бит.
Поставить svn сервер, сделать локальный репозиторий, потом скопировать туда директорию, выкачанную из удалённого репозитория, закомитить её, потом сделать дополнительные коммиты в локальный репозиторий, потом скопировать содержимое в удалённый репозиторий и закомитить
Ну, выглядит сложно да, но на деле проще чем кажется. "Поставить svn сервер" и "создать репозиторий" это разовые действия при настройке рабочего компа.
Скачать-скопировать-закоммитить(на самом деле импортировать) это рутина которая легко автоматизируется.
Копировать назад в удалённый вроде не надо — гуи свн клиенты умеют мержить коммиты между репами вроде.
Насчёт того, что с локальным гитом это удобнее — может и так (сам не пробовал это ни с гитом ни с свн).
А вот это
легче реализовать отдельной локалькой копией для каждого коммита в связке с утилитой patch, чем с помощью локального svn, это не вопрос интерфейса, это вопрос отсутствующих фич.
точно нет. Всё же хранить "локальные копии коммитов" в vcs всяко удобнее чем вне её. И функционал "утилиты patch" там тоже есть встроенный.
Можно конечно.
Надо только svn сервер себе поставить для этого. Комитьте туда сколько хотите а потом можно смержить результат наверх. Или можно сделать rebase если мержить не всё сразу, а по одному коммиту (хотя из коробки в один клик такого кажется в svn клиентах нету, но это лишь вопрос пользовательского интерфейса).
Не надо это записывать в минусы по сравнению с гитом: просто в гите этот функционал всегда идёт в комплекте, вне зависимости от его реальной надобности.
Репозиторий — это, я извиняюсь, каталог с определённого вида данными.
Ну, с таким подходом всё встаёт на свои места. Если преподносить гит как движок базы данных для системы контроля версий — то всё так и есть. Действительно, он знает как проводить нужные операции над данными, а остальное его волновать не должно.
Ну и
Вы так и не сказали почему это, собственно, проблема.
для встраиваемой библиотеки движка базы это и правда не проблема.
Но он почему-то везде преподносится как готовый standalone продукт. (у движка базы в первую очередь должно продвигаться и документироваться низкоуровневое api для обращения к нему из приложений, а вовсе не утилиты для командной строки).
А к готовому продукту требования уже (у меня по крайней мере, но думаю это разумно) совсем другие.
Например, от любой коллективно используемой ИТ-системы (не важно, vcs это или нет) я ожидаю наличие логов важных действий — с указанием, кто (логин, возможно адрес), когда и что (в данном случае список запушенных коммитов) сделал. И не прикрученных какими-то костылями, а реализованных монолитно с остальным исходным кодом приложения.
Если есть техническая возможность запретить что-то делать неправильно — то лучше это сделать на уровне техники.
Да, но издавать запреты это прерогатива начальства того сотрудника, которого эти запреты касаются, а вовсе не авторов инструментов. А если начальства нет и проект свой собственный — то вообще непонятно с чего бы кто-то решил мне запрещать его вести так как мне нравится, пусть даже и по чьему-то мнению я делаю это неправильно.
Собственно, я не против ситуации, в которой начальство, отчаявшись заставить своих сотрудников делить проект на компоненты, заставляет их пользоваться гитом с которым по-другому не получится. (хотя неудача в мирном решении данной проблемы наводит на мысли о некомпетентности этого начальства) А вот ситуация "указа не было, по пришлось из-за особенностей инструмента" уже мне совсем не нравится.
Тут все почему-то решили что «нормальное управление доступом» это разграничение доступа по файлам внутри репозитория. Ну да, про это тоже можно было написать, но о таком я, так сказать, от гита даже и не мечтал. У него всё намного хуже. А именно, управления доступом нет ВООБЩЕ.
То есть, если кто-то вообще смог подключиться к репозиторию (и смог/не смог тут решает не гит), то ему сразу всё доступно. Ограничения могут возникнуть только в случае если нижестоящий слой хранилища (файловая система) тупо не даст модифицировать файлы репозитория с теми правами, с которыми запустился процесс гит-клиента.
При этом сам гит вообще не имеет никакого понятия о том, что к нему подключился кто-то конкретный — для него все юзеры по сути анонимны.
Все способы устранить эту проблему неизбежно приводят к использованию какого-то доп. софта, и я не знаю даже, есть ли способ прикрутить его к гиту не традиционно-костыльным способом и не патча сам гит на сервере.
> одно из самых важных вещей, которые пришлось сделать — это поделить проект на компоненты
Смотрится так, как будто руководитель разработки такой дурак, сам не знает что ему надо, а умный гит его заставил сделать правильно. Решение организационных проблем техническими методами? По-моему инструмент должен реализовывать запросы его использующего, вне зависимости от их разумности, а не вынуждать его менять их.
git возможно и хорош для свободной базарной разработки (как у линукса), но для системы с жёстко централизованным репозиторием, каковая имеется, как мне кажется, в большинстве проектов, это перегруженная кучей лишних «фич» гадость (и «инструкция как коммитить» в начале статьи — наглядный тому пример), но при этом не умеющая из коробки такие действительно нужные вещи как нормальное управление доступом и его логирование.
Идеология subversion на мой взгляд намного лучше подходит для таких случаев, а git просто модный и распиаренный всякими гитхабами. В сожалению, из-за распиаренности иногда некоторые инструменты ориентируются эксклюзивно на него, что даёт ему дополнительные преимущества, но это не заслуга самого гита а лишь следствие его модности.
Вы так пишете, как будто не понимаете зачем нужны корневые сертификаты. А нужны они затем, чтобы этот самый удостоверяющий центр можно было идентифицировать и отличить от поддельных удостоверяющих центров.
Аналогично и с сертификатом — обращаются в УЦ за поддтверждением
Чтобы обратиться в УЦ и знать, что это настоящий УЦ а не фейковый — вам нужно заранее иметь его сертификат. А вы только хотите его скачать.
если информация передается подписанной,
До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.
Он же сертификат, его нельзя подменить. Это будет либо не сертификат либо какой-то чужой сертификат. И при подписании/проверки/шифровании.дешифровании все это всплывет. И вам нужно будет все же поставить корневой сертификат вашего УЦ и всю цепочку.
Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.
Извините, но мне кажется это утверждение равносильно тому, как если бы в начале 90-ых вы утверждали об интернете: нужно бояться, что у наших детей не будет альтернативы не подключаться к интернету. Т.е. технология сама по себе не несет негативных последствий.
Эм, ваш пример представляет из себя вполне разумное опасение. И, хотя возможно вы этого не знаете, но сейчас альтернатива НЕ подключаться к интернету всё ещё существует. И правда хорошо бы, чтобы она не потерялась.
Картинка в начале статьи притянула тем что я с ней не согласен. Слева (под красным крестиком) выглядит лучше, удобнее чем справа.
Сама статья какая-то нудная и я её не осилил. И так и не понял связана ли она как-то с картинкой или нет.
Буду очень удивлён, если спецслужбы этим не занимаются и безо всяких поправок, и в отношении кого угодно а не только несовершеннолетних.
Да и насчёт полиции не уверен что они никогда так не делали.
Чтобы старые проекты можно было продолжать собирать со старым диалектом
После такого всем лень будет поддерживать эту опцию и в итоге она сломается и сквозная совместимость будет утеряна. Это если диалект в общем случае.
А вот если речь идёт про только поддержку ключевых слов то наверно можно — ведь там всего лишь надо отключить распознавание токена как ключевого слова.
И где это вы 35км/ч собрались ездить?
Если по тротуарам — то вы, так сказать, нехороший человек. Ваши рассказы про безопасность значения не имеют, вы будете тупо пугать прохожих, даже если реальных аварий и не случится. По мне так вообще никаким колёсным средствам со возможной скоростью выше 15км/ч на тротуаре появляться нельзя — это приоритетная зона для комфортного нахождения на ней пешеходов, безо всяких дискуссий.
Если по проезжей части — проблемы с инстинктом самосохранения, и опять же ваши рассказы о безопасности на поведение окружающих авто никак не повлияют.
У меня тоже возникало такое подозрение по его сообщениям, но судя по профилю это всё-таки не так.
Так что либо он агитированный сектант секты свидетелей анархизма, либо просто тролль. Вступать с ним с дискуссии в обоих случаях нежелательно. Единственное исключение — когда надо предотвратить вредный агитационный эффект от некоторых его сообщений для остальных читателей (которые могут ему поверить, если он вдруг что-то напишет убедительно и никто ему не возразит). Но в этой ветке дискуссии таких мест кажется уже нет.
Вот ещё статья более понятная про это всё habr.com/ru/post/322132
И это, несмотря на всё вышеописанное, хорошо.
хотя точно не помню уже, могу ошибаться в деталях
Ужасно, как можно на такой элементарный вопрос написать столько текста.
Ну и
define LowerBit(N) ((N) & 1)
А то что у вас — это не младший бит, а младший единичный бит.
Ну, выглядит сложно да, но на деле проще чем кажется. "Поставить svn сервер" и "создать репозиторий" это разовые действия при настройке рабочего компа.
Скачать-скопировать-закоммитить(на самом деле импортировать) это рутина которая легко автоматизируется.
Копировать назад в удалённый вроде не надо — гуи свн клиенты умеют мержить коммиты между репами вроде.
Насчёт того, что с локальным гитом это удобнее — может и так (сам не пробовал это ни с гитом ни с свн).
А вот это
точно нет. Всё же хранить "локальные копии коммитов" в vcs всяко удобнее чем вне её. И функционал "утилиты patch" там тоже есть встроенный.
Надо только svn сервер себе поставить для этого. Комитьте туда сколько хотите а потом можно смержить результат наверх. Или можно сделать rebase если мержить не всё сразу, а по одному коммиту (хотя из коробки в один клик такого кажется в svn клиентах нету, но это лишь вопрос пользовательского интерфейса).
Не надо это записывать в минусы по сравнению с гитом: просто в гите этот функционал всегда идёт в комплекте, вне зависимости от его реальной надобности.
Хм а я и не заметил этот пост когда его опубликовали. Не хочу показаться попрошайкой, но возможность комментирования всего раз в сутки очень печалит.
[ -44 / 70 голосов ]
Испорчена в основном по политическим причинам (толерантное отношение к ркн и к государству в целом).
Ну, с таким подходом всё встаёт на свои места. Если преподносить гит как движок базы данных для системы контроля версий — то всё так и есть. Действительно, он знает как проводить нужные операции над данными, а остальное его волновать не должно.
Ну и
для встраиваемой библиотеки движка базы это и правда не проблема.
Но он почему-то везде преподносится как готовый standalone продукт. (у движка базы в первую очередь должно продвигаться и документироваться низкоуровневое api для обращения к нему из приложений, а вовсе не утилиты для командной строки).
А к готовому продукту требования уже (у меня по крайней мере, но думаю это разумно) совсем другие.
Например, от любой коллективно используемой ИТ-системы (не важно, vcs это или нет) я ожидаю наличие логов важных действий — с указанием, кто (логин, возможно адрес), когда и что (в данном случае список запушенных коммитов) сделал. И не прикрученных какими-то костылями, а реализованных монолитно с остальным исходным кодом приложения.
Да, но издавать запреты это прерогатива начальства того сотрудника, которого эти запреты касаются, а вовсе не авторов инструментов. А если начальства нет и проект свой собственный — то вообще непонятно с чего бы кто-то решил мне запрещать его вести так как мне нравится, пусть даже и по чьему-то мнению я делаю это неправильно.
Собственно, я не против ситуации, в которой начальство, отчаявшись заставить своих сотрудников делить проект на компоненты, заставляет их пользоваться гитом с которым по-другому не получится. (хотя неудача в мирном решении данной проблемы наводит на мысли о некомпетентности этого начальства) А вот ситуация "указа не было, по пришлось из-за особенностей инструмента" уже мне совсем не нравится.
То есть, если кто-то вообще смог подключиться к репозиторию (и смог/не смог тут решает не гит), то ему сразу всё доступно. Ограничения могут возникнуть только в случае если нижестоящий слой хранилища (файловая система) тупо не даст модифицировать файлы репозитория с теми правами, с которыми запустился процесс гит-клиента.
При этом сам гит вообще не имеет никакого понятия о том, что к нему подключился кто-то конкретный — для него все юзеры по сути анонимны.
Все способы устранить эту проблему неизбежно приводят к использованию какого-то доп. софта, и я не знаю даже, есть ли способ прикрутить его к гиту не традиционно-костыльным способом и не патча сам гит на сервере.
> одно из самых важных вещей, которые пришлось сделать — это поделить проект на компоненты
Смотрится так, как будто руководитель разработки такой дурак, сам не знает что ему надо, а умный гит его заставил сделать правильно. Решение организационных проблем техническими методами? По-моему инструмент должен реализовывать запросы его использующего, вне зависимости от их разумности, а не вынуждать его менять их.
Идеология subversion на мой взгляд намного лучше подходит для таких случаев, а git просто модный и распиаренный всякими гитхабами. В сожалению, из-за распиаренности иногда некоторые инструменты ориентируются эксклюзивно на него, что даёт ему дополнительные преимущества, но это не заслуга самого гита а лишь следствие его модности.
Вы так пишете, как будто не понимаете зачем нужны корневые сертификаты. А нужны они затем, чтобы этот самый удостоверяющий центр можно было идентифицировать и отличить от поддельных удостоверяющих центров.
Чтобы обратиться в УЦ и знать, что это настоящий УЦ а не фейковый — вам нужно заранее иметь его сертификат. А вы только хотите его скачать.
До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.
Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.
Эм, ваш пример представляет из себя вполне разумное опасение. И, хотя возможно вы этого не знаете, но сейчас альтернатива НЕ подключаться к интернету всё ещё существует. И правда хорошо бы, чтобы она не потерялась.
Сама статья какая-то нудная и я её не осилил. И так и не понял связана ли она как-то с картинкой или нет.
Буду очень удивлён, если спецслужбы этим не занимаются и безо всяких поправок, и в отношении кого угодно а не только несовершеннолетних.
Да и насчёт полиции не уверен что они никогда так не делали.
После такого всем лень будет поддерживать эту опцию и в итоге она сломается и сквозная совместимость будет утеряна. Это если диалект в общем случае.
А вот если речь идёт про только поддержку ключевых слов то наверно можно — ведь там всего лишь надо отключить распознавание токена как ключевого слова.
Если по тротуарам — то вы, так сказать, нехороший человек. Ваши рассказы про безопасность значения не имеют, вы будете тупо пугать прохожих, даже если реальных аварий и не случится. По мне так вообще никаким колёсным средствам со возможной скоростью выше 15км/ч на тротуаре появляться нельзя — это приоритетная зона для комфортного нахождения на ней пешеходов, безо всяких дискуссий.
Если по проезжей части — проблемы с инстинктом самосохранения, и опять же ваши рассказы о безопасности на поведение окружающих авто никак не повлияют.
Так что либо он агитированный сектант секты свидетелей анархизма, либо просто тролль. Вступать с ним с дискуссии в обоих случаях нежелательно. Единственное исключение — когда надо предотвратить вредный агитационный эффект от некоторых его сообщений для остальных читателей (которые могут ему поверить, если он вдруг что-то напишет убедительно и никто ему не возразит). Но в этой ветке дискуссии таких мест кажется уже нет.