Опубликован (https://github.com/asamy/ksm/releases/tag/v1.5) экспериментальный выпуск проекта KSM 1.5 (https://asamy.github.io/ksm/), в рамках которого развивается простой и быстрый гипервизор для 64-разрядных процессоров Intel, поддерживающих технологии VT-x и EPT. Код KSM написан на языке Си и поставляется (https://github.com/asamy/ksm) под лицензией GPLv2. Из операционных систем поддерживаются Linux и Windows.В отличие от Xen и KVM новый гипервизор не нацелен на обособленный запуск разных операционных систем на одном компьютере. Вместо этого KSM развивается в направлении создания дополнительного уровня защиты для текущей выполняемой ОС, предоставляя sandbox для изоляции приложений с виртуализацией физической памяти и движок для интроспекции операций с памятью. KSM также поддерживает вложенную виртуализацию и может эмулировать окружение для запуска других систем виртуализации, таких как KVM.
Из планов на будущее отмечается поддержка платформы macOS, виртуализация APIC, поддержка UEFI, задействование технологии Intel TXT (Trusted Execution Technology) и поддержка виртуализации на базе AMD-V и NPT.URL: https://github.com/asamy/ksm/releases/tag/v1.5
Новость: http://www.opennet.dev/opennews/art.shtml?num=45946
Что это за хрень на скриншоте? Указатель мыши для слепых?
кнопка "Play"
Тьфу... Ну как я мог сразу догадаться? Жесть полимер-чугунная...
Ты на скриншот кликни, там какой-то коуб/инстаграм/ютуб для кpасноглазых. Вот уж где жесть.
А мне понравилось. От туда текст можно копировать если что, так сказать юзер френдли)
Я правильно понимаю? ньюфаг впервые увидел ascii плеер?
он ещё плёночные фильмы смотрит..
"Forget screen recording apps and blurry video. Enjoy a lightweight, purely text-based approach to terminal recording."
Написано "Легковестный плеер", у меня одного на этом видео кулеры взлететь с системником пытаются?
https://asciinema.org/a/28404
recorde и плеер - это разные вещи
> Написано "Легковестный плеер", у меня одного на этом видео кулеры взлететь с системником пытаются?Все, как обычно. Хипстеры переписали (а скорее всего, переизобрели, потому как ни разу не слышали) утилиту script
https://linux.die.net/man/1/script
> The script command appeared in 3.0BSD.
> Linux July 30, 2000 Linuxна жабоскрипте и решили, что раз кроме браузера для проигрывания ничего не нужно, то это "легковесно" ;)
> Из планов на будущее отмечается поддержка платформы macOSбудущее не в то русло
там он точно не нужен - там jail нормально себя ведет.
Ты хорошо себя чувствуешь?гипервизор != jail
https://ru.wikipedia.org/wiki/KSM
> "..в частности, экспериментальная реализация KSM от Red Hat показала, что 52 виртуальных > экземпляра Windows XP с выделенными 1 ГБ памяти, могут работать на компьютере с 16 ГБ"Это как?
Как как - дедуплекация.Как будто эти 52 винды много чем друг от друга отличаются
>> "..в частности, экспериментальная реализация KSM от Red Hat показала, что 52 виртуальных > экземпляра Windows XP с выделенными 1 ГБ памяти, могут работать на компьютере с 16 ГБ"
> Это как?Могут работать, а могут и не работать.
Или работать, но очень недолго.
Готов для продакшена?
Ну чего тебе не хватает?
Годнота!
Управления гостями как происходит?
С терминала?
Заголовок, как будто убийца KVM вышел. Кто-нить хоть в код то смотрел?Явно пацанчик просто учится. Там полный фарш: сравнения unsigned с -1, кривые "кроссплатформенные" дефайны, которые по-разному ведут себя на винде и линуксах, кривые спецификаторы форматов в printf, какие-то дикие касты несовместимых типов, ворнинги компилятора ваще игнорируются, они ж для слабаков...
Про статический анализ разработчик явно не слышал ни разу.Максимум можно для экспериментов использовать как заготовку для какого-то своего инструмента и понимания принципов работы гипервизоров, не более того.
> Заголовок, как будто убийца KVM вышел. Кто-нить хоть в код то смотрел?
> Явно пацанчик просто учится. Там полный фарш: сравнения unsigned с -1, кривые
> "кроссплатформенные" дефайны, которые по-разному ведут себя на винде и линуксах, кривые
> спецификаторы форматов в printf, какие-то дикие касты несовместимых типов, ворнинги компилятора
> ваще игнорируются, они ж для слабаков...
> Про статический анализ разработчик явно не слышал ни разу.
> Максимум можно для экспериментов использовать как заготовку для какого-то своего инструмента
> и понимания принципов работы гипервизоров, не более того.Your argument is really stupid and the fact that you don't even understand why these warnings are ignored _SPECIFICALLY_ ON Microsoft Compiler (CL) makes it a lot more ignorant and fundamentally wrong and thus stupid. The Microsoft Compiler throws spurious warnings that are simply harmless, the warnings are even substandard, some of which are strict standard compliant, yet still the NTDDK also ignores the same warnings (the native one!), "Wild cast of incompatible types", lol, please go and understand the incompatible types meaning in C first, then argue about it. So that's one thing. I'd assume that you looked at the travis build but haven't even looked at how these warnings come from, right? You're stupid.
Another thing is that you're saying it can be used to learn from only, that's also one stupid argument and is not backed by ANY facts in the slightest, where are your premises? it's actually EXTREMELY stable and has been stressed tested under both Windows and Linux, and it has been used in other productivity software that I won't go through here, and that proves that it is extensible and stable. So, frankly, I'd assume you tried to use it and failed, that's what made you argue about this, so get over it and admit your failure, asking for help via e-mail or github issues is not embarassing, don't worry, nobody cares.
So, quite frankly, your argument is shit, and it's made even more shit by the fact that you have provided 0 premises to back them up.
Sure, I wouldn't argue that I did some mistakes with it, some are horrible, but still, I always fix them immediately when I notice, but still, that doesn't validate your arguments.
>[оверквотинг удален]
> to use it and failed, that's what made you argue about
> this, so get over it and admit your failure, asking for
> help via e-mail or github issues is not embarassing, don't worry,
> nobody cares.
> So, quite frankly, your argument is shit, and it's made even more
> shit by the fact that you have provided 0 premises to
> back them up.
> Sure, I wouldn't argue that I did some mistakes with it, some
> are horrible, but still, I always fix them immediately when I
> notice, but still, that doesn't validate your arguments.To elaborate more on the signed/unsigned comparison thing, I think these have historical reasons, and I was too lazy to remove, if you want them removed, welcome to open source; provide a patch and I will happily apply it.
If you are trying to mimic Torvalds you should spend more time on learning how to use word "bullshit" well and, I believe, you lack Linus's entourage, you are really miss mailing list full of supporters.And... y'know, your sayings is not very smart. If we take into consideration, for instance, casts between different types in C, I could give you three examples of software were such casts are widely used _without_ any compiler warnings despite -Wall used: linux kernel, gtk+, enlightenment libraries. So, just take a look at those code and learn how to deal with casts properly.
> If you are trying to mimic Torvalds you should spend more time
> on learning how to use word "bullshit" well and, I believe,
> you lack Linus's entourage, you are really miss mailing list full
> of supporters.Mimic Torvalds in what exactly? I don't see what you're talking about. I don't need supporters or mailing list to prove someone wrong.
> And... y'know, your sayings is not very smart. If we take into
> consideration, for instance, casts between different types in C, I could
> give you three examples of software were such casts are widely
> used _without_ any compiler warnings despite -Wall used: linux kernel, gtk+,
> enlightenment libraries. So, just take a look at those code and
> learn how to deal with casts properly.You're wrong and yet again, try casting a function pointer to a void pointer (inverse works, too) under both GCC and MSVC, see what you get. I do not have these warnings ignored under GCC, I have them ignored under MSVC, idiot. Both GTK and Linux Kernel use GCC.
> And... y'know, your sayings is not very smart. If we take into
> consideration, for instance, casts between different types in C, I could
> give you three examples of software were such casts are widely
> used _without_ any compiler warnings despite -Wall used: linux kernel, gtk+,
> enlightenment libraries. So, just take a look at those code and
> learn how to deal with casts properly.Also the incompatible pointer warning that was _only_ ignored for just 1 function is from here: https://github.com/asamy/ksm/blob/master/ksm.h#L563 which is reasonable, if you know how to container_of works, then you'll understand why this spurious warning happens. (The funny part, GCC has this problem, but not MSVC, hah.)
>> If you are trying to mimic Torvalds you should spend more time
>> on learning how to use word "bullshit" well and, I believe,
> Mimic Torvalds in what exactly?In your harsh replies to critics, obviously.
> You're wrong and yet again, try casting a function pointer to a
> void pointer (inverse works, too) under both GCC and MSVC, see
> what you get.And what I should get?
$ cat tmp.c
void (*casting_pointers())()
{
void *void_fn = (void*)casting_pointers;
void (*fn)() = (void (*)()) void_fn;
return fn;
}
$ gcc -Wall -c tmp.c
$> I do not have these warnings
> ignored under GCC, I have them ignored under MSVC, idiot.
> Both GTK and Linux Kernel use GCC.I don't know what warnings of MSVC you are talking about, but assuming you are right with it and MSVC warnings are useless, you should use gcc -Wall and its warnings or some external static code analizer to check your code.
> Also the incompatible pointer warning that was _only_ ignored for just 1
> function is from here: https://github.com/asamy/ksm/blob/master/ksm.h#L563 which is
> reasonable, if you know how to container_of works, then you'll understand
> why this spurious warning happens. (The funny part, GCC has
> this problem, but not MSVC, hah.)I bet you are doing it wrong. I have no idea what definitions of ksm and vcpu structs are (I'm too lazy to do such a research), but look:
uintptr_t k = (uintptr_t)container_of(vcpu, struct ksm, vcpu_list);
I'm sure that warnings come from inside of container_of due to wrong type of vcpu. To compile this without warnings struct ksm needs be something like:
struct ksm {
...
struct vcpu vcpu_list;
...
};I suggest that vcpu_list declared as a struct list_head, therefore you are getting those warnings. Clean your code and either make an explicit cast of vcpu to struct list_head*, or change type of an arg in function declaration to reflect the type of field in struct ksm.
> Also the incompatible pointer warning that was _only_ ignored for just 1 function...
If it is true, than I understand your behaviour even less. Why you need to speak about MSVC and your hatred of compiler warnings, instead of clear explanation of the issue? One unresolved warning is not so bad as systematically ignored warnings. Acting such a way you are showing youself as ignorant fool.
> In your harsh replies to critics, obviously.Harsh replies automatically allocate me as Linus Torvalds, ok.
> And what I should get?
> $ cat tmp.c
> void (*casting_pointers())()
> {
> void *void_fn = (void*)casting_pointers;
> void (*fn)() = (void (*)()) void_fn;
> return fn;
> }
> $ gcc -Wall -c tmp.c
> $Under MSVC, you'd get a warning saying you're casting a function pointer to a data pointer, which is why I disable this warning under MSVC only.
> I don't know what warnings of MSVC you are talking about, but
> assuming you are right with it and MSVC warnings are useless,
> you should use gcc -Wall and its warnings or some external
> static code analizer to check your code.It's already implicility used...
>[оверквотинг удален]
> getting those warnings. Clean your code and either make an explicit
> cast of vcpu to struct list_head*, or change type of an
> arg in function declaration to reflect the type of field in
> struct ksm.
>> Also the incompatible pointer warning that was _only_ ignored for just 1 function...
> If it is true, than I understand your behaviour even less. Why
> you need to speak about MSVC and your hatred of compiler
> warnings, instead of clear explanation of the issue? One unresolved warning
> is not so bad as systematically ignored warnings. Acting such a
> way you are showing youself as ignorant fool.You're the ignorant fool here for not bothering to look at the actual definitions before making these arguments, the vcpu_list is not a list_head, it's simply an array of `struct vcpu`, declared as follows:
struct vcpu vcpu_list[MAX_VCPUS];
So my point is still valid, you're (or the other guy) are arguing about ignoring the warnings while they are actually justified and are mostly substandard.
> Harsh replies automatically allocate me as Linus Torvalds, ok.No, you cannot be used as a replacement for him, but still looks similar. At least your first comment in this thread has such funny property.
> the vcpu_list is not a list_head, it's simply an array of `struct vcpu`, declared as follows:
> struct vcpu vcpu_list[MAX_VCPUS];Wow... I'm impressed. Unexpected use for container_of. But yes, you are right about I was a fool, I could catch it looking only into this function, but I didn't.
But nevertheless... You are using container_of in a way its not indended to use. Even without looking on the rest of your code I can say this to you with great confidence. If you do not believe me, you might ask any kernel developer and try to convince him that you have important reasons to such a design that leads to use container_of in this case.
container_of is a tool to design some data structures like list, where different struct types have common parts. For example struct list_head field.
container_of is not a magic way to use pointers into structures as substitute for pointers to structures. Because container_of is using explicit casts which is bad. Such casts used everywere in kernel not because it is a good practice, but because C gives no other ways to do some things. Pointer arith even worse, but in some cases its the only choice also. Your case is not valid case for using pointer arith, expicit casts and container_of.Just add to struct vcpu field `struct ksm *parent', and your vcpu_to_ksm will not need any casts anymore. Its completely safe: such a pointer will not become dangling, because struct vcpu shares lifetime with containing struct ksm. Just do not forget to initialize this pointer.
> Wow... I'm impressed. Unexpected use for container_of. But yes, you are right
> about I was a fool, I could catch it looking only
> into this function, but I didn't.Good thing you admit your failure, that's one step forward.
> But nevertheless... You are using container_of in a way its not indended
> to use. Even without looking on the rest of your code
> I can say this to you with great confidence. If you
> do not believe me, you might ask any kernel developer and
> try to convince him that you have important reasons to such
> a design that leads to use container_of in this case.
>
> container_of is a tool to design some data structures like list, where
> different struct types have common parts. For example struct list_head field.Have common parts? What? You really need to work on your understanding of things, the use of container_of is for container-structures of a single structure where you would have a pointer to that container-structure, then you can subtract it with the offset in the parent structure to get a pointer to the parent structure.
> container_of is not a magic way to use pointers into structures as
> substitute for pointers to structures. Because container_of is using explicit casts
> which is bad. Such casts used everywere in kernel not because
> it is a good practice, but because C gives no other
> ways to do some things. Pointer arith even worse, but in
> some cases its the only choice also. Your case is not
> valid case for using pointer arith, expicit casts and container_of.So you're arguing about pointer arithmetic being bad, but yet your compiler deploys it all day long because of your indirect use, but having a function such as offsetof, invalidates the use, good arguments you make, mate...
> Just add to struct vcpu field `struct ksm *parent', and your vcpu_to_ksm
> will not need any casts anymore. Its completely safe: such a
> pointer will not become dangling, because struct vcpu shares lifetime with
> containing struct ksm. Just do not forget to initialize this pointer.I'd rather laugh at confused people while they try to understand my code.
> I'd rather laugh at confused people while they try to understand my
> code.I see... You are not enlightened yet. So, go away and code. And do not come back until enlightened.
> I see... You are not enlightened yet. So, go away and code.
> And do not come back until enlightened.At least I understand shit before I try to argue they are wrong.
You're the one interested in my stuff regardless. Anyways, point proven, no need for me to come here again. The only reason I came was through Github Traffic, it got an abnormal amount of traffic and I was surprised because I did not advertise it, so it seemed to point to here and 2 other articles on the web.
> At least I understand shit before I try to argue they are wrong.I'm not trying to be offensive, but arguing is also the way do discover things. Yes I might clone your repo, run etags on it and find definitions of all structs, lurk some time in different parts of code, and become much more correct with my initial guesses about reasons behind the patterns used. But nevertheless my guesses would remains just guesses. Now my knowledge is more reliable. I cleared my mind from influence of OP's opinion and your hostile behaviour. I have built my own opinion instead. And, I hope, you also got something from discussion. I hope I was not just using you for reaching my goals, but giving you something also.
And one more hint. Less subtle. Psychologists tend to differentiate two strategies of behaviour: need for success and failure avoidance. And I work hard to bring myself to the first. I'd like to fail in discussion, which not a super important to me -- it costs me nothing. But I can get some information while losing. So I came to success while failing. The most of the people are unable to do it. I'm trying to become not like them but stronger.
> The only reason I came was through Github Traffic, it got an abnormal amount of traffic and I was surprised because I did not advertise it, so it seemed to point to here and 2 other articles on the web.
Gratz. :)
>простой и быстрый гипервизор для 64-разрядных процессоров IntelДавайте теперь напишем отдельный для AMD, потом для ARM и т. д. - каждому процу по своей виртуалке!
Как было замечено выше, это любительский проект одиночки. Какой процессор на его локалхосте стоит, под такой и пишет.
>>простой и быстрый гипервизор для 64-разрядных процессоров Intel
> Давайте теперь напишем отдельный для AMD, потом для ARM и т. д.
> - каждому процу по своей виртуалке!Правильно UNIX way - одна задача - одна программа. Только перенести эту аксиому на процессоры.
А если в слове ХЛЕБ сделать четыре ошибки, то получится ПИВО.
А если пять ошибок - получится слово ВОДКА, ага