Даже если допустить, что он спектр анализирует, то выходит, что он анализирует только верхний слой.
И опять же… по спектральному анализу можно только атомный состав определить, как тогда отличить тот же сахар от жира, и то и другое из углерода, водорода и кислорода состоит. С белком-то еще понятно, по азоту его можно определить.
Не в черных списках дело — любая преступная деятельность, произведенная через tor (не все ведь используют его ради обхода блокировок твиттерчиков в турции или реестра роскомнадзора), оставит на конечной точке IP владельца выходной ноды. И докажи потом в случае чего, что это «кто-то в tor». :)
Я об этом и говорю: это наклоном и компенсируется.
Т.е. куб плох тем, что он привязан к нормали относительно поверхности Земли. А произвольным наклоном, настраиваемым в конкретной точке земной поверхности, можно привязать к нормали плоскости эклиптики. В данном случае конечно будут некоторые смещения ввиду того что мы находимся выше/ниже плоскости эклиптики, если разместим ближе к полюсу например, но по идее там угол отклонения пренебрежительно мал.
Насколько я понимаю, проблема привязки к месту и времени года решается установкой куба под правильным углом для конкретного времени и места. Тут уже можно и электронику приделать для корректного позиционирования — красивая идея останется, и будет работать везде (ну может быть кроме полюсов).
Единственное что — его логичнее в таком случае сделать шаром, т.к. он не всегда будет гранью к поверхности повернут.
А этот плагин уже разве умеет без оригинального скайпа работать? Лет 7 назад не умел, т.е. просто транслировал из скайпа в интерфейс миранды, но требовал запущенного скайпа при этом!
Красивого и прозрачного — нет. Только «вручную» сообщить разработчику о необходимости переключиться на такую-то ветку сразу после выполнения мерджа. Судя по всему, гит описанного юзкейса не предусматривает. :(
Думаю что помимо зашифрованного запроса будут туда еще подбрасывать уникальную текстовую «черную метку». Если она всплывает в публичных страницах сайта — санкции (некоторые недобросовестные сеошники вешают перечень поисковых запросов как ссылки на контент, или другим подобным образом используют запросы).
У МКС нет такой сильной гравитации, как у Луны, которая притягивает относительно крупные тела. Для Луны конечно они мелкие, но для пояса, боюсь, будут катастрофичны. Думаю авторы концепта об этом не подумали :) А еще они не подумали о нагреве Земли, вся электроэнергия-то в конечном счете на 99% идет на тепло (если вычесть затраченное на хим. соединения например, хотя они тоже в итоге-то разложатся с выделением тепла).
Да практически ничего. Несколько небольших иксперий есть, но в основном с 512Мб оперативы :( one v — тоже 512. Неужели вайлдфайр был настолько передовой )) Леново А660 — прикольно, что пылезащищен, но опять 512!!! Леново S750 — всем хорош, но 4.5" :(
Черт побери, ну почему опять лопата? Тупо не на что менять почти стершийся HTC WIldfire S с экраном 3.2". Максимум, на что готов пойти в сторону увеличения — 4". Но в таком размере какие-то огрызки. То оперативы 512 (что, неужели за 3 года от вайлдфайра не оторвались?), то еще какая ерунда. Неужели всем нужны 5-дюймовые лопаты?!
Какая-то «зашоренная» точка зрения в статье. Примерно как говорить «дешевая рабская сила вытеснила с рабочих мест феодалов и они теперь плохо живут» )) Похоже автор не представляет себе жизни, где не нужно каждый день ходить на работу и что-то делать, при чем не обязательно оно должно быть полезным и что-то значить — главное сходить и получить за это деньги.
Автоматизация для общества потребления — это хорошо! При том же обеспечении ресурсами у людей освобождается время на более полезные дела, хобби, искусство. Если бы не было автоматизации сейчас — мы бы не на хабре комменты писали, а картошку копали. А так можно за часовую ставку неделю картошку эту кушать — это следствие удешевления и автоматизации производства!
Вы не поняли. Я избегаю не мердж-коммита, а неугодных коммитов в истории.
То есть вот имеется:
master A -> B -> C
shitcommits \ -> D -> E
Т.к. D и E — «не красивая история», делаем squash merge:
master A -> B -> C -> D+E(squash)
shitcommits \ -> D -> E
История мастера красивая: A->B->C->D+E
Но тем временем разработчик продолжает работать над своей веткой.
master A -> B -> C -> D+E(squash)
shitcommits \ -> D -> E -> F
И тут проблемы во всех случаях:
1. Мы забыли про сквош и сделали обычный merge, получаем полную хрень истории главной A -> B -> C -> D -> E -> D+E -> F
2. Мы снова делаем squash commit, и если мы еще и улучшали его код после предыдущего сквоша, получаем конфликты
Если же на шаге создания D+E сделать rebase -i ветки разработчика:
master A -> B -> C -> (merge_shitcommits_r)
shitcommits \ -> D+E -> /
shitcommits[0] \ -> D -> E
То нам необходимо как-то «переопределить» разработчика на новую ребейзнутую ветку, с «перетертой» историей. Простой пуш ребейзнутых веток сами понимаете к чему приводит…
В общем, вот ищу выход из данной ситуации, но так, чтобы это было прозрачно для разработчика, который знает только пару команд гит.
Даже если изменений в них как таковых нет (вызванных конфликтами), они не пустые. Пустым коммит может быть только если он полностью дублирует какой-то предыдущий. Рассмотрим ситуацию:
A->B->C-->(E)
\ /
->D->
в C у нас добавился файл C.txt, в D — соответственно D.txt
Ведь состояние рабочего дерева в E отличается и от C и от D. Значит он не пустой, что, в свою очередь, означает, что это состояние как-то необходимо адресовать, к примеру, для ветвления от него (ветвление в данном случае от C или D не будет тождественно, т.к. в первом случае не будет файла D.txt, а во втором — C.txt).
Отсутствие пустого возможно только в случае fast-forward, то есть если изменения были лишь в одной ветке после ветвления — в этом случае действительно «форсированный» --no-ff сделает «пустой» коммит, где рабочее дерево полностью тождественно дереву из предыдущего коммита.
Если ее отrebase'ить, то ее нельзя будет заpushить. А если заpushить с --force — тогда у горе-разработчиков работа вообще стает :)
Может я не знаю, и ее можно как-то ее отребейзить на сервере «прозрачно» для разработчика, т.е. чтобы у него все автоматом обновилось без лишних вопросов?
Для меня всегда было проблемой, что squash commit не делает струкутрных связей, так что если мы объединили изменения второй ветки в основную, а потом продолжили работу над второй веткой, мы вообще теряем информацию, что в этой второй ветке сквошмерджилось, а что — нет (только в описании сквош-коммита остается текстовая инфа). И далее при классическом мердже этой ветки, то есть «новых» изменений, в историю также попадают ранее смердженные сквошем коммиты, таким образом в общей истории получаем дубль: отдельные говнокоммиты, и их squash-merge.
Логичнее было бы, как мне кажется, некое виртуальное отождествление объединяющего сквош-коммита с теми что в него попали, для того чтобы в последующем они, как тождественные, не попадали в историю ни при каких обстоятельствах.
С горе-разработчиками, которые любят «нагадить в коммитах» очень актуально.
Может есть какая-то фича гита, которая делает именно так как я хочу? Кто как с этим борется? :)
И опять же… по спектральному анализу можно только атомный состав определить, как тогда отличить тот же сахар от жира, и то и другое из углерода, водорода и кислорода состоит. С белком-то еще понятно, по азоту его можно определить.
Т.е. куб плох тем, что он привязан к нормали относительно поверхности Земли. А произвольным наклоном, настраиваемым в конкретной точке земной поверхности, можно привязать к нормали плоскости эклиптики. В данном случае конечно будут некоторые смещения ввиду того что мы находимся выше/ниже плоскости эклиптики, если разместим ближе к полюсу например, но по идее там угол отклонения пренебрежительно мал.
Единственное что — его логичнее в таком случае сделать шаром, т.к. он не всегда будет гранью к поверхности повернут.
Автоматизация для общества потребления — это хорошо! При том же обеспечении ресурсами у людей освобождается время на более полезные дела, хобби, искусство. Если бы не было автоматизации сейчас — мы бы не на хабре комменты писали, а картошку копали. А так можно за часовую ставку неделю картошку эту кушать — это следствие удешевления и автоматизации производства!
То есть вот имеется:
Т.к. D и E — «не красивая история», делаем squash merge:
История мастера красивая: A->B->C->D+E
Но тем временем разработчик продолжает работать над своей веткой.
И тут проблемы во всех случаях:
1. Мы забыли про сквош и сделали обычный merge, получаем полную хрень истории главной A -> B -> C -> D -> E -> D+E -> F
2. Мы снова делаем squash commit, и если мы еще и улучшали его код после предыдущего сквоша, получаем конфликты
Если же на шаге создания D+E сделать rebase -i ветки разработчика:
То нам необходимо как-то «переопределить» разработчика на новую ребейзнутую ветку, с «перетертой» историей. Простой пуш ребейзнутых веток сами понимаете к чему приводит…
В общем, вот ищу выход из данной ситуации, но так, чтобы это было прозрачно для разработчика, который знает только пару команд гит.
в C у нас добавился файл C.txt, в D — соответственно D.txt
Ведь состояние рабочего дерева в E отличается и от C и от D. Значит он не пустой, что, в свою очередь, означает, что это состояние как-то необходимо адресовать, к примеру, для ветвления от него (ветвление в данном случае от C или D не будет тождественно, т.к. в первом случае не будет файла D.txt, а во втором — C.txt).
Отсутствие пустого возможно только в случае fast-forward, то есть если изменения были лишь в одной ветке после ветвления — в этом случае действительно «форсированный» --no-ff сделает «пустой» коммит, где рабочее дерево полностью тождественно дереву из предыдущего коммита.
Может я не знаю, и ее можно как-то ее отребейзить на сервере «прозрачно» для разработчика, т.е. чтобы у него все автоматом обновилось без лишних вопросов?
Логичнее было бы, как мне кажется, некое виртуальное отождествление объединяющего сквош-коммита с теми что в него попали, для того чтобы в последующем они, как тождественные, не попадали в историю ни при каких обстоятельствах.
С горе-разработчиками, которые любят «нагадить в коммитах» очень актуально.
Может есть какая-то фича гита, которая делает именно так как я хочу? Кто как с этим борется? :)