Exactly, and "customization" for the most part shouldn't be based on really weird "tweaks", it should mostly all be about the installation/removal of software or modules or whatnot. If you want a faster system, remove X, Y, and Z. If you don't want a GUI, remove X. There shouldn't really be anything super special about a "server" edition vs. a "desktop" edition other than default software selection, and on the same note it'd also be nice if there wasn't anything super special between distros, too. It's all Linux, it should all play nicely together. The main difference usually seems to stem from the file hierarchy being different due to where that particular package manager and package format chooses to put it's files, a difference that could be made more dynamic via corrected and standardized XML tags that allowed a package format to be adopted by more than one manager. Then, we could have cross-distro package installation of at least one format, which would remove the "we chose Ubuntu because it has a lot of packages compiled for it specifically" problem. Once Linux software is compiled once by the actual devs who made the program instead of by distro compilers making their own "specially tweaked versions", we'll all be free from distro lock-in, and choosing Fedora over Ubuntu will matter a whole lot less because it will be a simple matter of changing to any repository you want, even Ubuntu's if you like their "support", or manually installing any package updates you want. Or more appropriately, we'll have repositories directly to the developers of the program, so we get our updates from them directly and quickly, and not be forced to be dependent on the distro package maintainers.
Once Linux is free of it's distro proprietarization, maybe software vendors will be much more anxious to target it and create Linux packages, maybe then we'll finally start getting a lot more games for Linux, among other things.
InternetNews points out that only about half of the.NET apps out there will work on Mono 2.0, for a variety of reasons including (but not limited to) legacy Windows-only libraries and Microsoft's progress on.NET 3.0 and 3.5 APIs.
Exactly, which makes it pretty useless, so it's as bad as OOXML in a way, so tell me again why I'd want to bother writing Microsoft-specific software for Linux? No thanks.
Neither rpm nor deb are anything like "proprietary solutions." They're fully documented and mostly compatible. rpm --> deb can be accomplished trivially. As for the reverse, I think you can set up Red Hat based distros to use apt. Not my area of expertise, though.
But they aren't, so if it was trivial, you'd think things like that would be done so that users could install any package formats, but they aren't.
Regarding your idea about package manager compatibility, that's not something that's possible on the lowest level. apt will probably never be compatible with rpm packages, and rpm will never be compatible with debs. What you're looking for is much more likely to be accomplished by a frontend, like this one.
From the website, "The primary design goal is to unify all the software graphical tools used in different distributions.".
It is not a unification of package formats, it's a unification of package manager front-ends. It will not allow cross-distro packaging. The only things available right now are binary installers that don't at all integrate with the package manager, or Zero Install which is what I just said except it at least tries to integrate a little bit. Other than that, the only solution presented that I've ever seen is the Burgdorf Packaging API.
Finally, as for "why don't they seem to care?" well, proponents of each believe their solution to be the technically superior one, of course. That's Linux, man, that's choice. Free software is about choice, even at the expense of growth, and that's a Good Thing, it's what got us this far and it'll carry us to the future.
No matter which office program you choose to write documents in, you usually have a choice to save them in the ODF format. Standards give you more choice. I can save all my documents, and then easily switch to another office program if I so choose to do so, without having to worry about accessibility. They need to make package managers compatible with the major formats out there so that users can have access to software. You said yourself it was possible, so it needs to be done then! That's my argument! Programmers would still be free to choose RPM or DEB, it would not take away that choice or freedom, I want there to be more choice and freedom, I want there to be more packaging formats, and as long as they make package management systems intelligent enough to be able to deal with different formats, that's completely possible.
Linux users make a big stink about wanting standards like ODF and making office software read and write ODF, I'm saying they should make a big stink about having compatibility with at LEAST ONE goddamn packaging format. It's not technically impossible, at all, you just admitted it, so where is it. I'm not talking about getting on the command line and typing in "alien blahblahblah" I'm talking about integration with managers so users can point and click, because that is what will get Linux adoption and that's what I want to see. Making the argument that adding features to a system to improve it's use is a bad thing is ludicrous. Linux will ALWAYS have choice, and I will choose the Linux software that gives me more choice.
I just don't find the whole deb/rpm debate to be as much of an issue as you're making it out to be.
Fucking christ. I'm not arguing about DEB vs. RPM, I never was, and I don't care, those are just two formats that any developer should be ABLE to choose while still being able to get their software to any and all Linux users. What I am arguing, again, is that DEB packages should be installable on RPM managers, and RPM packages should be installable on DEB managers. If this can't be done because one package format lacks some metadata, it needs to be upgraded to include it, so that the API actually is useful. That way
I should add that when I said Windows has at least one API for package installation, I meant at least one standardized API. You don't need to have only one installation format for Linux, and you shouldn't because how can competition bring about another format, or what if one is easier to package for than another? You have to allow improvements in technology. For now, at least one format that's cross-distro needs to be adopted, somehow, and then you can worry about making plug-ins or whatnot for these managers to allow them to be compatible with more formats.
Right, there's so many reasons for it, I know that one big one is developers are pissed at the distros for changing their programs and then users would file bugs about them when the bug was caused by the distro's devs. While there are certainly lots of configuration files and such, I think that Linux should be modular enough that tweaking for the most part wasn't needed because all programs chose sensible default values to begin with. I think it'd be much nicer if "tweaking" a system was much more installing/uninstalling software was all. Got a slow mini-laptop? Fine, remove this piece of software, and that one, and this one isn't needed, not using bluetooth, there, less bloated now. Aside from maybe a few things which could be tweaked for some reason, for the most part, if everything was modular and used sane default values I think that would for the most part take care of it all. Then, programs just need to all have sane values and support packages for different platforms, not different distros. There should be a Linux x86 binary, a 64-bit, and possibly some of the other platforms which are cheaper like sparc and such.
Once Linux is ready to be easily targeted as a platform with the LSB packaging solution or something else, id, EA, Blizzard, and all those companies will have a much easier time making games for Linux which is one of Linux's tripping points right now, not to mention like you said, I can actually go out and easily download and install Firefox 3, and with the URL systems they are wanting to implement, you could let your manager get updates for Firefox directly from Mozilla, and not your middleman distro company, which is the way it should be. If the distro wants to have "officially supported packages" for paid support that's fine, they can flag the packages as being "3rd party" which I guess they are really 1st party, heh.
While you're right in that that is one solution, of course that's not an actual fix of the problem, which of course would be that the RPM package managers make compatibility with DEB, and vise versa, and if it can't be done because of a lack of metadata in one of the package formats, so be it, either update one or both of the formats, or come up with a new format and make your package manager compatible with it. Why don't they seem to care? I think part of the reason is that distro companies like Canonical and Red Hat and Novell and all the others think by having a proprietary solution, they'll have a one up over the other distros. That's just so foolish for many reasons, one being Linux adoption needs to actually you know grow, now is not the time to be fragmented in areas where it's completely retarded to do that. Linux still has to work together and it needs to make itself a universally targetable platform, otherwise companies like id, Blizzard, Frictional Games, and everyone including open source developers as well can have tight little automatic updating systems and uninstallation systems and all the other benefits package managing provides.
Any way, telling RPM managers to switch to DEB? Well, if it needs to be done so be it, but I'd much rather vote for my above solution. Package formats shouldn't be so static, you should be able to install multiple formats, so that newer formats can come out. Should be as trivial as installing a plug-in for your manager like it is with installing RAR support for File Roller. Klik, and moreso Zero Install are two top-level solutions, but the LSB Packaging API (Burgdorf API right now) seems to be the best solution, then it will actually hopefully come pre-installed in all these distros.
You don't have to offer good support, or any support, for something. If it was easy to port OSX drivers to Linux, and it'd allow Linux users easy access to their hardware, it'd be smart of them to do that now wouldn't it.
The thing is, the interface on the EEE is so simple that I don't think it's a problem using it, I think it's either
1) They were expecting Windows and anything different is bad. I'm not talking about any technical reasons here, just the fact that it doesn't show "Windows XP" when they power it on.
2) Technical problems, where something simply doesn't work as intended.
3) They wanted a desktop. From what I've seen, you just get a bunch of big icons, and that might seem more like a "toy" and not the "desktop" experience they were wanting, and until they are given the option to load one up that may turn them off.
4) Getting and installing software. OK, rant time, for those of you who know me you've probably heard it before, but I'd hope there was some internet retrieval "repository" system available as one of those big icons the user can select, that'd certainly help, but users should also have the option to have access to more software than what's in there, and more versions of that software, without waiting for Xandros to put them in. They are going to be somewhat confused when they download and try to run an EXE, though if Wine comes pre-installed this may be easy, but even after someone explains to them that it's a program for Windows, the next question won't have a good answer: "What do Linux programs look like?" "Well, er, there aren't any really, it has to say "for Xandros version blahblahblah, whatever version you're using, in order to actually install the software, and since basically no one makes packages for Xandros, you're fucked." "Oh.....I think I want to go back to Windows." OR you get "It says the only package available is a source package. What do I do with it? I can't find what to click on." "Um, well, you need to take a class in how to use a terminal first and navigate around in that, then you need to learn how to type these three lines, but only after you've gone through and made sure you have the required versions of the required libraries, and if you run into any problems you have to go onto the forums and..." "I need to do ALL THAT just to use Linux software when I'm running Linux?!?! FUCK THAT!"
The fact that Linux doesn't have as many programs as Windows does is bad enough, but that software accessibility is lacking because there is no universally adopted package format, or basically no cross-distro packaging solution right now, that puts a huge dent in it's adoption and will until Linux gets that sorted out. My roommate was wanting to install some Linux software that was slightly niche and gave up after he found out all the trouble you had to go through to get it installed. The politics of having "free software" fail miserably if you find yourself in a prison because you can't actually easily gain access to it. At least Windows has ONE standardized API to use for package installation for easy installation and removal, yet Linux has to be so retarded with it's package managers because these asshole developers can't try to place nicely with each other, probably due to politics behind distro companies wanting to use their proprietary compiled software repositories against one another as a perk for choosing their distro, so the problem remains unsolved and only the actual users who want easy "third-party" software installation care.
Skype has video and I heard that was installed by default, and of course there are several other Linux IM clients which do video which should be default instead of Gaim. I like Gaim but I am just surprised it's still the default when there are several options with video support that are cross-protocol. At least I think there's more talk about adding that support to Gaim but I know at least one of the main developers isn't interested in it's adoption, as he told me directly.
Dell IS incompetent. All their Linux "offerings" have been fucked up. They always give the Windows version the perks, like bigger hard drives and such, and throw Linux into the corner where you have to be purposefully searching for it to get it. Only now has Dell finally put Linux and Windows side-by-side with their mininote, but even then the Windows version still has hardware perks for buying it! WHY?
I don't know what kind of emails go back and forth between them and Microsoft, but they certainly seem to try hard to fuck it up and paint Linux as the worse option. I don't think it's the manager of the project, I think it's the policy of Dell and Microsoft.
Right, and I haven't gotten my paws on a triple-E yet but the UI on there looks pretty simple to me, however it could simply not be what some consumers want in the sense that some are either looking for Windows because they have certain Windows programs they think they need or actually need, or simply want, or they were expecting a desktop.
I think that installing Linux + Gnome or KDE might see less returns. I think that in some consumer's minds, having that big interface with huge buttons might make it seem more like a toy and they might feel trapped in that walled garden, even though in reality they aren't completely trapped, but having a desktop and an easy way to install more software and such (I don't know, maybe it is easy to install more software on the stock triple-E install?) they might enjoy one of the more "normal" Linux desktops instead. I think Asus should make a "normal" desktop available for selection from the login screen, or something.
Linux is great for people who don't mind doing email, surfing, and solitaire as well as office productivity, several other fun games, playing media, and several other things
Had to fix that for you, because that's what you just said your mother in law did with it, and I assume that she obviously doesn't like "tinkering" like you said. Linux is much more plug and play now, you should seriously try a newer distro.
Any way, you're right though to some degree don't get me wrong, I just think that Linux is for a lot more consumers than you do, but there are still a lack of Linux programs for several things on Linux you're right, and of course if you're needing somewhat "niche" programs then you really only have five options. Sometimes one of the first three options will just work and that'll be the end of it, but sometimes you're forced to do 4 or 5.
1. Your company gets a cross-platform solution to begin with. This could be easy or hard, depending. Often you CAN find some company out there that makes Linux software that does what you need, so if this was kept in mind as one of the features for your company/organization, if they had standardized on it instead, life would be easier in that regard. After they've already made another purchase though of course it's harder to get them to convert, at least until it's time for their software renewal.
2. Find that alternative yourself and use it as long as it's compatible with your company's software.
3. Wine. Many programs "just work", especially if they are "basic" Windows programs that use the more basic API calls, but Wine is pretty good at even running complex games sometimes.
Because of the lack of CD/DVD-ROM? Sure, though now with Unetbootin you can easily install to, well, anywhere, easily.
I plan on using USB sticks for all my Linux installation needs from now on, no more CD burning for me. Of course another cool way is to do it via your network through PXE and whatnot, but that's a little harder to set up than just a few clicks unfortunately.
This problem will always exist sure, blame general brand recognition problems in the world for part of that. But, to beat some of this, simply programming with an "intuitive" interface is the best practice and I think Linux has done a good job with that in some areas, but obviously there's always room for improvement, there are still GUIs missing for some tasks for instance. Any way, I think both Gnome and KDE do a much better job for the most part than the Windows GUI does. It only takes a few clicks to get to most things which is very nice, unlike with Windows XP which buries stuff a bit, and most especially Windows Vista which not only buries stuff further but flashes warnings at you the whole way.
Yeah, I know I'm changing firewall settings, if I didn't know what that would do why would I be in there changing them to begin with? ZOMG I want to use a 3rd party solution instead of your own crap? You sure do make that difficult to do, don't you.
That having been said, Linux needs a few more error messages whenever programs crash or fail to run, so that users can get basic feedback when things don't work without having to run them from a terminal. Those are the good kind of feedback messages users need, to you know, help them out in doing what they were trying to do, not putting roadblocks in their way.
Oh, I think I see what you're saying, or in other words have packages have more than one name. Or perhaps more simply, they need to have a standardized name somewhere in the package metadata is all. You have a particular packaging format be standardized and in that you have a standardized name, LSB_Package_Name="blah" or whatever. Yeah I think that's definitely needed for decentralized package distribution, even if the naming convention part has to be somewhat centralized. Like I said, even if things went down the crapper with the naming somehow, they could just switch to either a different package format or a different naming convention solution.
If you read in part 2, he talks about registering the program with the package system, but not providing for dependency resolution other than the one big LSB compliant resolution, as well as some additional LSB "pieces", but to limiting it to that instead of worrying about the thousands of other packages, so you're half right. I don't really understand this though, because once you have the dependency system in place, you don't really need to "worry" at all. Sure, having a base set of packages I guess can be helpful, but I believe the package format and manager together could provide all the solutions needed to resolve any kind of problems with getting software.
I'm frustrated that decentralized package resolution development is occurring in "top-down" programs such as Zero Install, and not in the base package systems where they should be. Using decentralized packaging, you have URLs for all dependencies, and you could have multiple locations from which packages were available, and the system also incorporates key signing and hash checking to protect users from file fraud. Using this system a developer could actually make all the dependencies they are using available from themselves if they didn't want to point anyone elsewhere, but only the dependencies the user didn't have would be downloaded, instead of installing the whole whopping software bundle. In other words, it would allow you to utilize dependencies and save bandwidth and storage space (though both of those things aren't AS big of an issue now days as they have been) while not running into any kind of problems with "worrying" about the base package installation.
Any way, just the base implementation is good enough for now so that all Linux users will have SOME way of installing any software, but I believe there is a lot of room for improvement and that they should really take a look at all the things Zero Install is accomplishing.
Yes, but for package formats, name standardization is usually something which is wanted. DEB has it's own naming convention system for example. So, if the LSB wanted to be more helpful, they should consider becoming a standards body for a particular format of application packaging, and I'd guess they will if the Burgdorf format takes off.
I mean don't get me wrong, DEB and RPM are great, I guess, but someone needs to make a format or a subsystem that will allow some kind of package to be cross-distro, so whatever it takes to make it happen, great. By using dependencies the way they should be used, you should be able to install anything. As long as it gets those libraries installed that the program actually needs, then there's no reason it shouldn't be able to run. If everything it needs can be placed as a dependency, in an organized way so that reuse of existing packages can be done if possible, then there's no problem. I think one of the issues is getting everyone to use a solid naming convention, and if that's all it is, that's just a simple communication issue. If I have to post up on a board someplace that I'm using the package name "awesomeness_program" for my program, so be it. If the organization running that system decides to be a jerk and start charging for name registration? Big whoop, you just update the packaging format standard to be able to use another naming standard, or change package formats altogether. Point being using standards doesn't mean lock-in, it just means consistent communication, and I know that if I were making a program, I would definitely want that consistency so my program could reach the masses as best it could.
I don't quite understand what you mean, I thought integration was exactly what he is talking about. He wants Linux to be a targetable platform, and so do I. I want software developers, both open and closed ones, to be able to release one package or one CD/DVD or whatever, and have it install and integrate easily regardless of the user's distro of choice. Like he said when he said there needs to be transferable apps not just programs, so not just binary compatibility is needed but package manager integration so that you can do all the installation and updating and such. That was exactly what the articles were about though I did read them a while back, but I'm pretty sure. Integration to me means iteroperating, inter-program communication, and that's just a communication problem. So, if the LSB wants to help function as a standards body, much like W3C for web standards or the Open Document Foundation for the ODF format, great, I hope that some Linux packaging standard gets adopted and soon, at least one, with more to come later, because I see software accessibility as the leading barrier to entry for Linux users right now. Most people are stupid, it's a fact, and if you don't like that word then unlearned, or ignorant, but regardless most of them will not ever learn to compile, and I want Linux to beat both Windows and Mac and everything else that's proprietary into the ground.
I see this problem as the only real proprietary thing on Linux right now, and it needs to be done away with with some simple planning and communication.
As a result configuration files need to be changed in complex ways between distributions.
Trust me, dependency issues can be dealt with. Interactions between programs can be dealt with. That's the thing, is that they need to start being dealt with, instead of closing out interoperability issues by slapping users with proprietary software stacks. No, that's not how things should be, Linux should not become fragmented. I should be able to install the newest version of Firefox directly from Mozilla, and if Linux packaging was standardized, I'd also receive my updates directly from them as well, if I choose to do so. By keeping user's programs proprietary, they become isolated and dependent on the distro company, and that's what these companies want, and it prevents programs from being able to learn to play nicely with each other too. Many users are so suspicious of Microsoft and their lock-in tactics, yet Linux interoperability has been getting some neglect. If programs are designed well, they can function with other programs, they can resolve all their problems with cooperating with other programs. My main point here is that cooperation simply requires communication, and that's not a barrier that should exist anymore now that the Internet exists, the only barrier is more intelligent programmers.
Linux is powerful, and part of that power is it's flexibility, but it's very possible to retain that flexibility and power by being more modular. Basically, there's no reason that you have to have the configuration of programs centered around compilation, you don't have to have settings set at that level, you can instead have plug-ins and modules, etc. As far as specific settings which allow inter-program communication, again, communication and intelligent programming can resolve all these issues.
The alternative would be some sort of unified handling which prevents distributions from being radically different than one another with respect to their core offerings: for example unified configuration managers.
Communication of some sort certainly needs to happen. I'll tell you one thing developers hate though, is when they have to worry about a certain version of their software on a certain distro has been tampered with when users come to them crying about bugs. It's incredibly annoying for them to deal with that, and rightly so. When a program has been modified from the original code in any way, it's only polite to call it something different so that it won't get confused with the original. If Firefox was ever somehow compiled differently using different libraries or whatnot, Mozilla shouldn't have to support that version as it's a different version, because if those changes in library versions cause problems then it's the library developers who are at fault for not having a stable library API, etc.
The default main program and it's settings need to be tested more and it help the program to get more attention, and that's what should happen, and it also allows users to easily swap out the program with newer versions of the original program from the creator's website and not have to worry about special configurations. I'm not saying that distros need to ship all programs with the default settings, but clearly communication needs to occur here so that different programs can interact with each other. For example, the move to XML-based configuration files helps to standardize things so that any other program can pull up the configuration of another program. If one program uses another, quite simply, they need to be able to properly communicate and this is always true and is a problem that will never go away. So clearly here you need intelligent programming in such ways that allow programs to be aware of the requirements of another one, or for settings to be dealt with through the dependency tree system, or some method, so that this inter-program communication can occur without fucking up settings
The middle man is the problem, and you should not need them. I want to get my software directly from the developers if I choose to do so. There is absolutely no need whatsoever for additional assholes getting in the way of this aside from presenting nice software bundles and offering support. Linux needs to be truly open and accessible, and for that to happen it needs to modularize itself in every way and free itself from proprietary distributors. I'm talking about freedom here, and I use Linux to have it, not to be locked into a specific software repository.
Doing this is very possible, all it does is require more intelligent programming, with standards and such in mind like with what the LSB and Freedesktop has tried to help promote, but it simply needs a little more communication with software packages, that's it. If you think there's some magical mystical barrier that prevents this from happening, why this is impossible for software to do, explain it to me. For DEBs and RPMs, most of each of them work in their respective package managers, yet neither managers have been made compatible with the other, even though all it takes is some additional communication. But go ahead, tell me why this communication cannot be done, why it's impossible to have at least one format that works with both systems? Technical details, please.
Klik exists, Zero Install exists, and of course not to mention Windows and OS X exist, so this can be done, all it takes is clear communication and at least one packaging format that the existing major managers are compatible with.
Distro companies wanting to fragment Linux by not working to resolve this issue are greedy assholes trying to pull users to their company by providing proprietary software that hooks you into having to get it from them and them alone, creating this Linux teat for their users that gives them the crack they need. Fuck that. Linux should mean freedom, not proprietary vendor lock-in.
I honestly don't know what that means exactly, because I'm no programmer, but since you had "module" in there, I can only assume it will help both modularity and possibly dependencies, and that would certainly be good for Linux.;)
The U.S. is run by religious nutcases who will vote for anyone as long as they proclaim they're in the same god faction they are. There was a time when U.S. presidents actually had some form of humility, and alignments like religion weren't purposefully pushed out into the open as cheap ways of scoring points. The U.S. has become an even bigger disgrace than ever, especially for letting him stay in office. Stupidity in schools has kept many from thinking for themselves and only serves to put this country into even more of a Nazi mindset marching forward in the name of patriotism and religion instead of denouncing ideas like these like they should be as mentally unfounded and foolish. The day everyone in the U.S. stops with the flag waving and finally starts praising intelligence and thought will be a great one indeed, if it ever comes. Unfortunately, the future looks kind of bleak for that ever changing as those who don't want it to happen are at the helm.
Slashdot Mirror
Exactly, and "customization" for the most part shouldn't be based on really weird "tweaks", it should mostly all be about the installation/removal of software or modules or whatnot. If you want a faster system, remove X, Y, and Z. If you don't want a GUI, remove X. There shouldn't really be anything super special about a "server" edition vs. a "desktop" edition other than default software selection, and on the same note it'd also be nice if there wasn't anything super special between distros, too. It's all Linux, it should all play nicely together. The main difference usually seems to stem from the file hierarchy being different due to where that particular package manager and package format chooses to put it's files, a difference that could be made more dynamic via corrected and standardized XML tags that allowed a package format to be adopted by more than one manager. Then, we could have cross-distro package installation of at least one format, which would remove the "we chose Ubuntu because it has a lot of packages compiled for it specifically" problem. Once Linux software is compiled once by the actual devs who made the program instead of by distro compilers making their own "specially tweaked versions", we'll all be free from distro lock-in, and choosing Fedora over Ubuntu will matter a whole lot less because it will be a simple matter of changing to any repository you want, even Ubuntu's if you like their "support", or manually installing any package updates you want. Or more appropriately, we'll have repositories directly to the developers of the program, so we get our updates from them directly and quickly, and not be forced to be dependent on the distro package maintainers.
Once Linux is free of it's distro proprietarization, maybe software vendors will be much more anxious to target it and create Linux packages, maybe then we'll finally start getting a lot more games for Linux, among other things.
InternetNews points out that only about half of the .NET apps out there will work on Mono 2.0, for a variety of reasons including (but not limited to) legacy Windows-only libraries and Microsoft's progress on .NET 3.0 and 3.5 APIs.
Exactly, which makes it pretty useless, so it's as bad as OOXML in a way, so tell me again why I'd want to bother writing Microsoft-specific software for Linux? No thanks.
Oops, sorry about the all bold there at the end. ^^
Neither rpm nor deb are anything like "proprietary solutions." They're fully documented and mostly compatible. rpm --> deb can be accomplished trivially. As for the reverse, I think you can set up Red Hat based distros to use apt. Not my area of expertise, though.
But they aren't, so if it was trivial, you'd think things like that would be done so that users could install any package formats, but they aren't.
Regarding your idea about package manager compatibility, that's not something that's possible on the lowest level. apt will probably never be compatible with rpm packages, and rpm will never be compatible with debs. What you're looking for is much more likely to be accomplished by a frontend, like this one.
From the website, "The primary design goal is to unify all the software graphical tools used in different distributions.".
It is not a unification of package formats, it's a unification of package manager front-ends. It will not allow cross-distro packaging. The only things available right now are binary installers that don't at all integrate with the package manager, or Zero Install which is what I just said except it at least tries to integrate a little bit. Other than that, the only solution presented that I've ever seen is the Burgdorf Packaging API.
Finally, as for "why don't they seem to care?" well, proponents of each believe their solution to be the technically superior one, of course. That's Linux, man, that's choice. Free software is about choice, even at the expense of growth, and that's a Good Thing, it's what got us this far and it'll carry us to the future.
No matter which office program you choose to write documents in, you usually have a choice to save them in the ODF format. Standards give you more choice. I can save all my documents, and then easily switch to another office program if I so choose to do so, without having to worry about accessibility. They need to make package managers compatible with the major formats out there so that users can have access to software. You said yourself it was possible, so it needs to be done then! That's my argument! Programmers would still be free to choose RPM or DEB, it would not take away that choice or freedom, I want there to be more choice and freedom, I want there to be more packaging formats, and as long as they make package management systems intelligent enough to be able to deal with different formats, that's completely possible.
Linux users make a big stink about wanting standards like ODF and making office software read and write ODF, I'm saying they should make a big stink about having compatibility with at LEAST ONE goddamn packaging format. It's not technically impossible, at all, you just admitted it, so where is it. I'm not talking about getting on the command line and typing in "alien blahblahblah" I'm talking about integration with managers so users can point and click, because that is what will get Linux adoption and that's what I want to see. Making the argument that adding features to a system to improve it's use is a bad thing is ludicrous. Linux will ALWAYS have choice, and I will choose the Linux software that gives me more choice.
I just don't find the whole deb/rpm debate to be as much of an issue as you're making it out to be.
Fucking christ. I'm not arguing about DEB vs. RPM, I never was, and I don't care, those are just two formats that any developer should be ABLE to choose while still being able to get their software to any and all Linux users. What I am arguing, again, is that DEB packages should be installable on RPM managers, and RPM packages should be installable on DEB managers. If this can't be done because one package format lacks some metadata, it needs to be upgraded to include it, so that the API actually is useful . That way
I should add that when I said Windows has at least one API for package installation, I meant at least one standardized API. You don't need to have only one installation format for Linux, and you shouldn't because how can competition bring about another format, or what if one is easier to package for than another? You have to allow improvements in technology. For now, at least one format that's cross-distro needs to be adopted, somehow, and then you can worry about making plug-ins or whatnot for these managers to allow them to be compatible with more formats.
Right, there's so many reasons for it, I know that one big one is developers are pissed at the distros for changing their programs and then users would file bugs about them when the bug was caused by the distro's devs. While there are certainly lots of configuration files and such, I think that Linux should be modular enough that tweaking for the most part wasn't needed because all programs chose sensible default values to begin with. I think it'd be much nicer if "tweaking" a system was much more installing/uninstalling software was all. Got a slow mini-laptop? Fine, remove this piece of software, and that one, and this one isn't needed, not using bluetooth, there, less bloated now. Aside from maybe a few things which could be tweaked for some reason, for the most part, if everything was modular and used sane default values I think that would for the most part take care of it all. Then, programs just need to all have sane values and support packages for different platforms, not different distros. There should be a Linux x86 binary, a 64-bit, and possibly some of the other platforms which are cheaper like sparc and such.
Once Linux is ready to be easily targeted as a platform with the LSB packaging solution or something else, id, EA, Blizzard, and all those companies will have a much easier time making games for Linux which is one of Linux's tripping points right now, not to mention like you said, I can actually go out and easily download and install Firefox 3, and with the URL systems they are wanting to implement, you could let your manager get updates for Firefox directly from Mozilla, and not your middleman distro company, which is the way it should be. If the distro wants to have "officially supported packages" for paid support that's fine, they can flag the packages as being "3rd party" which I guess they are really 1st party, heh.
While you're right in that that is one solution, of course that's not an actual fix of the problem, which of course would be that the RPM package managers make compatibility with DEB, and vise versa, and if it can't be done because of a lack of metadata in one of the package formats, so be it, either update one or both of the formats, or come up with a new format and make your package manager compatible with it. Why don't they seem to care? I think part of the reason is that distro companies like Canonical and Red Hat and Novell and all the others think by having a proprietary solution, they'll have a one up over the other distros. That's just so foolish for many reasons, one being Linux adoption needs to actually you know grow, now is not the time to be fragmented in areas where it's completely retarded to do that. Linux still has to work together and it needs to make itself a universally targetable platform, otherwise companies like id, Blizzard, Frictional Games, and everyone including open source developers as well can have tight little automatic updating systems and uninstallation systems and all the other benefits package managing provides.
Any way, telling RPM managers to switch to DEB? Well, if it needs to be done so be it, but I'd much rather vote for my above solution. Package formats shouldn't be so static, you should be able to install multiple formats, so that newer formats can come out. Should be as trivial as installing a plug-in for your manager like it is with installing RAR support for File Roller. Klik, and moreso Zero Install are two top-level solutions, but the LSB Packaging API (Burgdorf API right now) seems to be the best solution, then it will actually hopefully come pre-installed in all these distros.
You don't have to offer good support, or any support, for something. If it was easy to port OSX drivers to Linux, and it'd allow Linux users easy access to their hardware, it'd be smart of them to do that now wouldn't it.
The thing is, the interface on the EEE is so simple that I don't think it's a problem using it, I think it's either
1) They were expecting Windows and anything different is bad. I'm not talking about any technical reasons here, just the fact that it doesn't show "Windows XP" when they power it on.
2) Technical problems, where something simply doesn't work as intended.
3) They wanted a desktop. From what I've seen, you just get a bunch of big icons, and that might seem more like a "toy" and not the "desktop" experience they were wanting, and until they are given the option to load one up that may turn them off.
4) Getting and installing software. OK, rant time, for those of you who know me you've probably heard it before, but I'd hope there was some internet retrieval "repository" system available as one of those big icons the user can select, that'd certainly help, but users should also have the option to have access to more software than what's in there, and more versions of that software, without waiting for Xandros to put them in. They are going to be somewhat confused when they download and try to run an EXE, though if Wine comes pre-installed this may be easy, but even after someone explains to them that it's a program for Windows, the next question won't have a good answer: "What do Linux programs look like?" "Well, er, there aren't any really, it has to say "for Xandros version blahblahblah, whatever version you're using, in order to actually install the software, and since basically no one makes packages for Xandros, you're fucked." "Oh.....I think I want to go back to Windows." OR you get "It says the only package available is a source package. What do I do with it? I can't find what to click on." "Um, well, you need to take a class in how to use a terminal first and navigate around in that, then you need to learn how to type these three lines, but only after you've gone through and made sure you have the required versions of the required libraries, and if you run into any problems you have to go onto the forums and..." "I need to do ALL THAT just to use Linux software when I'm running Linux?!?! FUCK THAT!"
The fact that Linux doesn't have as many programs as Windows does is bad enough, but that software accessibility is lacking because there is no universally adopted package format, or basically no cross-distro packaging solution right now, that puts a huge dent in it's adoption and will until Linux gets that sorted out. My roommate was wanting to install some Linux software that was slightly niche and gave up after he found out all the trouble you had to go through to get it installed. The politics of having "free software" fail miserably if you find yourself in a prison because you can't actually easily gain access to it. At least Windows has ONE standardized API to use for package installation for easy installation and removal, yet Linux has to be so retarded with it's package managers because these asshole developers can't try to place nicely with each other, probably due to politics behind distro companies wanting to use their proprietary compiled software repositories against one another as a perk for choosing their distro, so the problem remains unsolved and only the actual users who want easy "third-party" software installation care.
Skype has video and I heard that was installed by default, and of course there are several other Linux IM clients which do video which should be default instead of Gaim. I like Gaim but I am just surprised it's still the default when there are several options with video support that are cross-protocol. At least I think there's more talk about adding that support to Gaim but I know at least one of the main developers isn't interested in it's adoption, as he told me directly.
Dell IS incompetent. All their Linux "offerings" have been fucked up. They always give the Windows version the perks, like bigger hard drives and such, and throw Linux into the corner where you have to be purposefully searching for it to get it. Only now has Dell finally put Linux and Windows side-by-side with their mininote, but even then the Windows version still has hardware perks for buying it! WHY?
I don't know what kind of emails go back and forth between them and Microsoft, but they certainly seem to try hard to fuck it up and paint Linux as the worse option. I don't think it's the manager of the project, I think it's the policy of Dell and Microsoft.
Right, and I haven't gotten my paws on a triple-E yet but the UI on there looks pretty simple to me, however it could simply not be what some consumers want in the sense that some are either looking for Windows because they have certain Windows programs they think they need or actually need, or simply want, or they were expecting a desktop.
I think that installing Linux + Gnome or KDE might see less returns. I think that in some consumer's minds, having that big interface with huge buttons might make it seem more like a toy and they might feel trapped in that walled garden, even though in reality they aren't completely trapped, but having a desktop and an easy way to install more software and such (I don't know, maybe it is easy to install more software on the stock triple-E install?) they might enjoy one of the more "normal" Linux desktops instead. I think Asus should make a "normal" desktop available for selection from the login screen, or something.
If Mac OS X users on the whole spend a lot more money than Linux users, I don't see how it's blockheaded.
Because porting drivers from BSD to Linux is cake, I guess?
Linux is great for people who don't mind doing email, surfing, and solitaire as well as office productivity, several other fun games, playing media, and several other things
Had to fix that for you, because that's what you just said your mother in law did with it, and I assume that she obviously doesn't like "tinkering" like you said. Linux is much more plug and play now, you should seriously try a newer distro.
Any way, you're right though to some degree don't get me wrong, I just think that Linux is for a lot more consumers than you do, but there are still a lack of Linux programs for several things on Linux you're right, and of course if you're needing somewhat "niche" programs then you really only have five options. Sometimes one of the first three options will just work and that'll be the end of it, but sometimes you're forced to do 4 or 5.
1. Your company gets a cross-platform solution to begin with. This could be easy or hard, depending. Often you CAN find some company out there that makes Linux software that does what you need, so if this was kept in mind as one of the features for your company/organization, if they had standardized on it instead, life would be easier in that regard. After they've already made another purchase though of course it's harder to get them to convert, at least until it's time for their software renewal.
2. Find that alternative yourself and use it as long as it's compatible with your company's software.
3. Wine. Many programs "just work", especially if they are "basic" Windows programs that use the more basic API calls, but Wine is pretty good at even running complex games sometimes.
4. VM.
5. Windows.
Because of the lack of CD/DVD-ROM? Sure, though now with Unetbootin you can easily install to, well, anywhere, easily.
I plan on using USB sticks for all my Linux installation needs from now on, no more CD burning for me. Of course another cool way is to do it via your network through PXE and whatnot, but that's a little harder to set up than just a few clicks unfortunately.
This problem will always exist sure, blame general brand recognition problems in the world for part of that. But, to beat some of this, simply programming with an "intuitive" interface is the best practice and I think Linux has done a good job with that in some areas, but obviously there's always room for improvement, there are still GUIs missing for some tasks for instance. Any way, I think both Gnome and KDE do a much better job for the most part than the Windows GUI does. It only takes a few clicks to get to most things which is very nice, unlike with Windows XP which buries stuff a bit, and most especially Windows Vista which not only buries stuff further but flashes warnings at you the whole way.
Yeah, I know I'm changing firewall settings, if I didn't know what that would do why would I be in there changing them to begin with? ZOMG I want to use a 3rd party solution instead of your own crap? You sure do make that difficult to do, don't you.
That having been said, Linux needs a few more error messages whenever programs crash or fail to run, so that users can get basic feedback when things don't work without having to run them from a terminal. Those are the good kind of feedback messages users need, to you know, help them out in doing what they were trying to do, not putting roadblocks in their way.
Oh, I think I see what you're saying, or in other words have packages have more than one name. Or perhaps more simply, they need to have a standardized name somewhere in the package metadata is all. You have a particular packaging format be standardized and in that you have a standardized name, LSB_Package_Name="blah" or whatever. Yeah I think that's definitely needed for decentralized package distribution, even if the naming convention part has to be somewhat centralized. Like I said, even if things went down the crapper with the naming somehow, they could just switch to either a different package format or a different naming convention solution.
If you read in part 2, he talks about registering the program with the package system, but not providing for dependency resolution other than the one big LSB compliant resolution, as well as some additional LSB "pieces", but to limiting it to that instead of worrying about the thousands of other packages, so you're half right. I don't really understand this though, because once you have the dependency system in place, you don't really need to "worry" at all. Sure, having a base set of packages I guess can be helpful, but I believe the package format and manager together could provide all the solutions needed to resolve any kind of problems with getting software.
I'm frustrated that decentralized package resolution development is occurring in "top-down" programs such as Zero Install, and not in the base package systems where they should be. Using decentralized packaging, you have URLs for all dependencies, and you could have multiple locations from which packages were available, and the system also incorporates key signing and hash checking to protect users from file fraud. Using this system a developer could actually make all the dependencies they are using available from themselves if they didn't want to point anyone elsewhere, but only the dependencies the user didn't have would be downloaded, instead of installing the whole whopping software bundle. In other words, it would allow you to utilize dependencies and save bandwidth and storage space (though both of those things aren't AS big of an issue now days as they have been) while not running into any kind of problems with "worrying" about the base package installation.
Any way, just the base implementation is good enough for now so that all Linux users will have SOME way of installing any software, but I believe there is a lot of room for improvement and that they should really take a look at all the things Zero Install is accomplishing.
Yes, but for package formats, name standardization is usually something which is wanted. DEB has it's own naming convention system for example. So, if the LSB wanted to be more helpful, they should consider becoming a standards body for a particular format of application packaging, and I'd guess they will if the Burgdorf format takes off.
I mean don't get me wrong, DEB and RPM are great, I guess, but someone needs to make a format or a subsystem that will allow some kind of package to be cross-distro, so whatever it takes to make it happen, great. By using dependencies the way they should be used, you should be able to install anything. As long as it gets those libraries installed that the program actually needs, then there's no reason it shouldn't be able to run. If everything it needs can be placed as a dependency, in an organized way so that reuse of existing packages can be done if possible, then there's no problem. I think one of the issues is getting everyone to use a solid naming convention, and if that's all it is, that's just a simple communication issue. If I have to post up on a board someplace that I'm using the package name "awesomeness_program" for my program, so be it. If the organization running that system decides to be a jerk and start charging for name registration? Big whoop, you just update the packaging format standard to be able to use another naming standard, or change package formats altogether. Point being using standards doesn't mean lock-in, it just means consistent communication, and I know that if I were making a program, I would definitely want that consistency so my program could reach the masses as best it could.
I don't quite understand what you mean, I thought integration was exactly what he is talking about. He wants Linux to be a targetable platform, and so do I. I want software developers, both open and closed ones, to be able to release one package or one CD/DVD or whatever, and have it install and integrate easily regardless of the user's distro of choice. Like he said when he said there needs to be transferable apps not just programs, so not just binary compatibility is needed but package manager integration so that you can do all the installation and updating and such. That was exactly what the articles were about though I did read them a while back, but I'm pretty sure. Integration to me means iteroperating, inter-program communication, and that's just a communication problem. So, if the LSB wants to help function as a standards body, much like W3C for web standards or the Open Document Foundation for the ODF format, great, I hope that some Linux packaging standard gets adopted and soon, at least one, with more to come later, because I see software accessibility as the leading barrier to entry for Linux users right now. Most people are stupid, it's a fact, and if you don't like that word then unlearned, or ignorant, but regardless most of them will not ever learn to compile, and I want Linux to beat both Windows and Mac and everything else that's proprietary into the ground.
I see this problem as the only real proprietary thing on Linux right now, and it needs to be done away with with some simple planning and communication.
Thank you for your response.
As a result configuration files need to be changed in complex ways between distributions.
Trust me, dependency issues can be dealt with. Interactions between programs can be dealt with. That's the thing, is that they need to start being dealt with, instead of closing out interoperability issues by slapping users with proprietary software stacks. No, that's not how things should be, Linux should not become fragmented. I should be able to install the newest version of Firefox directly from Mozilla, and if Linux packaging was standardized, I'd also receive my updates directly from them as well, if I choose to do so. By keeping user's programs proprietary, they become isolated and dependent on the distro company, and that's what these companies want, and it prevents programs from being able to learn to play nicely with each other too. Many users are so suspicious of Microsoft and their lock-in tactics, yet Linux interoperability has been getting some neglect. If programs are designed well, they can function with other programs, they can resolve all their problems with cooperating with other programs. My main point here is that cooperation simply requires communication, and that's not a barrier that should exist anymore now that the Internet exists, the only barrier is more intelligent programmers.
Linux is powerful, and part of that power is it's flexibility, but it's very possible to retain that flexibility and power by being more modular. Basically, there's no reason that you have to have the configuration of programs centered around compilation, you don't have to have settings set at that level, you can instead have plug-ins and modules, etc. As far as specific settings which allow inter-program communication, again, communication and intelligent programming can resolve all these issues.
The alternative would be some sort of unified handling which prevents distributions from being radically different than one another with respect to their core offerings: for example unified configuration managers.
Communication of some sort certainly needs to happen. I'll tell you one thing developers hate though, is when they have to worry about a certain version of their software on a certain distro has been tampered with when users come to them crying about bugs. It's incredibly annoying for them to deal with that, and rightly so. When a program has been modified from the original code in any way, it's only polite to call it something different so that it won't get confused with the original. If Firefox was ever somehow compiled differently using different libraries or whatnot, Mozilla shouldn't have to support that version as it's a different version, because if those changes in library versions cause problems then it's the library developers who are at fault for not having a stable library API, etc.
The default main program and it's settings need to be tested more and it help the program to get more attention, and that's what should happen, and it also allows users to easily swap out the program with newer versions of the original program from the creator's website and not have to worry about special configurations. I'm not saying that distros need to ship all programs with the default settings, but clearly communication needs to occur here so that different programs can interact with each other. For example, the move to XML-based configuration files helps to standardize things so that any other program can pull up the configuration of another program. If one program uses another, quite simply, they need to be able to properly communicate and this is always true and is a problem that will never go away. So clearly here you need intelligent programming in such ways that allow programs to be aware of the requirements of another one, or for settings to be dealt with through the dependency tree system, or some method, so that this inter-program communication can occur without fucking up settings
The middle man is the problem, and you should not need them. I want to get my software directly from the developers if I choose to do so. There is absolutely no need whatsoever for additional assholes getting in the way of this aside from presenting nice software bundles and offering support. Linux needs to be truly open and accessible, and for that to happen it needs to modularize itself in every way and free itself from proprietary distributors. I'm talking about freedom here, and I use Linux to have it, not to be locked into a specific software repository.
Doing this is very possible, all it does is require more intelligent programming, with standards and such in mind like with what the LSB and Freedesktop has tried to help promote, but it simply needs a little more communication with software packages, that's it. If you think there's some magical mystical barrier that prevents this from happening, why this is impossible for software to do, explain it to me. For DEBs and RPMs, most of each of them work in their respective package managers, yet neither managers have been made compatible with the other, even though all it takes is some additional communication. But go ahead, tell me why this communication cannot be done, why it's impossible to have at least one format that works with both systems? Technical details, please.
Klik exists, Zero Install exists, and of course not to mention Windows and OS X exist, so this can be done, all it takes is clear communication and at least one packaging format that the existing major managers are compatible with.
Distro companies wanting to fragment Linux by not working to resolve this issue are greedy assholes trying to pull users to their company by providing proprietary software that hooks you into having to get it from them and them alone, creating this Linux teat for their users that gives them the crack they need. Fuck that. Linux should mean freedom, not proprietary vendor lock-in.
I honestly don't know what that means exactly, because I'm no programmer, but since you had "module" in there, I can only assume it will help both modularity and possibly dependencies, and that would certainly be good for Linux. ;)
The U.S. is run by religious nutcases who will vote for anyone as long as they proclaim they're in the same god faction they are. There was a time when U.S. presidents actually had some form of humility, and alignments like religion weren't purposefully pushed out into the open as cheap ways of scoring points. The U.S. has become an even bigger disgrace than ever, especially for letting him stay in office. Stupidity in schools has kept many from thinking for themselves and only serves to put this country into even more of a Nazi mindset marching forward in the name of patriotism and religion instead of denouncing ideas like these like they should be as mentally unfounded and foolish. The day everyone in the U.S. stops with the flag waving and finally starts praising intelligence and thought will be a great one indeed, if it ever comes. Unfortunately, the future looks kind of bleak for that ever changing as those who don't want it to happen are at the helm.