Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ubuntu Picks Upstart, KVM

kdawson posted more than 6 years ago | from the their-own-sweet-way dept.

Software 97

derrida writes "Because the traditional System V init daemon (SysVinit) does not deal well with modern hardware, including hotplug devices, USB hard and flash drives, and network-mounted filesystems, Ubuntu replaced it with the upstart init daemon. Several other replacements for SysVinit are also available. One of the most prominent, initng, is available for Debian and runs on Ubuntu. Solaris uses SMF (Service Management Facility) and Mac OS uses launchd. Over time, Ubuntu will likely come to incorporate features of each of these systems into Upstart. Furthermore, heading in a different direction from its main rivals, Ubuntu Linux will use KVM as its primary virtualization software. Red Hat Enterprise Linux and Novell's Suse Linux Enterprise Server both use the Xen virtualization software, a 'hypervisor' layer that lets multiple operating systems run on the same computer. In contrast, the KVM software runs on top of a version of Linux, the 'host' operating system that provides a foundation for other 'guest' operating systems to run in a virtual mode." Slashdot shares a corporate overlord with Linux.com.

cancel ×

97 comments

Sorry! There are no comments related to the filter you selected.

Great (4, Informative)

laptop006 (37721) | more than 6 years ago | (#22387526)

Except Upstart has been in Ubuntu since IIRC 6.10, nothing has even changed about the design.

Re:Great (1, Informative)

Anonymous Coward | more than 6 years ago | (#22387810)

I cannot find any reference to initng in the Debian repositories, but Upstart is in Debian experimental http://packages.debian.org/experimental/upstart [debian.org]

Re:Great (1)

SigmundFloyd (994648) | more than 6 years ago | (#22400970)

Ubuntu 6.10 uses SysV-style boot scripts.

News? (4, Insightful)

webmaster404 (1148909) | more than 6 years ago | (#22387654)

How is this news? The Ubuntu project came up with Upstart and therefore they are going to use it? Whats next Debian using apt-get rather then RPM?

Re:News? (2, Informative)

macshit (157376) | more than 6 years ago | (#22387744)

Agreed, upstart doesn't seem like news, but I'd be curious to hear a bit of back-and-forth as to the benefits of the various initscript replacements. Ubuntu makes a case for upstart on their site; it would be nice to known what others think.

Similarly for kvm vs. xen: xen is on roll these days, with everybody and their dog using it, but it seems like the company behind it is moving in an increasingly proprietary direction, so it would be good to hear what's up with that, and how kvm compares.

Re:News? (1)

KwKSilver (857599) | more than 6 years ago | (#22388106)

Interesting discussion here [osnews.com] . Along with a couple low-temp flame-squabbles.

Re:News? (1)

calebt3 (1098475) | more than 6 years ago | (#22388154)

a couple low-temp flame-squabbles
I think the term you are looking for is "Bunsen Burner Battles"

Re:News? (2, Funny)

KwKSilver (857599) | more than 6 years ago | (#22388324)

more like "Zippos at five paces." Shockingly polite disagreements at that.

Re:News? (0)

Anonymous Coward | more than 6 years ago | (#22389258)

"Agreed, upstart doesn't seem like news"

Nor KVM, either. Red Hat has already stated that they'll go the KVM way in favour of Xen as their virtualization of choice (currently they are developing VM management tools which try to be "vendor-neutral").

Re:News? (1)

pipatron (966506) | more than 6 years ago | (#22390592)

so it would be good to hear what's up with that, and how kvm compares.

Because KVM requires hardware support for the virtualization, it won't work on any of my computers.

Xen does.

Re:News? (1)

GundamFan (848341) | more than 6 years ago | (#22391566)

That is a rather loose definition of "works" from my experience.

We tried Xen as a possible alternative to VMware and it isn't even close.

On the flip side... (1)

Ayanami Rei (621112) | more than 6 years ago | (#22400182)

With VMware you can't arbitarily set your MAC address to whatever you want. How else am I going to virtualize the machines running all my expensive license servers? You can't dynamically add CPUs or RAM to guest instances. You can't migrate running instances without the expensive VMotion add-on. And so forth.

What Xen is missing is a nice console. Maybe in version 4.

Re:News? (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#22387748)

"Slashdot shares a corporate overlord with Linux.com."

-1 redundant, Idiot mod, this is why (1)

marcus (1916) | more than 6 years ago | (#22390494)

It made the news.

Who's the dolt that doesn't recognize "insightful"?

Re:News? (1)

Tarlus (1000874) | more than 6 years ago | (#22392968)

Not to mention, I think they've been using upstart since version 7.04.

Slashdot
Facts for nerds. Stuff that matters.

Re:News? (1)

doas777 (1138627) | more than 6 years ago | (#22394220)

ummmm... KVM is an upstart in the Virtulazation market. thats what they're saying.... they are not refering to a peice of software called "Upstart".

Re:News? (0)

Anonymous Coward | more than 6 years ago | (#22395984)

Retarded?

kvm (3, Interesting)

debatem1 (1087307) | more than 6 years ago | (#22387900)

Not sure how much traction KVM is going to get here unless Ubuntu can wrap it well. I'm no expert but I know my way around most virtualization technologies and KVM seems to be one of-if not the- hardest to use productively. Ubuntu has a great track record with this kind of thing though, and *if* this signals a new push in that direction I eagerly await the results.

Re:kvm (4, Interesting)

neotokyo (465238) | more than 6 years ago | (#22388636)

You've got to be kidding, right? You can install kvm without having to reboot and be installing a guest OS (given that you have the cd) in mere minutes.

https://help.ubuntu.com/community/KVM [ubuntu.com]

All of two commands after you've installed kvm:

1. create disk image
2. launch installer

Maybe a little more description of your experience with 'one of-if not the- hardest to use productively' claim might persuade folks that the above is not trivially simple.

Re:kvm (1)

kripkenstein (913150) | more than 6 years ago | (#22389550)

I believe the GP may be referring to the lack of a GUI. If not, then I am - VMWare, Parallels, VirtualBox and Xen all have various GUIs to manage them, some of which are very convenient. I am unaware of a convenient GUI for kvm (the Ubuntu wiki page to which you refer doesn't mention one), but perhaps I am just uninformed? If so, please correct me.

Also - again, not sure about this, correct me if I am wrong - but kvm requires hardware support, i.e., a fairly new CPU. Whereas some or most other virtualization offerings can work without that support. Of course, this is an issue that will become moot eventually, that's true.

Re:kvm (0)

Anonymous Coward | more than 6 years ago | (#22389990)

Qemu-Launcher is not as nice as the alternatives but it does work, there is also Qemulator but ive not tried it so cant speak.
KVM isnt required by Qemu, but without it emulation may be slow. Reading about Xen it apears that to run Windows XP, then harware based emulation is NEEDED as the only port could not be published.

I think this is a good call based on the Ubuntu desktop market, Xen is 'Stable'(by this i mean systems that do not change e.g a web server ) systems, but a desktop user will normally switch tasks regularly and having an always running hypervisor isn't needed.
I wrote that before realising this is not important as ubuntu supports both Xen and KVM

As the init i hope it speeds up boot time, IMO we should switch to the fastest thing gentoo users do that wont make the system unstable (by this i tom cruise style unstable)

For anybody looking to standardise stuff can we standardise use of the word stable!

Re:kvm (1)

alexgieg (948359) | more than 6 years ago | (#22390160)

Let me ask something related. I have a kind of slow home machine running Ubuntu (an old 1st gen AMD Sempron 2300+ @ 1.56 GHz, DDR1, SATA1, AGP, you get the picture), and I'd like to have some additional OSes available as virtual machines to just play around and maybe, eventually, who knows, do something useful in them. But all as a simple end user, someone who, in Windows, would be playing on something easy such as Virtual PC (which I in fact used before removing Windows and switching to Ubuntu).

So, from all the virtualization options available, which one do you or others reading this think would suit me the best? I've heard good things about VirtualBox and VMware Server, but this as far as I know...

Re:kvm (3, Informative)

kripkenstein (913150) | more than 6 years ago | (#22390220)

VMWare Server is probably the safest choice. It's stable, works, and is fairly convenient.

Parallels just came out with convenient installation for Ubuntu, I haven't checked it out yet. But it is supposedly very user-friendly on other platforms, so it might be worth a shot if VMWare isn't working out.

Re:kvm (1)

jschrod (172610) | more than 6 years ago | (#22392098)

Except that VMware Server Beta2 replaced the simple server console app with a horrendous memory-eating Tomcat-based monster web application. I downloaded it once and when I saw a footprint of 350 MB without even a single VM instantiated, I checked the VMware forums. There, a clear commitment to this new management interface and its resource demands could be read, in spite of the protests of many many users.

We will have to see how many have the type of hardware that one seems to need for VMware server 2. Upgrading VMware Workstation with the needed additional functionality from Server also doesn't seem to be in the works.

I'm a paying VMware customer since they released the beta for their very first 1.0 product that is now called Workstation. I'm very disappointed by the current development, and this was a sufficient reason to check out the other VM offerings. Sad to say, the other ones are still not as stable or as functional.

Re:kvm (0)

Anonymous Coward | more than 6 years ago | (#22394398)

Since Sun is now working on acquiring [sun.com] Innotek things should get interesting.

Re:kvm (1)

aminorex (141494) | more than 6 years ago | (#22395890)

VirtualBox is just as good as VMware and it's open source. I prefer it for desktops and laptops and such. VMware is better for centralized server virtualization though.

Re:kvm (1)

LWATCDR (28044) | more than 6 years ago | (#22392356)

VirtualBox seems to work really well.
On an AMD AM2 machine I have run Vista Home with no problems.
On my older AMD machine I have run Ubuntu, Kbuntu, Xbuntu, PCLinux, and Minux3 with no problems.
Under Ubuntu you just install it from add software. The GUI is pretty simple and It seems to work just fine.

Re:kvm (1)

neotokyo (465238) | more than 6 years ago | (#22391068)

KVM has the same gui that opensource Xen does, namely virt-manager. Virt-manager provide a gui for creating guests as well as managing them. KVM does require hardware support, but I don't think that's a huge deal. VT/SVM has been around since ~2005, and I'd say that in many cases, folks have access to newer processors or will so very soon. And as you mention, for those folks that haven't upgraded to a new processor since 2005, they certainly can use other solutions.

Re:kvm (1)

debatem1 (1087307) | more than 6 years ago | (#22391768)

You're right.
The last time I tried it, it repeatedly failed with error messages that were, to say the least, unhelpful- but my information seems to be out of date. Using those instructions it was, indeed, trivially easy.

Re:kvm (3, Informative)

twistedcubic (577194) | more than 6 years ago | (#22389294)

Wow. Dude, KVM is the only one I've gotten to work with no fuss. For me it was downloading kvm-57.tar.gz, ./configure; make; sudo make install; qemu-imw create ... image.img; qemu-system-x86_64 -hda ... ; qemu-system-x86_64 image.img. Installing Debian is best (vs, say, Fedora) because it's faster with a smaller amount of memory. Now go ahead and download KVM and enjoy!

Someone help me (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22387910)

Is the plural form of "dildo" "dildos" or "dildoes"?

Re:Someone help me (0, Funny)

Anonymous Coward | more than 6 years ago | (#22388000)

Dildon't

Re:Someone help me (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22388084)

dictionary link [merriam-webster.com]

Inflected Form(s): plural dildos also dildoes

Re:Someone help me (2, Funny)

Anonymous Coward | more than 6 years ago | (#22389976)

It's actually dildi.

Why do you ask? (0)

Anonymous Coward | more than 6 years ago | (#22396688)

Is the plural form of "dildo" "dildos" or "dildoes"?

How many do you have? What are you trying to do with them?

I for one (1, Funny)

Monsuco (998964) | more than 6 years ago | (#22387970)

Slashdot shares a corporate overlord with Linux.com.
And I for one would like to welcome ...

Re:I for one (2, Funny)

bendodge (998616) | more than 6 years ago | (#22388590)

Hello World, make me a sandwich.
Ha! Sudo make me a sandwich!

Re:I for one (1)

SuluSulu (1039126) | more than 6 years ago | (#22388844)

Hello World, make me a sandwich.
Ha! Sudo make me a sandwich!

Reference for the uninitiated: Sandwich [xkcd.com]

Re:I for one (2, Funny)

WilliamSChips (793741) | more than 6 years ago | (#22390318)

Hey look! I've lived under a rock the past three years and don't know what xkcd is!

Dont forget... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22387996)

...to pay your $699 licensing fee you cock smoking teabaggers

How about launchd? (0)

Anonymous Coward | more than 6 years ago | (#22388348)

I've been playing w/launchd [apple.com] on my mac.. seems pretty cool, with neat little tools [sourceforge.net] to keep things like ssh port forwarding always running...

It's open source. Is there a licensing issue that keeps this from becoming popular on various distros?

Re:How about launchd? (1)

Jeremy Visser (1205626) | more than 6 years ago | (#22389068)

It's open source. Is there a licensing issue that keeps this from becoming popular on various distros?

Apparently, there is. See the Ubuntu wiki page for ReplacementInit [ubuntu.com] . In it, they listed launchd as a possible candidate for a replacement init, but decided against it due to "inescapable licence problems".

It's licensed under the Apache license -- I can't see what is wrong with that, but I can't imagine that Canonical would spend $$$ developing their own init system if it wasn't a big hurdle to use launchd.

Re:How about launchd? (1)

Jussi K. Kojootti (646145) | more than 6 years ago | (#22389222)

The license problems refer to time when initd was not apache licensed. This is a newer comment (from the page you linked to, btw):

it still doesn't meet our requirements, so would be only a base for our own work. We've already implemented enough that it'd be a backwards step to start again based on launchd.

Licensing is part of it... (1)

mbessey (304651) | more than 6 years ago | (#22389084)

Some folks don't like the terms of Apple's APSL license, and that'd be a factor. But notice that the major Linux distributions is agreeing on any other single system, either.

I think mostly they're going off on their own because it's a fun little problem to work on, but obviously it'd be to the advantage of sysadmins everywhere to have a standard, maintainable services startup system. Maybe a clear winner will emerge, and at least keep Linux from fragmenting too much.

Re:Licensing is part of it... (1)

Lussarn (105276) | more than 6 years ago | (#22389176)

Not to forget, startup is sysvinit compatible. Making the transition easy.

It's a FSF/Cononical Conspiracy! (4, Funny)

Anonymous Coward | more than 6 years ago | (#22388370)

Beware! Richard Stallman is behind this! First they replace init with an event driven system. Next they start migrating services out of the kernel. It be proposed and seem natural to have these services driven by events (after all the init system is) . Then of course it will seem obvious to abstract the event system into its own package. This package will be called Mach. Finally a name change will be proposed that we rename Linux to GNU/Hurd. Don't say I didn't tell you! We will be butt of our own Hurd jokes.

Getting a tad annoyed at this.. (3, Interesting)

arcade (16638) | more than 6 years ago | (#22388722)

Mac uses launchd
Ubuntu uses Upstart
Solaris uses SMF
Debian uses initng
RedHat uses sysvinit (?? not sure ??)

Meaning that a sysadmin that needs to support those systems, need to write scripts that takes care to use the correct way on each and every platform. Blergh. I hate it when this kind of thing happen, instead of just sticking with the old stuff or _agreeing_ on a new way to do it. Instead, we now have a multitude of ways of doing it. Okay. Options are good. This isn't options though - this is differences being forced on you by various vendors, guaranteeing that you'll have to do more work.

Blergh.

Re:Getting a tad annoyed at this.. (4, Informative)

Daengbo (523424) | more than 6 years ago | (#22388742)

Upstart still accepts the SysV init scripts.

Re:Getting a tad annoyed at this.. (1)

g1zmo (315166) | more than 6 years ago | (#22395928)

So does SMF. Maybe others do to, but SMF is the only other one I know well besides SysV Init.

Re:Getting a tad annoyed at this.. (1)

ashridah (72567) | more than 6 years ago | (#22388846)

Debian uses initng

Uh. Debian *can* use initng. I'm pretty sure it's not being installed by default, unless they've made this decision in testing (I don't have any testing/unstable boxes atm). That seems like a fairly irregular thing for debian to agree to do.

ash

Testing (Lenny) still defaults to sysv init. (1)

oyenstikker (536040) | more than 6 years ago | (#22391168)

Testing (Lenny) still defaults to sysv init.

Re:Testing (Lenny) still defaults to sysv init. (2, Informative)

deepclutch (1233040) | more than 6 years ago | (#22403560)

and worst I cant find initng any more in debian repos.OK I got it!initng is orphaned in Debian :p read this you Debianites: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426268 [debian.org]

Re:Getting a tad annoyed at this.. (1)

deepclutch (1233040) | more than 6 years ago | (#22403520)

I am on Debian Sid.It still uses sysVinit.I have replaced it with upstart though(available in experimental repository). initng also is available.I never heard anywhere Debian favours initng :S

A step away from compatibility between distros? (3, Insightful)

beachdog (690633) | more than 6 years ago | (#22389066)

When I moved from Red Hat to Debian (remember Bruce Peren's UserLinux ?) and to Ubuntu the thing I missed was the clarity of SysV init and the simple tools to add and remove programs from a runlevel.

The article quoted shows examples of upstart scripts. I don't quite see if compatibility with SysV init is a goal of upstart.

It sure would be nice if upstart means easier application sharing between Red Hat and Ubuntu.

Re:A step away from compatibility between distros? (1)

turbidostato (878842) | more than 6 years ago | (#22389286)

"When I moved from Red Hat to Debian (remember Bruce Peren's UserLinux ?) and to Ubuntu the thing I missed was the clarity of SysV init and the simple tools to add and remove programs from a runlevel."

The problem is just your ignorance; don't put the blame on anyone else.

Debian and Ubuntu *use* SysV init scripts by default and they have *one* single tool to add and remove programs from a runlevel (update-rc.d).

Re:A step away from compatibility between distros? (1)

abirdman (557790) | more than 6 years ago | (#22390126)

I happened to be interested in this, so took the opportunity to see what man had to say about update-rc.d.

Please note that this program was designed for use in package main-
tainer scripts and, accordingly, has only the very limited functional-
ity required by such scripts. System administrators are not encouraged
to use update-rc.d to manage runlevels. They should edit the links
directly or use runlevel editors such as sysv-rc-conf and bum instead.
Thus is from Ubuntu 7.10 x86_64.

Re:A step away from compatibility between distros? (0)

Anonymous Coward | more than 6 years ago | (#22391226)

pwned

Re:A step away from compatibility between distros? (1)

turbidostato (878842) | more than 6 years ago | (#22400558)

"I happened to be interested in this, so took the opportunity to see what man had to say about update-rc.d."

So Debian *does* have SysV-style init scripts, doesn't it? And Debian *does* have simple tools to add and remove programs from a runlevel (that's exactly what update-rc.d does), doesn't it?

What was your point, again?

Re:A step away from compatibility between distros? (0)

Anonymous Coward | more than 6 years ago | (#22411952)

Lots of initd daemons use SysV init scripts (exclusivly, or as an option). Ubuntu uses "upstart" daemon by default with SysV scripts emulation layer, but real scripts (and emulation layer) for upstart are in "/etc/event.d". Packages still install services in usual places (/etc/init.d/ and /etc/rc?.d/). Using it for some time, I'd say emulation is perfect, plus there are some extra features to play with :)

Re:A step away from compatibility between distros? (0)

Anonymous Coward | more than 6 years ago | (#22393056)

WTF are you on about? Debian uses sysvinit, although it does have slightly different paths to the init scripts as compared to Red Hat (the LSB package includes symbolic links which attempt to cure this, but LSB is a bodge anyway: just compile the fucking source already, you lazy cunt). Even Slackware uses sysvinit nowadays. Anyway, it's a design goal for Ubuntu Upstart to be backward-compatilbe with sysvinit.

Re:Getting a tad annoyed at this.. (2)

Yfrwlf (998822) | more than 6 years ago | (#22390138)

Which is why everything needs to stay on a common standard communication interface while behind-the-scenes system reformation is allowed to occur, and entirely new features are tacked onto the interface as additional settings or new commands, ensuring backwards compatibility.

There is no point in using a completely different interface for two things that do the same thing though, and going back to the topic Upstart is supposed to be "compatible", though it'd be nice to use an identifier/name and flags that didn't change and were uniform so that scripts and the like wouldn't break. I believe Linux could be completely seamless between most all distros if the communities would pull harder at developing standardized interfaces (something that I'm very surprised doesn't occur much more within communities who claim to understand their importance), and the companies would stop trying to pull things in opposite directions, towards fragmentation/proprietarization.

I hope one day us Linux users will actually have the freedom to use whatever system we prefer on whatever "distro" we prefer easily, reducing "distros" to mere package and configuration "groups".

Re:Getting a tad annoyed at this.. (1)

turbidostato (878842) | more than 6 years ago | (#22400652)

"There is no point in using a completely different interface for two things that do the same thing though"

Unless, of course, I really think my way it's better (on the other hand, why would I try a different path if I didn't think it's better?).

"I believe Linux could be completely seamless between most all distros"

If they were so seemless among, what would be the segregating factor to choose one over the other?

"I hope one day us Linux users will actually have the freedom to use whatever system we prefer"

Yeah, the kind of freedom that arises from choosing among things that in reality are just the same.

"reducing "distros" to mere package and configuration "groups"."

*I* already can choose among different packages and configuration groups. You don't really think I install the same packages and configuration groups on my servers than on my desktops, do you? Freedom to choose means exactly the oposite you try to defend: choosing among *different* things, the more different, the more freedom on my choice. What's the point in choosing among things that are equal? I think you'd better prefer not to have the time and effort to analyse those different things: of course the more similar the choices the lesser risk to be wrong. But that's not freedom; it's lazyness.

Re:Getting a tad annoyed at this.. (1)

cbart387 (1192883) | more than 6 years ago | (#22405212)

I think you'd better prefer not to have the time and effort to analyse those different things: of course the more similar the choices the lesser risk to be wrong. But that's not freedom; it's lazyness.
I disagree. Myself, I would try more distros, if I didn't have to spend the time learning a new way of thinking each time. Why? Because of lazy? No, I have a single computer that I use for my work. The more time spent on system tweaking/learning is less doing the work I have an interest in.

I believe Linux could be completely seamless between most all distros
If they were so seemless among, what would be the segregating factor to choose one over the other?
The community, preformance etc etc. Remember, your parent is discussing the interface ... not the implementation. For example, yum and apt-get are pretty close in what they you can do with them. Why not try to unify the interface? What really matters is what's under the hood. Instead of people choosing a distro based on the pain of learning a new process, they can choose the distro for a better reason. Remember, we're all geeks here. The more stuff the same the more we'll fight over the smaller stuff ;)

That's my take at least ...

Re:Getting a tad annoyed at this.. (1)

turbidostato (878842) | more than 6 years ago | (#22414912)

"I disagree. Myself, I would try more distros, if I didn't have to spend the time learning a new way of thinking each time."

Two points:
1) If you think learning a new distribution is "learning a new way of thinking" then you are still to rooky (it's only a matter of learning some specific tools, not much more).
2) Again, if they worked the same, why loosing time testing the same?

"For example, yum and apt-get are pretty close in what they you can do with them. Why not try to unify the interface?"

For once, yum is newer than apt-get so why do you think yum looks and acts like, ahem, yum instead of copycat apt-get? Exactly: both because yum authors thought their way was better and because if yum felt and acted like apt-get it wouldn't be yum, it would be apt-get. On this basis it's clear that in your effort for unification is not yum the one that should go towards apt-get. But then, yum has been around for sometime, so we can expect that if apt-get developers show something interesting in yum they'd already go for it (after all, it's open source). But then, why do you think this didn't happen? Exactly: again two reasons. One, because apt-get developers already thought about it and they still thougth their way was better (so no point trying to convince them to converge towards yum) or because they thought it wasn't worth the effort, in which case you'd better put your own hands on the problem than whine because, again, you'll get nothing just whining.

"What really matters is what's under the hood."

That's open source: define, please, "under the hood". Is it program names and options? Certainly yes. Is it APIs? Probably not for you but certainly a developer would say just like you "why do I have to learn so many different APIs? can't they try to unify them?". And then we are again at square 1. Or they could just define and implement the same, but this would be quite idiotic since they could just *use* and *modify* the old codebase, probably within the very same project, wouldn't they?

"The community, preformance etc etc."

On one hand, you *already* can have different communities with the same distro (think LUGs, only over the Internet: if you don't like "fedorafans", just go to "friendsoffedora"). On the other, do you think performance comes out of thin air? implementation decisions obviously affect it, so it's very probably it will affect APIs too (see my previous paragraph) and finally they probably would affect outer interfaces. After all, if you like apt-get but i.e. you feel it slow, you don't start a new program, you go and summ up the hackers group of apt-get itself.

In the very end while I understand you, I can see your opinion is *very* naive and failing the "reality check". I already said that I enjoy current variety and feel it useful but even if not, it's obvious things in real world can't go otherwise. You can expect minor victories from your point of view, but the overall landscape is doomed to be one of diversity.

In order for your naivety to vanish, just change your mindpath from current "I don't like the way things are, so I whine" to this: "I don't like the way things are, so I'll change them myself" and see what happens.

Hint: to follow your own example, just try indeed to go for a universal package manager; what would you do?
1) Go to yum people and convince them to abandon it in favour of apt-get. Do you really think you will success? See my previous paragraphs.
2) Go to apt-get people and convince them to abandon it in favour of yum. Do you really think you will success? See my previous paragraphs.
3) Start your new and revolutionary universal package manager, so wonderful everybody will jump to it. Do you really think you will success? Well, probably yum people thought it too when they started but please, think a little about the possibility of ending up with *three* package managers instead of neither one nor two.
4) Have a look at yum and apt-get and then jump into either hackers community and make it happen: deliver code that will push your elected one towards the other. Maybe you'll success, maybe you'll learn enough to abandon your mesianic unification intents.

All in all, I'd bet point 4 is the only one with any chances to succeed. Still I'd say lotto chances are better.

Re:Getting a tad annoyed at this.. (1)

cbart387 (1192883) | more than 6 years ago | (#22414976)

I disagree, so I guess we can agree to disagree ;)

Re:Getting a tad annoyed at this.. (1)

Yfrwlf (998822) | more than 6 years ago | (#22434332)

"...because apt-get developers already thought about it and they still thougth their way was better..."

You're talking about differences between programs. You're on the wrong page. I'm not saying there shouldn't be differences between programs. I'm saying programs should try to use the same interfaces where possible and not just user interfaces if and where desired/able, but inter-program interfaces too, because you should use standardized things where and when possible to make your programs modular. To use your example of apt-get and yum, the interface, i.e. "yum install ", could be the same, or even better if you just make universal system commands like "install" then you could simply make it "install ". Then, for the flags, you could have them use the same names or have aliases for some or whatever you wanted, because that front end is just a simple indexing searcher. Any way, it's entirely possible to do something like that and have it become something universal and part of every system. Then, on the back end, you can use whatever the hell you want to use and the back ends can directly compete. Their quality wouldn't be determined by how difficult the front end was to use. I could use apt-get commands for yum repositories, for example, which I'd love to do because I hate yum's search ability/method. Even if you don't want the same front-end commands, you can standardize it so that it uses the same inter-system communication methods. The one place I know yum doesn't is of course because it is only compatible with RPMs, and not DEBs, and apt-get only is compatible with DEBs and not RPMs. This drastically needs to be changed. You should be able to install DEBs and RPMs on LSB-compliant systems if those packages are LSB-compliant (yes, I know DEB isn't defined in the LSB but it should be because it's just a format).

So, standardize the front ends or whatever interfaces could use with some standardization, or the "languages" or protocols or whatever, and make all the stuff in between completely modular. It's also called a "framework". That's how your internet browser is. That's how any "client" and "server" is (to a greater or lesser degree in some instances though, especially where DRM is used). The FTP protocol gets standardized? Great, now you have lots and lots of different FTP servers and clients that are able to compete with each other because they all communicate using the same protocol. The data is different that gets transmitted, the servers and the clients are all different, but they all use the same powerful protocol.

Standards are good as long as they are scalable and don't lock you in. You may not like them to occur in some areas with some things, but in many areas they are very important, and like I've stated in posts in this thread there are lots of good reasons for making your program as modular and cross-platform and cross-everything as possible.

Re:Getting a tad annoyed at this.. (1)

turbidostato (878842) | more than 6 years ago | (#22470428)

"Then, for the flags, you could have them use the same names "

Then again, the stupidness of looking it from the end user point of view... The end user won't EVER use but the flags someone programmed; it's plain obvious. Now, go and tell the programmer it should use GNU-like long options when he (for whatever reason) dislike them.

I really don't know the syntax for yum, but let's say for the shake of the argument it goes like yum -install package where apt-get goes apt-get install package. Are *you*, as an end user, magically make yum accept "install" or apt-get "-install"? Sure not. It takes a programmer to do the trick. Now, both yum and apt-get have their own programming comunities. From time to time you may convince some group that the other's way is better, but in the general case scenario, they will have very valid reasons (at least for them) to go the path they follow and they are the ones that make it happen, so if they like "potaitos", "potaitos" you will have no matter how much you tell them "potatos" is much better.

And even if you managed to convice them, nothig stops a third party to start anew with "tomaitos" just because "tomaitos" is the way he feels the best. And his is programming efforts are of some value, you started with "potaitos" and "potatos" and will end up with "potaitos" and "tomaitos" after so much struggling.

"it's entirely possible to do something like that and have it become something universal"

Yeah, sure, enterli possible... the day you can imprission people that deffies your standard, or something like this.

"The FTP protocol gets standardized?"

That's plain stupid. Of course "The FTP protocol" is a standard, or else you wouldn't be able to talk about "The FTP protocol" -just the same you can talk about "The Qt4 API" but then, what purpouse serves "The FTP protocol"? Yeah, moving files from here to there... Surprise! just like TFTP, HTTP, WebDAV, CIFS, NFS, scp, plain old rcp and probably another dozen protocols I can't recall right now. From your very point of view is not the protocol, but the service (why should nobody have to learn a dozen different ways to move files from here to there?) so see, even "Standards" is not good enough.

"and make all the stuff in between completely modular"

I promise I'll send you the first grandma' usable version of the Hurd packaged with a copy of Duke Nukum Forever; just hold your breath.

Re:Getting a tad annoyed at this.. (1)

Yfrwlf (998822) | more than 6 years ago | (#22434418)

Oh and one more thing, things are changing, modular programming is becoming more and more popular thankfully. Just so you know. But, things still need more work, and certain companies may not be so eager to see it happen as some companies are competitors. Programs and companies should compete, but everyone's freedom should not suffer because of it, it should not make things more proprietary. Open source is all about working together (at least, often it is) to create great things, but that spirit doesn't have to always exist with open source software, so everyone should know what things limit their freedom.

Re:Getting a tad annoyed at this.. (1)

turbidostato (878842) | more than 6 years ago | (#22470266)

"things are changing, modular programming is becoming more and more popular thankfully"

Modular programming? Maybe. Modular "toolizing"? It's decades old. What do you think `ls -l | less` or `echo time > out.txt` means? But then, there comes some guru deciding that piping, IPC, POSIX system calls... are too cumbersome and there's the need for some "high level abstraction" or "service oriented" monolithic approach and, guess what? As long as he puts his effort where his mounth is you end with some people thinking the KDE-way is the best while others abash it in favour of Gnome, some people CORBA and then some RMI.

On square 1 again.

"Programs and companies should compete, but everyone's freedom should not suffer because of it"

That's all well and good... as long as you see that company's (or even individual hackers') freedom to look for their way shouldn't suffer either (and it won't, since you can't forbid it), and since *they* (the producers) not *you* (the end user) are the ones that "make it happen" is no wonder it's *their* freedom the one that you see pushed forward in the wild instead of yours.

"Open source is all about working together"

Yes. It's quite all about WORK and then some mumblemumble. Do you WORK? See point four on my previous poster. You don't? See points one to three and don't wonder the outcoming.

Re:Getting a tad annoyed at this.. (1)

Yfrwlf (998822) | more than 6 years ago | (#22432836)

Exactly right on all accounts. (see my reply to parent also if interested) Everyone should be concerned about bringing "systems" together, because as you do that you bring users and developers together, and make learning and life easier for everyone. I'm happy that there is a growing interest in keeping things modular so that we all have more freedom. It's one of many things that will help to make Linux more powerful, too, but it's simply intelligent programming. If I go to write a program to do something, say, make some sort of widget for the Linux desktop, one of the first things I would look into is how is what I'm doing "normally" done, and what kind of system exists that I need to interface with. I'd look at the current standard that is being used for these desktop widgets, and if I felt the standard was horrible and needed more "language" added to it to allow more powerful commands or whatnot, I would make those proposals and try to work that out until I clarified the standard so that I could do what I needed to do and move on from there. If the standard was built correctly, it would allow scalability for awesome improvements to be added onto it, or it would be such a perfect one that programs would be able to do anything they wanted to basically in a simple, quick, effective way. Doing all this ensures

1. Your program gets more use.
2. Your program can be swapped out for other programs.
3. Your program will always play nicely with the way users have their desktops set up, for example it will use the buttons and colors that the user wants their interface to use instead of forcing upon the user the choices of the programmer which is simply more respectful unless the programmer believes that there is a big need to define their own.
4. Your program can be shared easily and used on any system, which in turn makes it more widely used.
5. Because of it's wide use, more developers and community support will be available to continue and help you improve your program, in turn giving more power and freedom to everyone.
6. Everyone will have more freedom as an effect of your smart programming.
and probably a lot more...

Re:Getting a tad annoyed at this.. (1)

cbart387 (1192883) | more than 6 years ago | (#22442400)

Good stuff. I don't get the obsession people have with wanting to keep everything complicated. It's like they equate making things easier as being 'noobish'*. Just because I can handle complicated things that doesn't mean I wish to. I'm glad to see your response, I didn't have the energy to do a counter-argument.

* I use the term noob on purpose because it's ridiculous. Everyone starts out as a beginner. I find it quite arrogant and obnoxious.

Re:Getting a tad annoyed at this.. (1)

Yfrwlf (998822) | more than 6 years ago | (#22452452)

Yes it's very true, I like using noob because I think it's silly and playful, but yeah, while it may be fun for you writing a script to launch a program in a certain way at a certain time, and while it's what I do for a living, it's NOT what I want to always do for fun lol, sorry! You can enjoy a car without knowing everything about the inside of it. Besides we HAVE to make things easy if we want any kind of Linux adoption, and I do, or more specifically I want the adoption of a truly free system, because restrictive things are annoying and no one likes them, hehe. What I really want to see is a Linux gaming console, and more ways of getting paid development for Linux games and programs, but now I'm just rambling so I'll end this now. ^^

Re:Getting a tad annoyed at this.. (1)

Yfrwlf (998822) | more than 6 years ago | (#22432760)

I think you misunderstood the way I truly meant my post. I'm not saying to make everything the same. Far, far from it. I'm saying that the common *interfaces* could be made the same, so that things are *modular* and can be more easily swapped out for *other* things, giving users more freedom. If I have to install OS Y (avoiding OS X jokes) in order to get program Y to run, and can only use OS Z to get program Z to run, that's not freedom, that's lock-in. I'm being locked in to this one particular OS to use this program. To reduce things like that, you can put an ABI/API in place so that both programs will run on either OS, even though the programs and the operating systems are different. This concept of having some kind of common method of communication is really what I meant by my post. How far to take it though is an interesting conversation.

I think it would be a pretty cool idea to make it so, for example, all mail programs whether Exim, sendmail, etc used the same points of communication so that users would not have to learn each system. You make one command called "mail" and it can issue standardized commands. Next, the developers of mail programs make it so that their program can understand and interface with the standard. If the standard lacks in any way, improve and/or add onto it. Sure you can make other programs that interface with JUST Exim, but isn't it nice when a program or plugin can be used for more than only one other program or on more than only one platform, etc? :) It's just smart programming is all. Setting things up for interoperability and modularity is becoming the trend, and I'm very happy to see things heading in that direction. More freedom for us all. Not to mention more free time, since we don't have to understand how to use 100,000 different programs/systems because each is so completely different.

P.S.: Did I mention I really don't want to see Linux fragment like Unix did? If you want a good example of lock-in, look at the history of Unix. Sure, if everything is open source that helps tons, but lots of fragmentation of different sorts can still occur, and users and developers should be aware of such things as it effects everything about a program, how widely it gets adopted, how it gets used, etc.

Re:Getting a tad annoyed at this.. (1)

Mantaar (1139339) | more than 6 years ago | (#22390538)

There is no way Apple will agree on agreeing with anyone else - especially if it's some pesky open-source distributors or Sun, who are not in the desktop, but the server market (mostly). They are a) going to buy the stuff (cups, khtml) b) or completely ignore everyone else and roll their own, like they always did.

I don't say this is a bad thing - I'm rather trying to point out that the OP is wishful thinking. And to add to the list: Gentoo has several alternatives. Heck, there are two versions of their baselayout and you can use einit and initng (and maybe a third... I can't remember right now).

Let's face it: SystemVInit lies dead and rotten with a few people still clinging on to it, but more because of momentum than anything else. For one thing, it's awfully slow. When I moved my laptop from a tuned Gentoo (einit) to Debian I was really happy to know suspend is finally in the kernel - it would take forever to boot. Literally. About a minute! For a laptop, no services whatsoever (OK, save apache, nfsd and ntpd)

What's coming now are the Standards Wars. They've always been there (well, as long as there is more than one manufacturer) and they'll eventually settle. Nobody is going to use launchd except Apple, nobody is going to use SMF except Sun. *BSDs will hide behind sysV for a while - and Ubuntu is one of the early-adopters distro, always including the New Stuff - sometimes with catastrophic results (7.10 was a PITA), so they are the natural candidate for providing us with a new system - or at least a proposal therefor. And Gentoo... well, einit doesn't sound that bad. They've surely replaced the default framebuffer! uvesafb is a billion times better than vesafb-tng - and even that came from Spock (not the Vulcanian, a Gentoo dev). Let them fight, I'll stand aside and look, trying one or the other and fixing bugs for the one I like the most.

In a year's time we'll probably have a winner... or, let them be two years.

Re:Getting a tad annoyed at this.. (1)

Lord Kano (13027) | more than 6 years ago | (#22391556)

When I moved my laptop from a tuned Gentoo (einit) to Debian I was really happy to know suspend is finally in the kernel - it would take forever to boot.

When I went to 2.6.23, it was before Mandriva had an officially blessed update available, hell they still might not, but I had to patch in tuxonice and modify my init scripts to work with it and write a daemon to automate the hibernation process. It was kind of annoying, but not a very big deal. There is a reason why we're not running Windows on everything. We don't mind having to fix things every once in a while, because with linux, GNU and other open source we have the ability to fix things.

Vulcanian


Do you mean Vulcan?

In a year's time we'll probably have a winner... or, let them be two years.

This is wishful thinking. Here we are a decade on and we still have debs, rpms and tarballs. None of this will be settled. Everyone had their own reasons for doing things the way they did, why do you think that they'll change just because someone else did?

LK

Re:Getting a tad annoyed at this.. (1)

99BottlesOfBeerInMyF (813746) | more than 6 years ago | (#22395756)

There is no way Apple will agree on agreeing with anyone else - especially if it's some pesky open-source distributors or Sun, who are not in the desktop, but the server market (mostly).

Actually, Apple frequently adopts technologies and standards from both Sun and Linux distros. The thing is, Apple also is not willing to compromise on all things and will sometimes roll their own when they think they can do it better and cleaner (sometimes just better for them). They are less interested in being just like everyone else than they are in doing what is right for their developers and users. I think LaunchD is one example of this and Webkit is another. In the first case they created a new solution that was more elegant than the existing ones and offered it as open source... which none of the Linux distros even seriously considered. In the other case they adopted a technology created by the KDE people and made it much better, and eventually their version merged with and became the standard which is in use by many other projects today.

They are a) going to buy the stuff (cups, khtml) b) or completely ignore everyone else and roll their own, like they always did.

Umm, Apple bought KHTML? I thought Apple adopted it and made a lot of contributions to it. As far as I know they simply used the existing license without contributing any cash, just code. As for CUPS, Apple adopted it first, then several years later hired the main developer, then bought the codebase so they could ship a compatible printing system in closed source hardware devices (while keeping all their changes available via GPL).

Now I'm not trying to defend Apple here. I like and use many of their products, but I also use Linux, OpenBSD, and Windows... I'm just trying to clarify things. One thing, however, that I have noted is that Linux distros tend to ignore features in OS X that they are lacking, even when the code is there for the taking. I attribute this to a few factors. One is that people that care about having a featureful desktop OS tend to switch to OS X as their primary system, so they don't have a lot of incentive to work on those same features for a desktop Linux distro. Second, Linux desktop developers I know, rarely have used OS X and tend to not even know about the features/technologies they are missing, or if they do know, don't care because they are focused on power users. Finally, a huge feature of any Linux distro is compatibility with other Linux distros. Any feature that makes a real, architectural change to Linux has to overcome enormous resistance as it breaks compatibility with other distros and because Linux on the server developers don't want any more "bloat" or any changes that will cause potential instability without benefitting Linux as a server OS.

What's coming now are the Standards Wars... Let them fight, I'll stand aside and look, trying one or the other and fixing bugs for the one I like the most. In a year's time we'll probably have a winner... or, let them be two years.

I guess this comes down to capitalism versus socialism. Will multiple competing offerings result in all of them improving and one or two real, well done solutions arising, or will the duplication of effort and failure to cooperate retard innovation and annoy us for years to come (while Microsoft snickers)? Personally, I think we'd be better off with standardized technologies that are cleanly implemented, powerful, and universally adopted via a standards committee, than by head-to-head competing standards which may result in a "winner" that is not the best technological solution, but is paired with other technologies that are winning for other reasons. Oh well, I guess I'm a silly utopian idealist or something.

Re:Getting a tad annoyed at this.. (1)

turbidostato (878842) | more than 6 years ago | (#22400748)

"In a year's time we'll probably have a winner... or, let them be two years."

Yes, of course. SysV vs BSD has been there, how much? 25 years? But, of course, it'll settle now in a year of two. Yes, of course: Red Hat will throu away their years of development and fine tunning of their init scripts because it will settle. Debian... well, even if they decided it (and they won't) you probably won't see Lenny's succesor in such a timeframe.

You forget that:
1) There are not such a terrible differences between SysV and BSD (nor anyone of their more modern successors) so that one could mean a terrible advantage over the other.
2) The init system layout is not so terrible important anyway, but it's quite complex and positioned on a place that it is critical to the system so there's not so strong pushing to change it: if ain't broken, don't change it.
3) Not being such an important subsystem by itself, being quite delicate to change (lot of corner cases), and not showing anyone terrible advantages over the others, inertia mandates: you can bet that, for the most part, current Unix and unix-like systems that use SysV init systems will retain its use, while BSD-related will do the same too on the foreseeable future.

Re:Getting a tad annoyed at this.. (1)

CmdrTHAC0 (229186) | more than 6 years ago | (#22391058)

Don't forget Gentoo has its own weird (but improved, IMHO) system. If only their package management was as nice as their init stuff.

For my own software, I prefer to write an init-script for Ye Olde sysvinit and the actual distro I'm currently running, and leave others out in the cold.

Re:Getting a tad annoyed at this.. (1)

softdevs (1203042) | more than 6 years ago | (#22400180)

And for windows??? kanati [kanati.com.ph]

KVM less of a surprise than you might think... (5, Interesting)

adamkennedy (121032) | more than 6 years ago | (#22388780)

At last year's Linux.Conf.Au I attended both the virtualization mini-conf and kernel hacker virtualization talks with interest, since I dabble a bit in virtualization but not enough to keep up to date on current trends.

I was struck with the immense gulf in opinion between the "virtualization folks" and the "kernel folks".

Most (possibly all) of the talks in the virtualization stream could be summarized as "Xen! Xen! Xen! Yay! Yay! Yay! Xen, xen, xen, xen xen, xen, xen. Xen! Xen Roxx0rs! Xen! Clients! Xen! Xen! XEN!!!". Lots of action, lots of progress, lots of excitement, lots of Real People in Real Companies doing Real Work and discovering Best Practices.

It was quite a shock to walk into the "kernel hacker QA" with kernel maintainers from several big linux distros and some major names and here a simple "Xen sucks. Use KVM". Talking to one unnamed kernel hacker who actually wrote a big chunk of Xen code, even he basically flat out said Xen was a terribly solution which he only saw as a stop gap until KVN had picked up some speed.

So the impression I walked away with was that while Xen is the current poster child for virtualization, its days are numbered.

Once KVM has had time time to move away from being shiny new code that only a kernel dev could love to a Real Product Xen is going to have its ass kicked by the new Blessed Child.

Fortunately I don't have anything invested in either side (I mostly use qemu because my needs are more for pure isolation and speed isn't needed at all) but it looks like this match is shaping up as a hell of a flame war.

And by the sounds of it, Ubuntu just threw lit up the first flamethrower on behalf of KVM.

Now where did I put those marshmallows.

Re:KVM less of a surprise than you might think... (1)

AceJohnny (253840) | more than 6 years ago | (#22389038)

So, what, your point is that, since KVM is better than Xen in the opinion of experienced techies, it will kick Xen's ass on the market?

When did technical superiority ever matter on the market?

Re:KVM less of a surprise than you might think... (1)

adamkennedy (121032) | more than 6 years ago | (#22389460)

If we end up with two competing open source virtualization strategies with commercial support, but one has the blessing of (and encouragements for) the kernel devs and the other doesn't, then over the medium term, then quite possibly yes.

Or at least that's the impression I got from the kernel dev I had a few drinks with.

But hey, he could be wrong.

My point is that by the looks of things, we've got a pretty major competitive war coming, and Ubuntu going to KVM isn't as unusual a choice as it might seem.

Re:KVM less of a surprise than you might think... (3, Insightful)

gbjbaanb (229885) | more than 6 years ago | (#22389688)

Well, if it gets some decent userspace tools to manage the host and guests, then yes KVM could well become a decent 'standard' though it will not oust Xen as Xen already has enough support in the marketplace to ensure its survival (unless, of course, Xen proves to be a poor performer or unstable)(I've heard reports of both).

The things to make people really think KVM is the best is a web-style gui to manage start/stop, guest settings etc, and stats on what all the guests are doing in semi/realtime.

Re:KVM less of a surprise than you might think... (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22389520)

KVM is better than Xen in the opinion of the kernel maintainers. Therefore, KVM will be (already is) available in the stock Linux kernel, and all distros that use any recent-ish kernel. KVM will be available pretty much everywhere by default, and requires very little in the way of distro support - a couple of simple userland apps will handle everything, and they don't even need root access to work.

Once KVM has the remaining kinks worked out of it, it'll be everywhere (on Linux at least) by default, and will be trivial to use.

Re:KVM less of a surprise than you might think... (1)

ThePhilips (752041) | more than 6 years ago | (#22393386)

IIRC, in the time of discussions, it was said that Xen can always use KVM.

KVM is essentially official kernel interface to virtualization hardware. But Xen has to work even without hardware support so they do lots of things on their own.

As soon as number of servers with hardware supported virtualization reaches critical mass, Xen would start using KVM where available since it is part of kernel, since it is official interface.

IOW, in long term Xen and KVM are complementing, not competing technologies.

Re:KVM less of a surprise than you might think... (1)

Chris Pimlott (16212) | more than 6 years ago | (#22390232)

When did technical superiority ever matter on the market?
Since when did market share dictate Linux design decisions?

Linux (and open source in general) is much less swayed by commercial popularity than proprietary vendors are.

Re:KVM less of a surprise than you might think... (2, Informative)

Anonymous Coward | more than 6 years ago | (#22389570)

"the first" flamethrower? Huh? Fedora has been supporting KVM for a while! Yes, Fedora _also_ supports Xen, but that might change, given that Xen is always a few kernel versions late and Fedora ships very recent kernels (so there's now a special old kernel-xen used for the Xen Dom0 and DomU kernels, basically the situation sucks).

Re:KVM less of a surprise than you might think... (2, Informative)

digipres (877201) | more than 6 years ago | (#22389758)

And if the virtualisation waters weren't already muddy enough, we have kernel hacker Paul http://www.rustyfacts.com/ [rustyfacts.com] Rusty http://en.wikipedia.org/wiki/Rusty_Russell [wikipedia.org] Russell coming up with lguest http://lguest.ozlabs.org/lguest [ozlabs.org] .

So we have a kernel guy and his own take on Linux and virtual machines. This may prove hugely popular, though I hear that not too many turned up for Rusty's lguest tutorial at LCA08. Then again that may be because he scared us off with a "if you haven't done the homework, don't turn up!"

Re:KVM less of a surprise than you might think... (0)

Anonymous Coward | more than 6 years ago | (#22391548)

Fortunately I don't have anything invested in either side (I mostly use qemu because my needs are more for pure isolation and speed isn't needed at all) but it looks like this match is shaping up as a hell of a flame war.
Then perhaps you'll be disappointed to note that the kvm frontend is a qemu version.

Re:KVM less of a surprise than you might think... (1)

turbidostato (878842) | more than 6 years ago | (#22400778)

"Fortunately I don't have anything invested in either side (I mostly use qemu"

Then you are doubly fortunate since KVM userspace tools and even the "native" disk image format are those from qemu.

Virtualisation extensions (1)

Bloater (12932) | more than 6 years ago | (#22389682)

Doesn't KVM require virtualisation extensions to run? Will Ubuntu be integrating qemu's CPU virtualisation into the UI they write so it can be used for more than a tiny fraction of the Ubuntu using population?

Re:Virtualisation extensions (3, Informative)

CmdrTHAC0 (229186) | more than 6 years ago | (#22391110)

It requires them to run with performance, yes. It falls back to pure emulation when they aren't available, because it *is* still qemu as well.

Meanwhile, my crystal ball shows me that VT-capable hardware is not going away, so the "tiny fraction" will become the majority. It seems important to consider them when thinking of future directions.

Re:Virtualisation extensions (1)

Bloater (12932) | more than 6 years ago | (#22398890)

If Ubuntu's standard development suite is benchmarked virtualising at 1/5 to 1/10 the speed of Microsoft's Development suite, Ubuntu loses.

I mean, 1/5 to 1/10 the speed, Dude. And this existing hardware isn't going away any time soon and it can't just go to landfill for people to replace it. They'll just run Windows and Virtual Server - it's so easy and fast.

KVM_AMD and SKAS_UML (1)

sgt scrub (869860) | more than 6 years ago | (#22393274)

If UML gets SKAS support on AMD working there wouldn't be any argument about what is the best VM on Linux. It works great on Intel hardware.

Useless for older hardware? (1)

nurb432 (527695) | more than 6 years ago | (#22398990)

Doesn't KVM require support for VM in hardware? ( ie, newer hardware ).

Leaves out a lot of people that don't have brand new fancy stuff. ( or have things changed )
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?