Ubuntu's Live USB Disk Creator

[deanjo]

UNetbootin offers a straight binary as well as Ubuntu and openSuse packages, so it's cross distro without requiring users to compile. Does the YaST one do that? Huh huh huh?

Oh, and did I mention UNetbootin can do any distro? Can the Ubuntu or Suse ones do any distro you want?

Oh snap. UNetbootin = 2. Others = ?

If you want to write the profile for it, absolutely it can.

[Yfrwlf]

If you want to write the profile for it, absolutely it can.

Mhm well right now UNetbootin has several distros it already supports, and since the program you're referring to is a Yast module, you'd have to have Yast to run it, and is there an easy way to download and run Yast? Regardless, UNetbootin is a standalone program, so that may be easier for anyone to use.

But hey, the more competition the better.

[deanjo]

Mhm well right now UNetbootin has several distros it already supports, and since the program you're referring to is a Yast module, you'd have to have Yast to run it, and is there an easy way to download and run Yast? Regardless, UNetbootin is a standalone program, so that may be easier for anyone to use.

But hey, the more competition the better.

You don't need the yast module, it's just a gui for kiwi which is can be brought over and used without the yast gui. YaST as well is being ported to other distro's as well, latest effort being RHEL (some others as well I believe if IIRC when going through the opensuse build service). UNetbootin is nice, but does not have the same level of customizeation that Yast/Kiwi allow (users, package selection, preconfigs, other types of images such as VM's etc).

[Yfrwlf]

You don't need the yast module, it's just a gui for kiwi which is can be brought over and used without the yast gui. YaST as well is being ported to other distro's as well, latest effort being RHEL (some others as well I believe if IIRC when going through the opensuse build service). UNetbootin is nice, but does not have the same level of customizeation that Yast/Kiwi allow (users, package selection, preconfigs, other types of images such as VM's etc).

Being *ported*? Wow, I didn't know some Linux programs were so ingrained into specific distros that they had to be ported. The proprietization of Linux is a very sad thing indeed, and I hope everyone will be very wary of helping out with any programs unless they have freedom, accessibility, and modularity as their core principals so their work won't go to waste.

So *Kiwi* at least is a standalone program that can be used on all Linuxes right now, that's good. You have the link to a binary we can all download and run by any chance, or even the source code? Because, right now I can't find anything on Google or Sourceforge or anything about this program. If I can't even download it then as far as actually using the thing, I'd have to give UNetbootin *my* editor's choice, but hopefully you can help me find the link, that would be really nice of you. ^^

[deanjo]

http://kiwi.berlios.de/

http://svn.berlios.de/wsvn/kiwi/kiwi-head/doc/kiwi.pdf?op=file&rev=0&sc=0

YaST does have a bit of porting to be done fore use on other distro's as they do not all use the same packagemangers, etc.

[Yfrwlf]

http://kiwi.berlios.de/

http://svn.berlios.de/wsvn/kiwi/kiwi-head/doc/kiwi.pdf?op=file&rev=0&sc=0

YaST does have a bit of porting to be done fore use on other distro's as they do not all use the same packagemangers, etc.

Not to get too off subject but I hope Package Kit can help standardize package manager GUI front ends somehow, though I don't know how they're planning on doing that exactly, but any standardization efforts for more package manager modularity is good.

Any way, thanks for the links. I wouldn't call that website user friendly yet though of course, there's only an RPM (just for Suse?) so that pretty much means a total lack of adoption by mainstream Linux users outside of openSuse until a cross-distro binary is provided (as well as a download link for the latest source or something would be nice too for those wanting that, though if you want to compile sources you're probably OK with the link to the SVN any way). That's the problem I've been referring to the whole time, making it difficult to install Linux software on Linux systems means slower Linux adoption and less software for everyone. UNetbootin provides ways to easily download and run it regardless of distro, but obviously Kiwi is still young. I wish it luck. ^^

[deanjo]

Not to get too off subject but I hope Package Kit can help standardize package manager GUI front ends somehow, though I don't know how they're planning on doing that exactly, but any standardization efforts for more package manager modularity is good.

Any way, thanks for the links. I wouldn't call that website user friendly yet though of course, there's only an RPM (just for Suse?) so that pretty much means a total lack of adoption by mainstream Linux users outside of openSuse until a cross-distro binary is provided (as well as a download link for the latest source or something would be nice too for those wanting that, though if you want to compile sources you're probably OK with the link to the SVN any way). That's the problem I've been referring to the whole time, making it difficult to install Linux software on Linux systems means slower Linux adoption and less software for everyone. UNetbootin provides ways to easily download and run it regardless of distro, but obviously Kiwi is still young. I wish it luck. ^^

Cross distro packages could easily be made using the openSUSE build service that is capable of creating packages for pretty much all the mainstream distros,Debian, ubuntu, RHEL and kin, Mandriva and openSUSE of course. All it would take is someone being motivated enough to set it up.

[Yfrwlf]

Cross distro packages could easily be made using the openSUSE build service that is capable of creating packages for pretty much all the mainstream distros,Debian, ubuntu, RHEL and kin, Mandriva and openSUSE of course. All it would take is someone being motivated enough to set it up.

Getting off topic but...

That might be one temporarily solution, but I don't consider it a permanent one since I believe this solution of basically setting up compilation farms for distros is beating around the bush, and it's going to be a biased solution any way because it'll leave the lil dists in the dark. What needs to happen is an actual solution to the problem, some intelligent communication occurring to develop some kind of packaging standard that all package managers can use, be it some XML standard perhaps even backed by the ISO and other standards bodies (though of course because of the whole MSOOXML thing, ISO isn't in a great state of trust right now), or using the existing package standards and implementing them in all the most common/popular package managers so that users are free to use any package format they want, OR if it can't be done because of a lack of metadata in any of the existing formats preventing them from being used properly they should be updated so they can be free of any specific manager and can play nicely with all other packages.

Yes, I know that was the biggest run-on sentence ever.

Basically, different package managers are different, so all you need is a package format that is dumb but has all the information needed for it to be installed successfully no matter what, perhaps even something that can deal with namespace collisions so you wouldn't even need a Linux program name registry. I don't know if this idea is being worked on at all but what the LSB is working on I think comes closest since it's more of a low-level solution, but other kinds of solutions are being worked on like Klik, Zero Install, and here's the links for LSB's packaging thang.

[deanjo]

Getting off topic but...

That might be one temporarily solution, but I don't consider it a permanent one since I believe this solution of basically setting up compilation farms for distros is beating around the bush, and it's going to be a biased solution any way because it'll leave the lil dists in the dark. What needs to happen is an actual solution to the problem, some intelligent communication occurring to develop some kind of packaging standard that all package managers can use, be it some XML standard perhaps even backed by the ISO and other standards bodies (though of course because of the whole MSOOXML thing, ISO isn't in a great state of trust right now), or using the existing package standards and implementing them in all the most common/popular package managers so that users are free to use any package format they want, OR if it can't be done because of a lack of metadata in any of the existing formats preventing them from being used properly they should be updated so they can be free of any specific manager and can play nicely with all other packages.

Yes, I know that was the biggest run-on sentence ever.

Basically, different package managers are different, so all you need is a package format that is dumb but has all the information needed for it to be installed successfully no matter what, perhaps even something that can deal with namespace collisions so you wouldn't even need a Linux program name registry. I don't know if this idea is being worked on at all but what the LSB is working on I think comes closest since it's more of a low-level solution, but other kinds of solutions are being worked on like Klik, Zero Install, and here's the links for LSB's packaging thang.

Ya but the LSB get's the Debian crew's panties all in a knot. I agree that some standardization of a base system should exist but then you get people bitching and moaning how it goes against FOSS philosphy.

[Yfrwlf]

Ya but the LSB get's the Debian crew's panties all in a knot. I agree that some standardization of a base system should exist but then you get people bitching and moaning how it goes against FOSS philosphy.

Right and both sides may be to blame, but "standardization" does not = less choice. If done correctly it means much much more choice. Standardization via forcing someone to use software X, I don't even know if that's really standardization by definition, but regardless that's not what "standardization" is supposed to be. You don't see torches and pitchforks against HTML, that's a standard, and a huge one. Or ODF, that's a massive standard as well. Just because the standard for ODF exists doesn't mean I can't choose other document formats when I save my files, but choosing something that is open and popular is a good idea. That way, I can use many other programs to read and write in whatever "document standard" I choose. Sure, if you were head IT guy in some company, forcing everyone to use a specific piece of software is one option and it may help with certain things a little bit, but you can just not *support* all other similar programs instead, but this is getting off topic.

Standardization means you have a common language, system, API, or whatnot that any software can use. It means modularity. It means the opposite of a proprietary software stack, even if some of that stack was closed source, you can still have standards and interoperability with an infinite range of other software.

Any way, to address your comment, I don't know if I agree with the LSB saying "You better have software X, Y, and Z, or else!". While having some standard specific programs may be mildly helpful, ultimately you want standard systems and what programs are installed by default should be left up to popular vote and that isn't a problem at all as long as all Linux software is easily obtainable, installable, and usable. There's no reason why you shouldn't be able to install any and all software alongside one another, even if it does the exact same thing, as long as you have a system for dependencies that can install different versions of the same libraries side-by-side, etc. Just like RAR, BZIP, 7Z, KGB, and other even newer compression formats, the fact they are standards doesn't mean you have to try to force anyone to use any of them, I use them only if I want to, it simply means that the popular ones can be adopted and integrated into programs like File Roller or 7-Zip or whatever archiving program you use. NTFS or PAL? I can choose and use either one. ODF, FTP, PHP, OpenGL, they're all standards that any program can use without consent and thus their adoption will continue until truly better standards come along. That's the way things work with most standards and that's how Linux should work, it should be driven by popular demand and not by some God Company telling you what you have to install.

The key is clear communication as well as feature set and performance and such, but standards demand open communication and clear/easy documentation and implementation in order to get them adopted. It's perfectly possible to come up with at least one packaging format (unless one exists already that can do the job) that all the common package managers can adopt so we can get cross-distro apps, then later on more can come about, but some lubricant, some API, some standard is needed somewhere it seems in order to make this happen.