Agreed, there are a lot of valid use-cases for host-level virtualization. Another one is testing, where you're able to set up really close-to production systems for staging test.
For the cross-os problem, yeah, you will have to have a bunch of hosts, either physical or virtual, where virtual may save you some problems, and give you others. (The famous system-clock problem in time-critical apps, for example). The important thing here I'd say, would be to still trying to keep the number of OS instances down, since each OS instance by itself will introduce some maintenance, nomatter the hardware it's running on. (Monitoring log-files, proactive and retroactive, security etc.) I often see virtualisation-promotors overlooking that aspect.
As of elastic-cloud-type of applications, I would really like to see OS-level virtualization and traditional high-performance distributed computing compared to host-virtualization.
Especially, for scaling up many applications (not ondemand-hosting many small apps, of course, there host-level virtualization really shines), I would suspect more virtual hosts will do little to nothing, since the app must be written from start to mind parallelism and scaling up, and when that's done, the networking code is a smaller problem.
Agreed, there are a few things that hypervisors does better than most OS:es around. I'm not arguing against the use of host-level virtualization, I'm just questioning 90% of how I see it being used in practice.
As for live migration, it's mostly a question about scaling up, which I would from a purely theoretical standpoint assume think app-level architecture would do a lot better than emulated hardware, especially if the workload is I/O-intensive. Secondly it's not really the most common use-case I see in the world, and by itself far from an case for host-level virtualization.
OR, skip the overhead of virtualization, and use the Operating System.
From webster: operating system : software that controls the operation of a computer and directs the processing of programs (as by assigning storage space in memory and controlling input and output functions)
The key here is program_s_, as opposed to program. A modern server operating system is designed to do most of the things that people is now cheering for virtualisation to do. Virtualisation solutions however, will either evolve into a new operating system, or will lack some of the comforts of an operating system, such as multi-user security, and shared memory optimisations.
One of the funniest uses I've seen in the topic of virtualization were one physical system running two virtual hosts, the first running httpd+tomcat, the second running only the underlying MySQL server used by the tomcat application. What would have been a simple "yum install mysql" were now split into double the maintenance, and crippled to roughly half the performance. (We ourselves ran the exact same software in a bare-OS configuration and achieved close to double the performance on slightly weaker hardware.)
Vendor lock-in, probably in some areas even worse than MSFT.
Personally, I try to avoid stores that forces me to install their program when all I really want is their content.
Imagine if Microsoft.com were only _at all_ accessible from anything but IE? Or if Google would not admit service unless you're using Chrome. Imagine an uproar? Yet that is pretty much what Itunes is.
I.E. why should we let the dominance of Itunes hinder the coming cheap ARM-based netbooks? They certainly won't run i386 windows OR OSX, but have all basic requirement to download and play music.
Personally, I usually try to take it a step further though, and also avoid purchasing Music in patent-covered and/or crappy formats (including MP3). That leaves pretty much Vorbis/FLAC, which sometimes makes it damn hard to find music, so of course I sidestep every now and then, but then more usually to a good ol' plastic CD than other downloadable formats.
While partial encryption strategies for sensitive data may be a good idea, whole-disk-encryption is largely a bad idea. Most users don't really need to encrypt stuff like temporary files, os files, program files etc. It's just the sensitive user-created stuff that may need protection.
I go with similar suggestion as some others here mentioned, focus security on home-directories, possibly removable media (although be careful about user education, ALL removable media should of course not be encrypted). Above all, focus on a strong practice and security around putting stuff in networked storage. That can also help keeping backups, versioning and have other positive side-effects.
It would be refreshing to have the drivers in the kernel, where they belong.
What? Framebuffer isn't enough for ya?
Seriously, it was a sad day that Linus chose to endorse framebuffer instead of a more general solution. (http://www.kgi-project.org/) I know the kernel-devs like small releases and gradual changes, but stuff like the graphics/vt subsystem needs a major overhaul IMHO.
I don't expect them to know, which is why I'm politely trying to teach them.
As someone pointed out earlier in a thread, it's actually _extra_ work to make a.doc if you're mailing in Outlook, when you can just insert the screenshot directly inline in the mail. I usually get appreciation for showing them that. (I also think that you can paste directly in the file-manager, although I don't use windows a lot, so I'm not sure)
I just don't agree with parent that.doc should be accepted as an image-format due to ignorance of the situation of the recipient.
First of all, I don't expect the sender to know anything about this. I've already got proof of the opposite, since they've evidently sent me the image in an inconvenient format. And no, the ticket system has nothing to do with it, it was just an example, but for almost ANY purpose, getting them embedded in a.doc means extra work from me.
Regarding support-fees, you're wrong. I often get mails from co-workers with lower salaries then myself, and also from co-workers with higher salary, and sometimes my own direct or indirect bosses. It really doesn't matter.
The key here is education. While it's frustrating to recieve.doc:s for me, the sender will never know that, unless I politely point it out. I usually sit down, explain the issue, and in a couple of minutes show them how I would like to get the support-mails instead. So far, all I've got is appreciation for politely showing them a better workflow, rather than scoffing at them and insulting them behind their backs, like some of the BOFH:s I've seen do.
However, I DON'T think that it is a viable alternative to just accept, like you suggest, that the sender should just send in whatever ill-formed request they want, and that it's the job of the support guy to sort it out, just because he has lower salary. Support is a two-way street, and I think decent mail-behavior is a skill everyone should learn in this century.
I bet I could send all of those screenshots to/dev/null (digital shredder, kindof), even faster. Doesn't mean it's a useful method.
Whenever you do something FOR someone else (such as sending them screenshots, or any kind of image), you should always try to make it easy for _them_, not for yourself. Especially if it's a support-case and you want help fast.
For me, being the reciever of the image, say I have to upload it to some ticket-system, it takes me a LOT of extra steps extracting them from the Word-document, compared to recieving it in a zip, where many OS:es can even consider it a regular foler and let me upload straight away.
Do they? I'm sure a request of data will be a single packet. Why not wait for a response before requesting another. Keeping network utilisation up just requires opening enough connections.
This would mean hooorible performance in smaller swarms, especially with bad latency.
IMHO, EBML with an extension to the standard to describe id:s used in sub-formats would kick so much ass. As soon as you make it possible to devise general editors for the format, all kinds of possibilities opens up."
That's for stating it more clearly though:D
OTOH, it could improve things like:
* files mixedly edited by hand and by automatic systems (configuration files comes in mind)
* Version-control and diffs could be performed on entities instead of just lines (and friggin line-termination wouldn't have to be such a problem)
* Any XML-routing (XMPP comes to mind) could probably be improved 10-folds performance-wise.
* Regular computer languages such as C, Java or Python could just store the AST (http://en.wikipedia.org/wiki/Abstract_syntax_tree) and it would completely be up to the editor to follow the users preferences for coding-style.
* Probably 10-fold simplicity and performance-boosts in ODF (really, zipping a loose bunch of varying files and you call it a format???)
* Cryptographic signatures/checksums could become universally implemented.
* Transparent filtering (compression and encryption) could also be universally available.
*...
EBML and XML are not exactly equivalent. EBML lacks an equivalent of namespacing, and an EBML-document is self-explanatory, since tag-names are integer-encoded.
IMHO, EBML with an extension to the standard to describe id:s used in sub-formats would kick so much ass. As soon as you make it possible to devise general editors for the format, all kinds of possibilities opens up.
I even took the effort a couple of years ago to jot up a SourceForge project for it, but as with most sourceforge-project I ran out of time soon after.:S http://runestone.sourceforge.net/
"It's not the people who want my property that worry me - it's what they're prepared to do to access the said property."
What worries ME is exactly that kind of thinking. Since you assume THEY are capable of hurting your loved ones, you justify killing THEM. That opinion in widespread form, and you can count on that anyone breaking into your house WILL be prepared to kill you, since they assume otherwise you will kill them.
You enter a bad circle and finally you end up with the middle-east, or for that matter the crime statistics of the U.S. with a homicide-rate of over 5.5%, compared to Sweden with 1.1% (for 2006).
The moral arguments is not about protecting your self. It's the "shoot to kill"-part that worries me, especially to protect your "property".
So if you come home and find some homeless person have broken your window and is working his way through your fridge, you shoot him in the head?
Or even if he's going through your wifes jewelry box (or yours, rumors say there's some girl somewhere in Boston that reads Slashdot), you shoot him in the head without pardon?
Also, I would want a "standards-facist"-mode, where the browsers accepts no workarounds, but yells about error in visited sites. I think it's about time to move away from a web where not half of the sites pass validation.
Storing cache in RAM is an interesting design decision. Usually, you want to selectively work your data up the data-storages, from worstly accessible, to quickest accessible, one step at a time.
In the browser-world, they strangely decided to put web-content (very slow primary access over the net) directly in RAM. I wonder what happened to cache the data in an temporary mmaped file instead. You could still access it as if it was in-memory, but the kernel would be given more options to swap it when other processes needs the ram-pages more. (I.E. for I/O-cache or something else).
For some reason, to many developers "optimizing their program" usually means hogging more system resources, rather making better use of the resources they have. If you're not going to play nice with other processes, you should build micro-kernel appliances instead.
If you think the candidates have a clue ( or care ) what their websites are running on, or could even understand it all you are sadly mistaken. I doubt they even know who is doing their web stuff, its all handled by their respective 'committees'. Doesn't that describe basically ALL politicians in ALL matters? No clue, only survives backed by their support staff?
At least, I think Bush Jr. have proved that a great number of times, trying to speak script-less on his own.
My largest dislike for Java is that there are solutions to almost all of the problems with it, and people defend them because of that, while they really should not have been there from the beginning.
For instance, to even HAVE a typed language without Generics/Templates/something equivalent is just silly. Yes, I know they have it since 1.5, but it should have been there from the beginning.
Also, the way Java tends to encourage complete and misplaced trust in the GC to save the world, to the point where plain old destructors to clean up after yourself is hardly available. Finalizers, allegedly are not guaranteed to run even at a normal exit, (Wtf is that all about?) making them quite useless as a cleanup-mechanism. One fine example is deleteOnExit(). Try Googling it and you'll find a part of the core library API that has little other effects than being one big memory leak. (I just spent hours debugging memory leak in a mission-critical app that turned out to be just that.)
All this turns out in suboptimal solutions, giving me Cobol fingers instead of letting me do something more useful with my time.
When someone ask me, I'd say Java has more or less managed to hit exactly the sour-spot between a quick, agile and productive language such as Python, and a performant and lightwheight language such as C/C++.
If any language manages to find a good compromise in between, though, I would say it's D. I find the Design-By-Contract features to be brilliant, it's flexibility and power is close to Ruby/Python (and combines some of the best aspects of both), while performance and memory-use is fairly close to C++ (and waay better than Java).
Not sure if it's ESX or ESXi but no, it's not the workstation version. ESX 1.5 I think, if that helps. And the arguments still stands, host virtualisation is wildly overrated these days.
Slashdot Mirror
Agreed, there are a lot of valid use-cases for host-level virtualization. Another one is testing, where you're able to set up really close-to production systems for staging test.
For the cross-os problem, yeah, you will have to have a bunch of hosts, either physical or virtual, where virtual may save you some problems, and give you others. (The famous system-clock problem in time-critical apps, for example). The important thing here I'd say, would be to still trying to keep the number of OS instances down, since each OS instance by itself will introduce some maintenance, nomatter the hardware it's running on. (Monitoring log-files, proactive and retroactive, security etc.) I often see virtualisation-promotors overlooking that aspect.
As of elastic-cloud-type of applications, I would really like to see OS-level virtualization and traditional high-performance distributed computing compared to host-virtualization.
Especially, for scaling up many applications (not ondemand-hosting many small apps, of course, there host-level virtualization really shines), I would suspect more virtual hosts will do little to nothing, since the app must be written from start to mind parallelism and scaling up, and when that's done, the networking code is a smaller problem.
Agreed, there are a few things that hypervisors does better than most OS:es around. I'm not arguing against the use of host-level virtualization, I'm just questioning 90% of how I see it being used in practice.
As for live migration, it's mostly a question about scaling up, which I would from a purely theoretical standpoint assume think app-level architecture would do a lot better than emulated hardware, especially if the workload is I/O-intensive. Secondly it's not really the most common use-case I see in the world, and by itself far from an case for host-level virtualization.
OR, skip the overhead of virtualization, and use the Operating System.
From webster:
operating system : software that controls the operation of a computer and directs the processing of programs (as by assigning storage space in memory and controlling input and output functions)
The key here is program_s_, as opposed to program. A modern server operating system is designed to do most of the things that people is now cheering for virtualisation to do. Virtualisation solutions however, will either evolve into a new operating system, or will lack some of the comforts of an operating system, such as multi-user security, and shared memory optimisations.
One of the funniest uses I've seen in the topic of virtualization were one physical system running two virtual hosts, the first running httpd+tomcat, the second running only the underlying MySQL server used by the tomcat application. What would have been a simple "yum install mysql" were now split into double the maintenance, and crippled to roughly half the performance. (We ourselves ran the exact same software in a bare-OS configuration and achieved close to double the performance on slightly weaker hardware.)
There are way to many ignorant users running outdated hardware.
Outdated hardware? Typo, or do IE7/8 really suck that much more out of the system than 6?
If so, FF usually seem like a big performance-lift on all systems where I've tried.
because of outdated intranet software, or just an incompetent IT staff.
Oh, so there's a difference?
I always water-cool my Ethernet ports to make my binary 1:s to 2:s.
Vendor lock-in, probably in some areas even worse than MSFT.
Personally, I try to avoid stores that forces me to install their program when all I really want is their content.
Imagine if Microsoft.com were only _at all_ accessible from anything but IE? Or if Google would not admit service unless you're using Chrome. Imagine an uproar? Yet that is pretty much what Itunes is.
I.E. why should we let the dominance of Itunes hinder the coming cheap ARM-based netbooks? They certainly won't run i386 windows OR OSX, but have all basic requirement to download and play music.
Personally, I usually try to take it a step further though, and also avoid purchasing Music in patent-covered and/or crappy formats (including MP3). That leaves pretty much Vorbis/FLAC, which sometimes makes it damn hard to find music, so of course I sidestep every now and then, but then more usually to a good ol' plastic CD than other downloadable formats.
While partial encryption strategies for sensitive data may be a good idea, whole-disk-encryption is largely a bad idea. Most users don't really need to encrypt stuff like temporary files, os files, program files etc. It's just the sensitive user-created stuff that may need protection.
Especially, some researchers have found that whole-disk-encryption is fairly easy broken (pure software solution) for any machine that has had it's keys in ram (not wiped) up to the last 5 minutes or so. (I.e. in ACPI Standby).
http://news.cnet.com/8301-13578_3-9876060-38.html
http://www.itpro.co.uk/170304/disk-encryption-easily-defeated-research-shows
I go with similar suggestion as some others here mentioned, focus security on home-directories, possibly removable media (although be careful about user education, ALL removable media should of course not be encrypted). Above all, focus on a strong practice and security around putting stuff in networked storage. That can also help keeping backups, versioning and have other positive side-effects.
It would be refreshing to have the drivers in the kernel, where they belong.
What? Framebuffer isn't enough for ya?
Seriously, it was a sad day that Linus chose to endorse framebuffer instead of a more general solution. (http://www.kgi-project.org/) I know the kernel-devs like small releases and gradual changes, but stuff like the graphics/vt subsystem needs a major overhaul IMHO.
As a side-note, FISA in Swedish means "farting" in English. ;) (Yeah, I'm really gonna be that low today)
Interesting idea. :) Or, i suppose I could use something like wv or docvert. In any case, pretty much overhead, in clicks and whatnot.
I don't expect them to know, which is why I'm politely trying to teach them.
As someone pointed out earlier in a thread, it's actually _extra_ work to make a .doc if you're mailing in Outlook, when you can just insert the screenshot directly inline in the mail. I usually get appreciation for showing them that. (I also think that you can paste directly in the file-manager, although I don't use windows a lot, so I'm not sure)
I just don't agree with parent that .doc should be accepted as an image-format due to ignorance of the situation of the recipient.
First of all, I don't expect the sender to know anything about this. I've already got proof of the opposite, since they've evidently sent me the image in an inconvenient format. And no, the ticket system has nothing to do with it, it was just an example, but for almost ANY purpose, getting them embedded in a .doc means extra work from me.
Regarding support-fees, you're wrong. I often get mails from co-workers with lower salaries then myself, and also from co-workers with higher salary, and sometimes my own direct or indirect bosses. It really doesn't matter.
The key here is education. While it's frustrating to recieve .doc:s for me, the sender will never know that, unless I politely point it out. I usually sit down, explain the issue, and in a couple of minutes show them how I would like to get the support-mails instead. So far, all I've got is appreciation for politely showing them a better workflow, rather than scoffing at them and insulting them behind their backs, like some of the BOFH:s I've seen do.
However, I DON'T think that it is a viable alternative to just accept, like you suggest, that the sender should just send in whatever ill-formed request they want, and that it's the job of the support guy to sort it out, just because he has lower salary. Support is a two-way street, and I think decent mail-behavior is a skill everyone should learn in this century.
I bet I could send all of those screenshots to /dev/null (digital shredder, kindof), even faster. Doesn't mean it's a useful method.
Whenever you do something FOR someone else (such as sending them screenshots, or any kind of image), you should always try to make it easy for _them_, not for yourself. Especially if it's a support-case and you want help fast.
For me, being the reciever of the image, say I have to upload it to some ticket-system, it takes me a LOT of extra steps extracting them from the Word-document, compared to recieving it in a zip, where many OS:es can even consider it a regular foler and let me upload straight away.
Do they? I'm sure a request of data will be a single packet. Why not wait for a response before requesting another. Keeping network utilisation up just requires opening enough connections.
This would mean hooorible performance in smaller swarms, especially with bad latency.
Agreed. That's pretty much what meant by:
IMHO, EBML with an extension to the standard to describe id:s used in sub-formats would kick so much ass. As soon as you make it possible to devise general editors for the format, all kinds of possibilities opens up."
That's for stating it more clearly though :D
OTOH, it could improve things like: ...
* files mixedly edited by hand and by automatic systems (configuration files comes in mind)
* Version-control and diffs could be performed on entities instead of just lines (and friggin line-termination wouldn't have to be such a problem)
* Any XML-routing (XMPP comes to mind) could probably be improved 10-folds performance-wise.
* Regular computer languages such as C, Java or Python could just store the AST (http://en.wikipedia.org/wiki/Abstract_syntax_tree) and it would completely be up to the editor to follow the users preferences for coding-style.
* Probably 10-fold simplicity and performance-boosts in ODF (really, zipping a loose bunch of varying files and you call it a format???)
* Cryptographic signatures/checksums could become universally implemented.
* Transparent filtering (compression and encryption) could also be universally available.
*
EBML and XML are not exactly equivalent. EBML lacks an equivalent of namespacing, and an EBML-document is self-explanatory, since tag-names are integer-encoded.
IMHO, EBML with an extension to the standard to describe id:s used in sub-formats would kick so much ass. As soon as you make it possible to devise general editors for the format, all kinds of possibilities opens up.
I even took the effort a couple of years ago to jot up a SourceForge project for it, but as with most sourceforge-project I ran out of time soon after. :S http://runestone.sourceforge.net/
"It's not the people who want my property that worry me - it's what they're prepared to do to access the said property."
What worries ME is exactly that kind of thinking. Since you assume THEY are capable of hurting your loved ones, you justify killing THEM. That opinion in widespread form, and you can count on that anyone breaking into your house WILL be prepared to kill you, since they assume otherwise you will kill them.
You enter a bad circle and finally you end up with the middle-east, or for that matter the crime statistics of the U.S. with a homicide-rate of over 5.5%, compared to Sweden with 1.1% (for 2006).
Information Source:
U.S: http://www.disastercenter.com/crime/uscrime.htm
Sweden: http://www.bra.se/ (authorative statistics-source for crime in Sweden. In Swedish, I think google translate will do a decent job).
The moral arguments is not about protecting your self. It's the "shoot to kill"-part that worries me, especially to protect your "property".
So if you come home and find some homeless person have broken your window and is working his way through your fridge, you shoot him in the head?
Or even if he's going through your wifes jewelry box (or yours, rumors say there's some girl somewhere in Boston that reads Slashdot), you shoot him in the head without pardon?
Seconded.
Also, I would want a "standards-facist"-mode, where the browsers accepts no workarounds, but yells about error in visited sites. I think it's about time to move away from a web where not half of the sites pass validation.
Storing cache in RAM is an interesting design decision. Usually, you want to selectively work your data up the data-storages, from worstly accessible, to quickest accessible, one step at a time.
In the browser-world, they strangely decided to put web-content (very slow primary access over the net) directly in RAM. I wonder what happened to cache the data in an temporary mmaped file instead. You could still access it as if it was in-memory, but the kernel would be given more options to swap it when other processes needs the ram-pages more. (I.E. for I/O-cache or something else).
For some reason, to many developers "optimizing their program" usually means hogging more system resources, rather making better use of the resources they have. If you're not going to play nice with other processes, you should build micro-kernel appliances instead.
At least, I think Bush Jr. have proved that a great number of times, trying to speak script-less on his own.
My largest dislike for Java is that there are solutions to almost all of the problems with it, and people defend them because of that, while they really should not have been there from the beginning.
For instance, to even HAVE a typed language without Generics/Templates/something equivalent is just silly. Yes, I know they have it since 1.5, but it should have been there from the beginning.
Also, the way Java tends to encourage complete and misplaced trust in the GC to save the world, to the point where plain old destructors to clean up after yourself is hardly available. Finalizers, allegedly are not guaranteed to run even at a normal exit, (Wtf is that all about?) making them quite useless as a cleanup-mechanism. One fine example is deleteOnExit(). Try Googling it and you'll find a part of the core library API that has little other effects than being one big memory leak. (I just spent hours debugging memory leak in a mission-critical app that turned out to be just that.)
All this turns out in suboptimal solutions, giving me Cobol fingers instead of letting me do something more useful with my time.
When someone ask me, I'd say Java has more or less managed to hit exactly the sour-spot between a quick, agile and productive language such as Python, and a performant and lightwheight language such as C/C++.
If any language manages to find a good compromise in between, though, I would say it's D. I find the Design-By-Contract features to be brilliant, it's flexibility and power is close to Ruby/Python (and combines some of the best aspects of both), while performance and memory-use is fairly close to C++ (and waay better than Java).
Not sure if it's ESX or ESXi but no, it's not the workstation version. ESX 1.5 I think, if that helps. And the arguments still stands, host virtualisation is wildly overrated these days.