LINUX.ORG.RU
ФорумTalks

Xen переходит с hg на git

 ,


0

2

http://blog.xen.org/index.php/2013/02/25/xen-is-now-officially-in-git/

Xen переходит с hg на git по причине:

one benefit of officially switching to git is that there is now one very officially blessed git history. This means that it will be somewhat easier for git-using contributors to share patch series. But the main benefits are to committers.

.....

Personally, with my committer hat on, I’m already enjoying the convenience of having a single git tree containing all the Xen branches I deal with. And I’ve found that git’s tools for extracting patches from email and applying them are an improvement over what I was using before.

Мне лично не совсем понятно, что им мешало держать все ветки в одном репозитории и в hg. Но в целом, новость весьма печальна, так как такими темпами скоро меркуриал рипнется. И что самое обидное, совсем не из-за технического несовершенства.

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)
Ответ на: комментарий от leave

маразматичное бранчевание, умопомрачительные реверты и всяческие иные stash

так пользоваться надо уметь, а не кричать «фигня, отстой» сразу как что-то начало не получаться

q11q11 ★★★★★
()
Ответ на: комментарий от Sahas

как мне теперь посмотреть весь лог?


если красиво, то

git log --all --oneline --graph --decorate

и по хорошему для этого нужно сделать алиас в ~/.gitconfig
а ещё лучше сделать один алиас для этого, и ещё один для того-же, но без --all
а аналог hg summary будет git status

q11q11 ★★★★★
()
Последнее исправление: q11q11 (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Redmine

эта тулза подавляющим большинством людей используется не по назначению
ну и плагины соответственно притягиваются за уши
как ни парадоксально, но это НЕ багтрэкер
это Project Management tool

q11q11 ★★★★★
()
Последнее исправление: q11q11 (всего исправлений: 1)
Ответ на: комментарий от trex6

Для гит есть git gui и gitk. Их вполне себе хватает для повседневных работ. Что-то более сложное удобно делать в консоли.

я всегда наоборот считал, гуишный гит нужен когда консольного уже не хватает для скорости или ещё чего нибудь, ну типа чтоб быстро много блэймов просмотреть

это я к тому что мне гиушный никогда не был нужен, консоль даёт всё что нужно

q11q11 ★★★★★
()
Ответ на: комментарий от q11q11

Консоль удобнее gitk? Вот когда в консоли можно будет крутить дерево туда-сюда, кликать по коммиту и смотреть его дифф, тогда может быть.

trex6 ★★★★★
()
Ответ на: комментарий от q11q11

В случае, когда необходим какой-нибудь хитрый rebase, подключить удаленный репозиторий. Push/pull тоже делаю из консоли (так уже исторически сложилось).

trex6 ★★★★★
()
Ответ на: комментарий от q11q11

так пользоваться надо уметь

Ну да, нужно уметь стоя, в гамаке, в ластах и маске. Только зачем?

а не кричать «фигня, отстой»

Вещи нужно называть своими именами.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

никто кроме тебя не виноват, в том что ты не туда мержишь, конечно потом реверты нужно делать... но что мешало немного подумать перед коммит-пушем?

но только не говори что HG позволяет делать кашу из веток и хаос из коммитов... и это всё никак не сказывается на проекте

q11q11 ★★★★★
()
Ответ на: комментарий от q11q11

о чем и речь: для vcs у гита слишком высокий порог вхождения

leave ★★★★★
()

Но в целом, новость весьма печальна, так как такими темпами скоро меркуриал рипнется.

с чего-бы? Скорее твой xen рипнется. В тренде сейчас разделение системы на разные машины (облака), что является полной противоположностью виртуализации (когда у тебя на одной машине Over9000 виртуалок). Т.ч. всю твою виртуализацию можно хоронить, ибо не нужно. Вот из-за своей ненужности разрабы и занимаются всякой ерундой.

drBatty ★★
()
Ответ на: комментарий от drBatty

В тренде сейчас разделение системы на разные машины (облака)

у которых внутре неонка^W xen и/или kvm. Если хочешь оспорить - приводи пример реализации облака, где это не так.

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от q11q11

никто кроме тебя не виноват, в том что ты не туда мержишь

Когда ты поймешь, что это не так - считай, повзрослел как специалист.

tailgunner ★★★★★
()
Ответ на: комментарий от qnikst

у которых внутре неонка^W xen и/или kvm. Если хочешь оспорить - приводи пример реализации облака, где это не так.

не смогу, согласен. Но и ты согласись, что это просто костыли для облаков. Со временем отомрут, ибо что-то нормальное сделают. Может даже форк xen. Но в какой DVCS - неизвестно.

drBatty ★★
()
Ответ на: комментарий от drBatty

Но и ты согласись, что это просто костыли для облаков. Со временем отомрут, ибо что-то нормальное сделают. Может даже форк xen.

я знаком лишь с некоторыми технологиями и то поверхностно, так что возможно ты прав. Хотя мне показалось, что пока все крупные игроки используют одну из этих технологий, иногда прилепляя контейнеры для красоты и даже если и пилят что-то свое, то не афишируют. хотя опять же повторюсь я знаком с темой весьма поверхностно.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

я знаком лишь с некоторыми технологиями и то поверхностно, так что возможно ты прав.

технология довольно новая, потому все с ней знакомы поверхностно. Фишка в том, что за очень небольшие деньги мы получаем большую мощность, и непонятно, что с ней собственно делать. Самое тупое, что можно придумать - зафигачить Over9000 виртуалок. Ну так и делают. Но это вопрос времени.

Уверен, что в тех-же гуглооблаках никакого xen'а и близко нет, ибо не нужен. Ну а то, что сейчас продают под видом «облачных технологий», строго говоря к облакам относится слабо. ИМХО.

drBatty ★★
()
Ответ на: комментарий от drBatty

Уверен, что в тех-же гуглооблаках никакого xen'а и близко нет, ибо не нужен.

насколько мне известно, там ganeti, он поверх xen/kvm + есть бекенды на lxc для бедных.

Насколько я понимаю, облака это куча виртуалок + системы дублирования + системы перераспределения ресурсов + использование «распределенных файловых систем», чтобы резервное копирование и восстановление систем не занимало всю работу «кластера». Так что ничего сверх нового, просто красиво собранные технологии обозвали новым словом, и появилось куча денег от инвесторов.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

Фишка в том

что облака неразрывно связаны с виртуализацией. Суть технологии состоит в том, что нет разницы, где выполняется твоя ВМ, она может вживую мигрировать на другой хост, а ты этого не заметишь. ВМ можно «усыпить», можно даже сделать так, что ВМ будет в основном спать, а просыпаться будет после открытия соединения. То самое socket activation из systemd. На голом железе такого не сделаешь.

Ближайший аналог, который я могу придумать — LVM: можно подключить к группе томов ещё один физический том и перекинуть на него корневой раздел работающей ОС не прерывая её работы. Потом отсоединить старый диск, погасить его и вынуть из системы. И всё это online.

i-rinat ★★★★★
()
Ответ на: комментарий от qnikst

облака это куча виртуалок + системы дублирования + системы перераспределения ресурсов + использование «распределенных файловых систем»

ну а я вот совсем по другому понимаю: вот у тебя есть облако на 256 машин и файл, который ты хочешь сохранить. Ты делишь файл на 100 кусков, и отсылаешь каждый кусок на одну машину (в среднем один кусок хранится на 2.56 машин). Когда тебе нужен этот файл, ты его скачиваешь со ста ближайших к данному куску машин и к тебе. Потому скорость закачки у тебя в 100 раз больше. Надёжность хранения тоже увеличивается - если одна или две машины рухнет, то файл ты всё равно скачаешь, возможно чуть медленнее(на доли %). Если рухнет 3 машины, то вероятность успеха очень близка к 100%. Т.к. требования к скорости и надёжности систем очень слабые, то ты можешь на очень слабых и дешёвых компонентах создать быстрый и надёжный сервер. Причём даже в динамике можешь регулировать его скорость и/или надёжность. Тоже самое с _любыми_ задачами. Зачем тут виртуалки над облаком? Какой тебе сейчас нужен сервер - такой и собирай. Виртуалки нужны скорее ПОД облаком, например для аренды VDS как компонента облака (имеет смысл арендовать VDS у разных хостеров, у одного глупо). Тут смысл в том, что систем должно быть МНОГО. Причём широко раскиданных.

drBatty ★★
()
Ответ на: комментарий от i-rinat

что облака неразрывно связаны с виртуализацией. Суть технологии состоит в том, что нет разницы, где выполняется твоя ВМ, она может вживую мигрировать на другой хост, а ты этого не заметишь.

это суть виртуализации, а не облаков. Облако - это когда твоя ВМ распилена на 100500 кусков, а для тебя кажется одним единым сервером. И никуда оно не «мигрирует» в принципе, ибо IRL никакой ВМ не существует. Как не существует облака в небе, а есть только отдельные капли воды.

drBatty ★★
()
Ответ на: комментарий от drBatty

Облако - это когда твоя ВМ распилена на 100500 куско

Просто ты путаешь понятия и понимаешь под облаками то, что другие называют Система Хранения Данных. В одном из предыдущих сообщений ты как раз SAN и описал.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Просто ты путаешь понятия и понимаешь под облаками то, что другие называют Система Хранения Данных. В одном из предыдущих сообщений ты как раз SAN и описал.

я-то как раз и не путаю понятия: SAN это просто самый тупой и примитивный пример облака, когда только данные для хранения так обрабатываются. Однако, никто не запрещает нам обрабатывать так всё что угодно. Не только хранить.

drBatty ★★
()
Ответ на: комментарий от drBatty

я-то как раз и не путаю понятия

Тогда поясни

Облако - это когда твоя ВМ распилена на 100500 кусков, а для тебя кажется одним единым сервером.

другими словами. Как именно распилена, на сколько кусков, что где лежит.

Твои жёсткие диски поди до сих пор используют CHS?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

другими словами. Как именно распилена, на сколько кусков, что где лежит.

распилена случайным образом на все куски равномерно. Лежит тоже где угодно.

Идея проста - от информации(любой. Не только файлы, которые нужно хранить) вычисляется какой-нить криптостойкий хеш, и берутся самые близкие машины к этому хешу. Это наверное самая простая реализация (есть и сложнее). Эти машины как раз и обрабатывают данный кусок информации (в самом примитивном случае тупо сохраняют).

drBatty ★★
()
Ответ на: комментарий от i-rinat

Твои жёсткие диски поди до сих пор используют CHS?

угу.

Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  125045424
	LBA48  user addressable sectors:  125045424
Восемь блоков CHS(по 8063Мб), последний неполный.

А у тебя не так?

И при чём тут это?

drBatty ★★
()
Ответ на: комментарий от drBatty

распилена случайным образом на все куски равномерно. Лежит тоже где угодно.

И ЦПУ и ОЗУ тоже?

от информации(любой. Не только файлы, которые нужно хранить) вычисляется какой-нить криптостойкий хеш

Где вычисляется, чем вычисляется? Мне пришёл пакет на сокет, от него тоже хэш считается? Или вот задача: посчитать хэш от файла. Считаем от него хэш и отправляем... куда? Зачем?

(в самом примитивном случае тупо сохраняют)

Твой «самый примитивный случай» и есть SAN. Ты только о нём и говоришь.

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

Восемь блоков CHS(по 8063Мб), последний неполный.

Бвуа-ха-ха! Что?! Ты это что, серьёзно?!

И при чём тут это?

При том что давно уже диски оперируют LBA, то есть используют виртуализацию. Когда на диске появляется плохо читаемый блок, переназначение тоже происходит прозрачно, а не выпячивает бедблоки наружу, как раньше.

Виртуализация повышает надёжность. Вместо обрушения верхних уровней диск перезапишет данные с плохой дорожки на запасную, отрапортует посредством S.M.A.R.T., а я вставлю новый диск, перекину тома, а затем выну старый. Комп при этом будет недоступен только на время втыкания-вытыкания, ибо для этого я его погашу, минут 5-15 это терпимо. Это не 15-20 часов.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

распилена случайным образом на все куски равномерно. Лежит тоже где угодно.

И ЦПУ и ОЗУ тоже?

конечно ;)

не, ну ЦПУ понятно что пилить не нужно, речь о задачах уровня несколько выше, чем байткод или асм.

Где вычисляется, чем вычисляется? Мне пришёл пакет на сокет, от него тоже хэш считается? Или вот задача: посчитать хэш от файла. Считаем от него хэш и отправляем... куда? Зачем?

хм… Ну вот тебе реализация простого облака в Kademlia: там можно искать файлы по имени. Считаешь хеш имени, отправляешь его «в облако», ближайшим соседям. Они отправляют дальше. С каждым шагом хеш запроса становится ближе к хешу системы. В итоге, системы максимально близкие к запросу как раз и хранят данные о нужном файле.

Ты получаешь данные, а там - хеш. Этот хеш ты опять отправляешь в Сеть, и он опять блуждает, в поисках уже других систем. Так ты получаешь список хешей кусков.

По уму, тут можно было-бы опять отправить хеши в Сеть, дабы получить уже куски фалов и собрать у себя. Но, к сожалению, по организационным причинам получается только список IP, с которых и скачиваешь свои кусочки.

Твой «самый примитивный случай» и есть SAN. Ты только о нём и говоришь.

как в SAN искать информацию?

drBatty ★★
()
Ответ на: комментарий от drBatty

Kademlia

Странные люди от «облаков» хотя гигабайты в секунду, а не килобайты в секунду. И вообще, это уже p2p.

как в SAN искать информацию?

POHMELFS

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Бвуа-ха-ха! Что?! Ты это что, серьёзно?!

не знаю. Команда «hdparam», а не «humor». Думаешь - пасхалка?

При том что давно уже диски оперируют LBA

ну и что? Я и говорю: «LBA из 8 блоков CHS». А то, что LBA использует CHS ты не знал? Ну знай.

Когда на диске появляется плохо читаемый блок, переназначение тоже происходит прозрачно, а не выпячивает бедблоки наружу, как раньше.

а! вот что ты называешь «виртуализацией»? Всё то, что скрыто, и тебе непонятно? Тогда пиво - виртуальное. Ибо я толком не знаю, как его варят на пивзаводе, и откуда там столько спирта.

Виртуализация повышает надёжность. Вместо обрушения верхних уровней диск перезапишет данные с плохой дорожки на запасную, отрапортует посредством S.M.A.R.T., а я вставлю новый диск, перекину тома, а затем выну старый. Комп при этом будет недоступен только на время втыкания-вытыкания, ибо для этого я его погашу, минут 5-15 это терпимо. Это не 15-20 часов.

да. А вот облако ты ВООБЩЕ НЕ БУДЕШЬ ГАСИТЬ, ибо оно будет ПОСТОЯННО работать, даже если один из твоих дисков полностью навернулся. Просто его ёмкость/надёжность упадёт на 0.001%. Теперь тебе понятна разница, между облаком, и твоей «виртуализацией»? Это ведь совсем не сложно.

Облако - это «виртуализация наоборот» - в облаке ты имеешь _одну_ виртуальную машину, которая собрана из множества реальных. Как и в настоящем облаке, потеря одной отдельной частички НИЧЕГО не меняет в общем. Мало того, облако в принципе невозможно «погасить», ибо каждая часть облака прямо контактирует лишь с несколькими другими «каплями». Это надо либо ГЛОБАЛЬНО условия менять, либо как-то заражать облако чем-то, и ждать, пока оно само выпадет.

drBatty ★★
()
Ответ на: комментарий от drBatty

ну а я вот совсем по другому понимаю: вот у тебя есть облако на 256 машин и файл, который ты хочешь сохранить. Ты делишь файл на 100 кусков, и отсылаешь каждый кусок на одну машину (в среднем один кусок хранится на 2.56 машин). Когда тебе нужен этот файл, ты его скачиваешь со ста ближайших к данному куску машин и к тебе. Потому скорость закачки у тебя в 100 раз больше. Надёжность хранения тоже увеличивается - если одна или две машины рухнет, то файл ты всё равно скачаешь, возможно чуть медленнее(на доли %). Если рухнет 3 машины, то вероятность успеха очень близка к 100%. Т.к. требования к скорости и надёжности систем очень слабые, то ты можешь на очень слабых и дешёвых компонентах создать быстрый и надёжный сервер.

это ты примерно описал как работает хранилище в облаке. При этом когда ты запускашь там систему она целиком работает на 1 узле в гипервизоре, и репродуцируется на кусок облака так, чтобы потом с минимальной паузой запустить его на другом, если «основной» хост сдохнет или надо будет мигрировать из-за нагрузок.

При этом сама запущенная система из гипервизора никуда не денется, ну или попробуй описать как будет работать мой вебсервер в моей оси, будучи запущенным в облаке.

Зачем тут виртуалки над облаком?

затем, что юзер не только хостит файлы и БД, а ещё и приложения и сайты, которые должны быть запущены в своей оси, т.е. та же виртуализация.

qnikst ★★★★★
()
Ответ на: комментарий от i-rinat

Странные люди от «облаков» хотя гигабайты в секунду, а не килобайты в секунду

абсолютные числа не имеют значения. И да, Kademlia у меня даёт десятки мегабайт в секунду, и это при том, что народ отдаёт на скорости 4..8Кбайт каждый.

И вообще, это уже p2p.

ну есть торрент - там ты идёшь на сайт, и ищешь название. На сайте тебе дают хеш. С этим хешем твой клиент идёт на треккер, и получает список кусков и список IP, с которых ты можешь что-то скачать.

Вот только перед этим копираст закроет сайт и/или треккер, и ты лосаснёшь тунца. Ибо это НЕ облако, а значит, его можно легко и просто запретить/сломать. Ну а в Kademlia лосасает тунца уже копираст. Единственное, что он может - запрещать поиск в google, но всем пофиг, ибо в Kademlia есть свой поиск. Ну и уныло форсить мемы типа «в осле скорость маленькая». На которые ты ведёшься, прям как на рекламу сникерса ☺

POHMELFS

я там не заметил поиска даже в планах. Ну такого как в Kademlia. Да и вообще это немного не то.

drBatty ★★
()
Ответ на: комментарий от drBatty

Я и говорю: «LBA из 8 блоков CHS». А то, что LBA использует CHS ты не знал? Ну знай.

Это такой бред, что тут и возразить не получается.

Теперь тебе понятна разница, между облаком

http://en.wikipedia.org/wiki/Cloud_computing Прочитай для разнообразия что люди пишут, что ли.

Облако - это «виртуализация наоборот»

Ты похож на человека, который утверждает, что зелёный плохо пахнет. Есть устоявшаяся терминология, и если ты ей не пользуешься, ты не поймёшь других, а они тебя.

i-rinat ★★★★★
()
Ответ на: комментарий от qnikst

При этом сама запущенная система из гипервизора никуда не денется, ну или попробуй описать как будет работать мой вебсервер в моей оси, будучи запущенным в облаке.

вот по тому-то я и говорю, что виртуализация в облаке не нужна. Однако, сам сервер вполне ведь может работать на двух хостах сразу? Да и на трёх - тоже может. Почему - нет? Почему он не может работать на N/M хостах, причём это частное будет зависить и от нагрузки на сервер(вой) и от нагрузки на хост?

затем, что юзер не только хостит файлы и БД, а ещё и приложения и сайты, которые должны быть запущены в своей оси, т.е. та же виртуализация.

ну и пусть хостит - как я уже говорил, считаем хеш от запроса, и отправляем его на ближайшую машину. Так например можно хостить 2 сайта на 3х машинах, при этом каждая машина будет жевать ⅓ запросов. Если одна из машин рухнет, то «ближайших» будет 2 машины, и каждая _автоматически_ начнёт жевать ½ запросов.

Естественно, VDS тут не сделать, но поднять Over9000 сайтов на 100500 железок - легко.

drBatty ★★
()
Ответ на: комментарий от drBatty

На которые ты ведёшься, прям как на рекламу сникерса ☺

Тему сменил, молодец.

Ну такого как в Kademlia. Да и вообще это немного не то.

Точно, не то. Ты наконец уловил суть.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Ты похож на человека, который утверждает, что зелёный плохо пахнет. Есть устоявшаяся терминология, и если ты ей не пользуешься, ты не поймёшь других, а они тебя.

твоя терминология ближе к маркетингу. С технической т.з. такого термина ещё нет. А что там маркетологи пишут - меня мало волнует.

К тому-же, по части определений, вика не столько категорична, как ты. Сам почитай свою ссылку. Ну и процитируй мне строчку о том, что «зелёный не вонючий». А то я что-то устал искать - статья-то большая.

drBatty ★★
()
Ответ на: комментарий от i-rinat

Тему сменил, молодец.

ничего я не менял. Врать про низкую скорость kademlia ты начал.

цитата:

Странные люди от «облаков» хотя гигабайты в секунду, а не килобайты в секунду

мало того, что аргумент вообще не по теме, дык ещё и враньё.

Точно, не то. Ты наконец уловил суть.

суть в том, что ты опять занимаешься демагогией, подсовывая похмелфс в качестве пруфа, а потом говоря, что это действительно не пруф?

Если ты не знал, поиск - это не хранение. В Kademlia поиск есть, причём распределённый, облачный. Попытайся доказать обратное. Если можно - без демагогии.

drBatty ★★
()
Ответ на: комментарий от drBatty

вот по тому-то я и говорю, что виртуализация в облаке не нужна.

не вижу связи

Однако, сам сервер вполне ведь может работать на двух хостах сразу? Да и на трёх - тоже может. Почему - нет?

потому, что синхронизация состояния это слишком затратная процедура.

Такое возможно только для stateless систем причем даже там результат работы будет очень далек от оптимального.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

а потом говоря, что это действительно не пруф?

Когда я сказал, что ты уловил суть, я ошибочно считал, что ты наконец понял, что к обсуждаемым облакам твоя Kademlia не имеет никакого отношения. Я ошибался. Сожалею.

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

А то я что-то устал искать - статья-то большая.

http://en.wikipedia.org/wiki/Cloud_computing#Platform_as_a_service_.28PaaS.29

Usecase. Я хочу запустить вебсервер. Для начала я расчитываю на 10 посещений в час. Возможно, в будущем, посещаемость возрастёт до 1000 в час, но я не знаю когда. Не хочу переплачивать. Теперь расскажи мне, как это сделать при помощи Kademlia.

i-rinat ★★★★★
()
Ответ на: комментарий от qnikst

вот по тому-то я и говорю, что виртуализация в облаке не нужна.

не вижу связи

это я уже понял. ну ещё раз: облако - это такая ерунда, когда 100500 юзеров нападают на один виртуальный сервер(на разных железках). А xen это такая ерунда, когда на одной железке крутятся 100500 серверов. Согласись - совсем иная история.

потому, что синхронизация состояния это слишком затратная процедура.

обоснуй. Возьми например ЛОР - сколько постов добавляется в секунду? Какая мощность для этого нужна? Сколько байт за сутки отправлено на ЛОР (не считая запросов RO, которые можно слать на любую копию)?

Такое возможно только для stateless систем

дык они практически все statless. Точнее - почти statless вне пределов сессии. Т.е. есть атомарное понятие «сессия», а от эти самые сессии друг на друга практически НЕ влияют. А если даже и влияют, то небольшим временным отставанием можно пренебречь. Например: ты находишься за 1000км от меня, и пишешь пост на ЛОР. Я отвечаю. Пока я отвечаю, ты пост удаляешь. Какая мне разница, среагирует «мой» ЛОР на это за 1 секунду, или за 3? Да хоть за 5 минут.

Ну и вообще - клиенты генерируют копеечный трафик НА сервер, ибо потому-что мало того, что тупые, дык ещё и на гнилых каналах. Им надо КАЧАТЬ/СМОТРЕТЬ/СЛУШАТЬ, т.е. ReadOnly. Откуда именно копия - им плевать, лишь-бы хеш совпал и поближе/побыстрее.

drBatty ★★
()
Ответ на: комментарий от i-rinat

Когда я сказал, что ты уловил суть, я ошибочно считал, что ты наконец понял, что к обсуждаемым облакам твоя Kademlia не имеет никакого отношения. Я ошибался. Сожалею.

откуда тебе знать, к чему Kademlia имеет отношение, если ты про неё только по слухам знаешь? Ну вот я тебе рассказываю, как оно изнутри. Не веришь - проверь.

drBatty ★★
()
Ответ на: комментарий от i-rinat

Usecase. Я хочу запустить вебсервер. Для начала я расчитываю на 10 посещений в час. Возможно, в будущем, посещаемость возрастёт до 1000 в час, но я не знаю когда. Не хочу переплачивать. Теперь расскажи мне, как это сделать при помощи Kademlia.

в Kademlia этот вопрос решается автоматически:

  • когда ты решил скачать файл, ты УЖЕ становишься его источником, и твой IP сохраняется в узлах, которые близки к хешу файлов.
  • предположим, ты один такой, и файла ни у кого нет(и у тебя нет). Тогда, твой IP будет лежать на 3-4 машинах, и со временем сотрётся (ты уберёшь файл, никто его не запрашивает, и ты, и он просто вытеснится, ибо там ЕМНИП по 1000 файлов на машину)
  • однако, если файл таки есть, и он (стал) популярным, то источников будет больше, запросов тоже больше, и следовательно систем, где хранится инфа об этом файле (в т.ч. и теперь твой IP) тоже будет больше

в итоге - чем больше запросов, тем больше систем вовлечены в хранение/обработку данного хеша.

Заметь - это без всякого супервизора, и узлы сети даже ничего не знают ни о чём, кроме небольшого списка прямых соседей.

Ну а владельцу облака будет достаточно децентрализовано снимать статистику, и снимать деньги с клиентов, в зависимости от того, сколько нод сети он юзет. Если 3-4 - то копейки, если 300-400 - рубли соответственно.

drBatty ★★
()
Ответ на: комментарий от drBatty

когда ты решил скачать файл

Ты невнимательно читаешь. Я не хочу скачивать файл. Я не хочу размещать файл. Я же сразу сказал: хочу веб-сервер. К примеру, свой клон ЛОРа запустить, с tomcat'ом и postgres'ом. Как у твоей Kademlia с поддержкой tomcat'а и postgres'а?

i-rinat ★★★★★
()
Ответ на: комментарий от tailgunner

Когда ты поймешь, что это не так

иными словами - гит виноват в том что, сидя на одной ветке и делая коммит в другую, ты ловишь конфликты?

q11q11 ★★★★★
()
Ответ на: комментарий от drBatty

вот блин потерял ответ.. так что отвечу короче, чем собирался

ну ещё раз: облако - это такая ерунда, когда 100500 юзеров нападают на один виртуальный сервер(на разных железках). А xen это такая ерунда, когда на одной железке крутятся 100500 серверов. Согласись - совсем иная история.

если образно, то ты прав, а если на самом деле, то облако грубо говоря это 100500 железок, на каждой из которых крутятся 100500 систем причем твоей системы там 1050, а ты видишь только одну. На самом деле все сложнее, но в рамках этой дискуссии это неважно, а важно то, что на каждой ноде стоит гипервизор в котором 100500 систем, только часть из них резервные, часть синхронизируются и т.д. И так будет всегда минимум потому, что голое железо тебе никто выдавать не будет, так же средств для live миграции с одной голой железки на другую нет и пока не предвидится, плюс в этом случае остается overresource, с которым борются и сейчас

дык они практически все statless. Точнее - почти statless вне пределов сессии.

нет, stateless это очень узкая категория. Пример не принимается. Можешь оспаривать, но в следующий раз постарайся описывать ситуацию с другой стороны: привести примеры не stateless, и доказать почему они или сводятся к stateless или облако не для них. Приводить тебе очевидные примеры мне тупо лень.

qnikst ★★★★★
()
Ответ на: комментарий от q11q11

иными словами - гит виноват в том что

...он является корявым говном, неудобным в использовании. То, что неудобные инструменты приводят к большему количеству ошибок, я доказывать не собираюсь.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

т.е. если я скажу, что у меня ошибок в использовании hg было существенно больше, чем при использовании git (а это так), то ты согласишься с тем, что hg говно? или может всё таки руки?

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.